Introduce `ldmx-lyso-r1-v14-8gev`

[tvami]

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This resolves https://github.com/LDMX-Software/ldmx-sw/issues/1228 and introduces a new geom where the target is LYSO (taken from ldmx-lyso-v12) but everything else is v14.

Also resolves https://github.com/LDMX-Software/ldmx-sw/issues/1226

New signal libraries with all the elements for LYSO were generated by @Art5140:

• 100k of 1 MeV
• 100k of 10 MeV
• 100k of 100 MeV
• 100k of 1000 MeV This amounts to about 2GB of files.

Question: where should we store those? SLAC? or somewhere in GitHub?

For the validation in ldmx-sw the following config was used: Detectors/test/lyso_signal_10MeV_config.py the results will be shown at a SWAN / sw-dev meeting in the near future.

Check List

• [x] I successfully compiled ldmx-sw with my developments
• [x] I ran my developments and the following shows that they are successful.
• [x] I attached any sub-module related changes to this PR. N/A

[bryngemark]

for reference i think most of @joyang8caltech's current ideas for the LYSO layout are outlined here

[tvami]

are copies to a new directory: is this the v14_8gev geometry but simply substituting the LYSO geometry (from the old v12 LYSO geometry) for the W target?

yes, that's correct!

Didnt talk to James yet, for now we were more interested in the general concept of having signal produced on LYSO and plugging that into LDMX. @joyang8caltech, if you have any geometry files instead of what's in v12, I'm happy to include it here.

For the signal production we used the dark-brem-lib-gen after the PR https://github.com/LDMX-Software/dark-brem-lib-gen/pull/17 is merged, and then ran https://github.com/LDMX-Software/dark-brem-lib-gen/blob/main/context/db-lib-gen.py with ``` --target ['lutetium','yttrium','silicon','oxygen'] --max_energy 8 --nevents 100000 --apmass 1 (and then 0.1,0.01,0.001)

[tomeichlersmith]

Just to chime in here about dark-brem-lib-gen. I'm 95% sure that @bryngemark is using the equivalent of v4.5 of dark-brem-lib-gen and @tvami is using the equivalent of v4.6. Unfortunately, since this was one of my first containerization projects (pre-dating ldmx-sw adoption iirc) and I haven't gotten around to updating it, the labels on the images are rather uninformative, so please update to a tagged version for future production.

[bryngemark]

Just to chime in here about dark-brem-lib-gen. I'm 95% sure that @bryngemark is using the equivalent of v4.5 of dark-brem-lib-gen and @tvami is using the equivalent of v4.6. Unfortunately, since this was one of my first containerization projects (pre-dating ldmx-sw adoption iirc) and I haven't gotten around to updating it, the labels on the images are rather uninformative, so please update to a tagged version for future production.

Thanks @tomeichlersmith. I'll probably get back to you on this for general syntax etc. One thing that's not clear to me: do I need to build a separate image or is this functionality now pulled into any recent ldmx production image?

[tomeichlersmith]

do I need to build a separate image or is this functionality now pulled into any recent ldmx production image?

Short Answer: Yes apptainer build ldmx-software_dark-brem-lib-gen_v4.6.sif docker://ldmx/dark-brem-lib-gen:v4.6

Long Answer

The `dark-brem-lib-gen` image contains MadGraph4 which has been strongly deprecated, so much so that [it appears to only be available for new download by "people in the know"](https://answers.launchpad.net/mg5amcnlo/+question/689425). [There has been some investigation into updating to MadGraph5](https://github.com/LDMX-Software/dark-brem-lib-gen/issues/3), but nobody has had time to thoroughly check the physics to make sure it wouldn't change (or the changes are well motivated). The reason this is important is because MadGraph4 is not compatible with newer versions of GNU Fortran[1] and so we need to keep it isolated so that it can have the older Fortran version running with it. In addition, the overall design of how the user interacts with the container is different, so even if we could run the MG4 context from within the ldmx/dev image, we would need to refactor the [core python script](https://github.com/LDMX-Software/dark-brem-lib-gen/blob/main/context/db-lib-gen.py) that manages the several MG4 runs required to generate a library. I could imagine this being done, but - for the reasons above - I think it should wait until at least after the context is updated to MG5. [1]: I haven't thoroughly checked this. I just remember seeing fortran errors when trying to run the MG4 context in that library on bare metal on my Ubuntu 22.04 machine a while back.

[bryngemark]

Long Answer thanks @tomeichlersmith for writing the long answer here, for the benefit of myself and future me :D i can confirm seeing fortran errors when trying to build way back, maybe even on an ubuntu 16.04.

this split makes sense to me. i wonder if comparisons between MG4 and 5 aren't due also for reasons of comparing to theorist's simulations of newer models (e.g. spin-1 DM); thoughts on this @EinarElen ? if we should devote some effort there then let's make a new issue for it though 😄

[bryngemark]

@tvami proceed as you see fit with the exact LYSO positioning. i would err on the side of getting it right from the start (as right as we can ever be), i think this would improve our performance studies, since especially targetPN is interesting to study with LYSO and it would be unfortunate to have different geometries for signal and other samples. if you are in a hurry, though, you might not want to wait for the final word on this. james and tim are figuring out how to fit LYSO with the TS and tracker. so perhaps check with them if they think it will converge soon enough for your work. email is probably best.

[EinarElen]

There is one already :)

https://github.com/LDMX-Software/dark-brem-lib-gen/issues/3

I think this is something that is worth pushing a bit at soon, as you say most theorists are using MG5 and it is a lot less opaque. But would need some validation procedure

[tvami]

if we should devote some effort there then let's make a new issue for it though 😄

I think this exists here: https://github.com/LDMX-Software/dark-brem-lib-gen/issues/3

I can prob devote some time to validate it.

email is probably best.

A simple google search didnt help me find James's email, can you please share that with me?

[tvami]

I was wondering if we should name this so it allows the evolution of the LYSO independently of the evolution of the det geometry (i.e. v14 stays but we have something else as an addition) Can we do something like ldmx-lyso-w1-v14-8gev (other naming conventions are welcome too of course), or there is something in the code that will break by adding an extra block? @tomeichlersmith

[tomeichlersmith]

I like that idea @tvami !

Nothing to my knowledge relies on the blocks separated by -, the geometry conditions use regex to match conditions with named geometries so adding a new block should function normally.

[tvami]

Great thanks Tom!

(other naming conventions are welcome too of course)

Something else I can think of is

ldmx-lyso-r1-v14-8gev

where the r can be short for "revision"

[bryngemark]

@tvami i also support r over w so there's no confusion with W, since the LYSO geometry is after all changing the target material

[tvami]

hi @bryngemark , all, so should we merge this as r1 and then when James comes back to me with more details add those whenever they come as r2?

[bryngemark]

sounds very sensible to me

[tvami]

ok tested again with the new name using

Detectors/test/lyso_signal_10MeV_config.py

it's all good!