Empty Four Momenta with newest build of HallD Recon

[ShannenUmassJlab]

Hi all,

When running MC Wrapper using version_7.4.0.xml and a personal generator of mine (/w/halld-scshelf2101/home/shannen/events/generators/pi0TotGen/prim/para4/primParaGenNum.hddm), the decay products (i.e. the pi0->gamma gamma decay, which is done by GEANT) have empty four vectors. Their momenta and angles are 0 in hd_dump and a segfault is produced when I try and use DNeutralShowers over the resulting hddm files

Using version_7.0.0.xml, I the decay products are non-zero and no segault is produced

Let me know what you all think,

Shannen

[aaust]

@rjones30 Could this be a result of including double-precision support in the latest hddm version?

@ShannenUmassJlab Did you recompile your generator with the new version file, especially with the hddm 5.1.0 dependency?

[ShannenUmassJlab]

@aaust My generator is just a relatively simple root macro that produces a list of four vectors and writes them to an ascii file. To get the hddm file from this, I use a python script, which I ran with version_7.0.0.xml initialized, which uses hddm version 5.0.0. I can try and run the python script with version_7.4.0.xml and see if that fixes things

[rjones30]

Hello Shannen, Can you share a copy of your python script with instructions for how to reproduce the problem?

…

-Richard Jones

On Fri, Feb 6, 2026 at 3:06 PM ShannenUmassJlab ***@***.***> wrote: *ShannenUmassJlab* left a comment (JeffersonLab/halld_recon#1096) <#1096 (comment)> @aaust <https://github.com/aaust> My generator is just a relatively simple root macro that produces a list of four vectors and writes them to an ascii file. To get the hddm file from this, I use a python script, which I ran with version_7.0.0.xml initialized, which uses hddm version 5.0.0. I can try and run the python script with version_7.4.0.xml and see if that fixes things — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWHG6XNMCI4F7XGPXR34KTX5VAVCNFSM6AAAAACUHZGBJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRSGM2DAMBUGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ShannenUmassJlab]

Sure, the python script can be found here: /w/halld-scshelf2101/home/shannen/events/generators/ascii2hddm.py

If you want to reproduce this, in principle I'd think there's nothing special about any particular list of four vectors but one I was careful to use version_7.4.0.xml in making the hddm file can be found here: /w/halld-scshelf2101/home/shannen/events/generators/pi0TotGen/prim/para4/primParaGenNum.csv

If you want to produce an hddm file, you can do it as follows: python3 ascii2hddm.py pi0 pb208 [origin file] [outpite file name], but the generator files are fairly large so it takes a while to run. I've made an hddm file with version_7.4.0.xml, it can be found here /w/halld-scshelf2101/home/shannen/events/generators/pi0TotGen/prim/para4/primParaVerTest.hddm

From there I feed it through MC wrapper by using gluex_MC.py w/ the following config file: /w/halld-scshelf2101/home/shannen/events/generators/MC.config

Files ran w/ version_7.4.0.xml can be found here: /volatile/halld/home/shannen/generators/pi0/prim/para6/hddm and versions ran w/ version_7.0.0.xml can be found here: /volatile/halld/home/shannen/generators/pi0/prim/para7/hddm

[rjones30]

Shannen, I ran one of your gen_amp_*.hddm simulation output files through hddm-xml and all of your pi0 momentum components are non-zero. Can you produce a sample output using hddm-xml that shows one event from one of your output files that has zero momentum components?

…

-Richard Jones

On Sun, Feb 8, 2026 at 12:24 AM ShannenUmassJlab ***@***.***> wrote: *ShannenUmassJlab* left a comment (JeffersonLab/halld_recon#1096) <#1096 (comment)> Sure, the python script can be found here: /w/halld-scshelf2101/home/shannen/events/generators/ascii2hddm.py If you want to reproduce this, in principle I'd think there's nothing special about any particular list of four vectors but one I was careful to use version_7.4.0.xml in making the hddm file can be found here: /w/halld-scshelf2101/home/shannen/events/generators/pi0TotGen/prim/para4/primParaGenNum.csv If you want to produce an hddm file, you can do it as follows: python3 ascii2hddm.py pi0 pb208 [origin file] [outpite file name], but the generator files are fairly large so it takes a while to run. I've made an hddm file with version_7.4.0.xml, it can be found here /w/halld-scshelf2101/home/shannen/events/generators/pi0TotGen/prim/para4/primParaVerTest.hddm From there I feed it through MC wrapper by using gluex_MC.py w/ the following config file: /w/halld-scshelf2101/home/shannen/events/generators/MC.config Files ran w/ version_7.4.0.xml can be found here: /volatile/halld/home/shannen/generators/pi0/prim/para6/hddm and versions ran w/ version_7.0.0.xml can be found here: /volatile/halld/home/shannen/generators/pi0/prim/para7/hddm — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWARXJSIK3P5NX56I3D4K3CAHAVCNFSM6AAAAACUHZGBJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRWGE4TQNRZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ShannenUmassJlab]

@rjones30 Interestingly the pi0 momentum when I run hddm-xml is non-zero, but hddm-xml crashes with the following error:

The command I ran for this is as follows: hddm-xml /volatile/halld/home/shannen/generators/pi0/prim/para6/hddm/gen_amp_101494_000.hddm

Sorry for the delayed reply

[aaust]

This is the same error I found in the single track reconstruction test. I opened an issue in JeffersonLab/HDGeant4#235 , but it looks like it might be a more general problem.

[rjones30]

Please build with updated HDDM and verify that it works. I can tell you that it does, but not if you are running with an outdated HDDM. If the HDDM writer is broken then what is written by the generator into the hddm file is bad. If the writer is fixed and hddm-xml shows good momenta, it will still not read correctly if the reader is bad. In other words, both the generator and the simulator and the analyzer have to be built with a working release of HDDM. I have tested this myself end-to-end and verified it works. If it is not easy to figure out how to build everything with an updated HDDM, let's organize a zoom session and walk through it together.

…

-Richard Jones

-Richard Jones

On Thu, Feb 19, 2026 at 5:01 PM Alexander Austregesilo < ***@***.***> wrote: *aaust* left a comment (JeffersonLab/halld_recon#1096) <#1096 (comment)> This is the same error I found in the single track reconstruction test. I opened an issue in JeffersonLab/HDGeant4#235 <JeffersonLab/HDGeant4#235> , but it looks like it might be a more general problem. — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWEW5VXJ65PWH4YPTVL4MYXFHAVCNFSM6AAAAACUHZGBJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZQGM4DANRZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aaust]

Do you mean the the main branch on https://github.com/rjones30/HDDM or the latest release hddm 5.1.0?

The nightly build uses hddm 5.1.0 and builds all packages with this dependency. You can check by sourcing this environment:
source /group/halld/Software/build_scripts/gluex_env_nightly.sh 2026-02-20

With this environment, I was still able to run hdgeant4 and produce an hddm file that shows this error:

cd /volatile/halld/aaustreg/single_track/tmp/
hdgeant4
hddm-xml pion1.hddm
            <momentum_double E="1672.77" px="-1.05212" py="0" pz="3.39519e-313" />
hddm-xml : size mismatch in tag momentum_double, remainder is -16, cannot continue.

[rjones30]

That tagged release 5.1.0 is broken. It needs the updates that are in the rjones30/HDDM repo. -Richard Jones

…

On Fri, Feb 20, 2026 at 5:40 PM Alexander Austregesilo < ***@***.***> wrote: *aaust* left a comment (JeffersonLab/halld_recon#1096) <#1096 (comment)> Do you mean the the main branch on https://github.com/rjones30/HDDM or the latest release hddm 5.1.0 <https://github.com/JeffersonLab/HDDM/releases/tag/5.1.0>? The nightly build uses hddm 5.1.0 and builds all packages with this dependency. You can check by sourcing this environment: source /group/halld/Software/build_scripts/gluex_env_nightly.sh 2026-02-20 With this environment, I was still able to run hdgeant4 and produce an hddm file that shows this error: cd /volatile/halld/aaustreg/single_track/tmp/ hdgeant4 hddm-xml pion1.hddm <momentum_double E="1672.77" px="-1.05212" py="0" pz="3.39519e-313" /> hddm-xml : size mismatch in tag momentum_double, remainder is -16, cannot continue. — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWCZ2XTMSZYT5Z6FHND4M6EMLAVCNFSM6AAAAACUHZGBJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZXGQ4DMMJWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aaust]

Thanks for the confirmation. I'll make a new tag to test again.

[aaust]

I rebuilt the entire software stack from scratch with hddm 5.1.1, but I still observe the above described minimal example.
You can source my environment on the ifarm with these 2 commands:

. /work/halld2/home/aaustreg/Analysis/sw/Alma9_7.5.0_hddm_test/gluex_env_boot.sh
. /work/halld2/home/aaustreg/Analysis/sw/Alma9_7.5.0_hddm_test/gluex_env_local.sh

[rjones30]

Ok, let me have a look. Independently, I have tried to build halld_sim from the latest master and I am getting a bunch of compiler errors / warnings that show things like missing headers and buffer overflow bugs. Are these known? -Richard Jones

…

On Mon, Feb 23, 2026 at 10:26 AM Alexander Austregesilo < ***@***.***> wrote: *aaust* left a comment (JeffersonLab/halld_recon#1096) <#1096 (comment)> I rebuilt the entire software stack from scratch with hddm 5.1.1 <https://github.com/JeffersonLab/HDDM/releases/tag/5.1.1>, but I still observe the above described minimal example. You can source my environment on the ifarm with these 2 commands: . /work/halld2/home/aaustreg/Analysis/sw/Alma9_7.5.0_hddm_test/gluex_env_boot.sh . /work/halld2/home/aaustreg/Analysis/sw/Alma9_7.5.0_hddm_test/gluex_env_local.sh — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWGPONKYXIPSTKG6YVD4NMLZLAVCNFSM6AAAAACUHZGBJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBVGQZDSNBSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aaust]

Thank you. The halld_sim master is built every night without errors, but there are a series of warnings that could be addressed. Here is the list of a recent build test:
https://halldweb.jlab.org/pull_request_test/halld_sim%5Efit_options/report_fit_options.txt

[rjones30]

This took quite some effort to diagnose. Several years ago when Mark Ito was leading our software effort, we agreed to pull HDDM out from halld_recon and form a separate git repo for it. At that time, we removed the HDDM library components from halld_recon. Or did we? No, not completely. There still remains a residue from that legacy present in our halld_recon repo at src/external. That xstream source tree with its associated libxstream.a library is present and maintained in the HDDM repo, but an unmaintained copy of it still remains in our halld_recon/src/external/ tree as well. That residual halld_recon/src/external still gets used to build a local copy of libxstream.a when we do "scons install" in halld_recon/src, resulting in two copies of libxtream.a, the maintained one that gets built and installed by cmake at HDDM_DIR/lib and the unmaintained one that gets automatically built and installed by scons in halld_recon/$BMS_OSNAME/dir. So which copy of libxstream.a gets used when we link our halld_recon apps? That depends on the order that the lib directories are listed in the link list, and can be different for different apps. In this test case, we were unlucky.

Let's delete external from halld_recon/src and remove it from the build. That way the copy of libxstream.a that is in the HDDM_DIR/lib area will be used, which is the supported version. Alex, let me know if you can do this, or if you want me to submit a PR for it.