Introduce a reduced-LDMX geometry (ECAL and tracker, no magnet)

[tvami]

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

What are the issues that this addresses?

This resolves #1267

Check List

• I successfully compiled ldmx-sw with my developments

• I ran my developments and the following shows that they are successful.

With the magnet:

We ran the pn config https://github.com/LDMX-Software/ldmx-sw/blob/trunk/.github/validation_samples/ecal_pn/config.py
with changing to the following line:

mySim = ecal.photo_nuclear('ldmx-reduced-v1',gen.single_4gev_e_upstream_tagger())

which then outputs

...
[ EcalProcessFilter ]: 97 Brem photon produced 20 particle via biasWrapper(photonNuclear) process.
[ EcalProcessFilter ]: 98 Brem photon produced 8 particle via biasWrapper(photonNuclear) process.
[ EcalProcessFilter ]: 99 Brem photon produced 15 particle via biasWrapper(photonNuclear) process.
[ EcalProcessFilter ]: 100 Brem photon produced 11 particle via biasWrapper(photonNuclear) process.
[ Simulator ] : Started 6961 events to produce 100 events.

Then a full stats physics study of the WABs was carried out with this reduced geometry and will be presented at the SWAN meeting:
https://indico.fnal.gov/event/63722/#18-wide-angle-brem-studies-at

Without the magnet:

Ran electron gun for a technical test located in Detectors/test/reducedLDMX_eGun_config.py
Further physics studies will be done later, this already proves that the geometry works as expected.

Most of this work was done by @SanjitMasanam

• I attached any sub-module related changes to this PR.

In Ecal submodule the number of layers are not hardcoded anymore thanks to
LDMX-Software/Ecal#52

[bryngemark]

thanks for starting this work! I think, before we pull this in, we should consolidate an ESA setup.

• the hcal prototype used at the cern testbeam will for sure be there, it's already in ESA. you can find gdmls for that detector geometry in hcal-prototype-v2.
• that geometry also has a one-pad TS, 12 bars, which is likely closer to what we'll see in ESA (rather than the full LDMX three-module setup).
• will there be a target?
• what about the tracker, will there be recoil and tagger tracker, or just a few layers? axial or stereo?
• the magnet, is that something we'll have?

i fully anticipate that the answers to this will change but i don't expect it to be anything close to the full LDMX with only a reduced ecal.

[tvami]

Thanks @bryngemark for your comments!

• the issue with hcal-prototype-v2 is that it's structured differently and I dont have enough experience with HCAL to just plug it into this reduced geometry, so I proposed to do this in two steps where the demo HCAL is added later on
• ok that's good to know about the TS, we can change that
• for now in this PR we removed the tagger tracker and kept 2 layers of the recoil tracker
• we are about to remove the magnet

I should add that I was thinking of having this in several PRs (i.e. add tracker + ECAL first, which then allows studies with the ECAL, etc), but now I understand that the preference is more to have everything ready and pull a more complete picture in. Is that right?

[therwig]

My 2c:

• its probably OK for HCal to come in v2 of this new detector configuration if the rest is ready. I am kind of assuming that this geometry will be a bit unstable in any case, thinking we might want to, e.g., move layers forward/backward wrt the target.
• It might be worth keeping multiple TS layers in, if this is something we might possibly want to include. (I'd think it would be useful for TS studies and is probably something we could realistically do on the ESA timescale. easier to have it there and then ignore 2/3 planes if need be.) the cost is just a little extra material from the extra modules.

[bryngemark]

thanks for thinking with me. i agree the TS geometry is probably more likely to be expanded so we can leave several in; their exact location is probably anyone's guess though? for the hcal, on the contrary, i think it will be exactly as at cern so there i thought pulling it in would be easy. its location in z will likely be farther back (for the cern testbeam, the origin was placed at the center of the hcal but i think this should or could be a simple offset defined as one of the constants). pulling @EinarElen in here, as he was working the most closely with peter on the cern testbeam geometry.

[tvami]

Regarding the magnet we had a little conversation in #1274 but this is a more natural place for that conversation @tomeichlersmith

Without the magnetic field, the normal beam electron will be shot at such a wide angle that it will entirely miss the detector.

We are looking at WAB signal so the angles are wide but they should still reach the detector. And we can exclude that the effect is from gen.single_4gev_e_upstream_tagger(). Maybe we could look at the LHE level angle distribitions @SanjitMasanam

[therwig]

Hi @tvami ah right sorry you learned this the hard way :) Indeed we probably want to do something like

myGun = gen.single_4gev_e_upstream_tagger()
myGun.position = [0,0,-6000]
myGun.momentum = [0,0,4000]

this could also be packaged into a new gun that could be automatically loaded if you prefer.

[therwig]

but I think this is independent of the new geometry (and thus this PR, except that it would be good to test of course)

[therwig]

values are based on
https://github.com/LDMX-Software/SimCore/blob/trunk/python/generators.py.in#L196-L252

[tvami]

Thanks for the suggestion Christian, we can do that as a test and if it works then push the no-magnet situation in this PR. After that I think this PR is ready to go from my side. If it's easy for @EinarElen maybe he could plug in the demo HCAL here, otherwise that could be another PR IMO.

[tvami]

OK so the gun works nicely as expected! I pushed the commit that removes the magnet, with this from my side this is ready to be merged.

[therwig]

I made a quick check, generating some events with the test config. One thing I noticed was that "trigger pad 3" doesn't appear to have any hits. Assuming I didn't make some mistake, maybe @bryngemark should advise us on how they should be positioned in the bending plane for the B=0 setup? I guess an offset is no longer needed for B=0T. (Is it just x=0 for everything? Confusing to me, it seems that pads1, 2, 3 have x=-43, -38, 0 however we see hits in 1 and 2 but not 3)

[tvami]

however we see hits in 1 and 2 but not 3)

I saw that too, but also to add to the confusion, I think there are digis in pad (3) just no clusters. But this could just be noise...

[therwig]

Yes though the digis appear to be "null" ones, at least for me. Probably we need to center the TS modules on the beamline

[therwig]

maybe something simple like setting x to "1/2 of a bar length" instead of 0? I don't know where the volume starts measuring from..

[tvami]

We are looking at WAB signal so the angles are wide but they should still reach the detector.

Just a heads-up that this worked for me after all! So now we have two example where the reduced geometry works

[bryngemark]

Not sure if the TS confusion is still there? Some notes:

• yes with a beam of normal incidence and no bending, no offset in x is needed
• in the gdml and in G4 generically, all positions are "half values"; setting x=0 means we center the pad on the beam axis
• if there are no clusters, this may be a time cut effect in clustering in itself; i'd focus on seeing hits (even simhits are good enough) since everything downstream of that is reco and should be decoupled from introducing the geometry. specific changes to parameters can be done for the reco in a config later.
• for digi, good hits are somewhere around 80PE (~double in clusters) or 0.3MeV in edep, noise is just a steeply falling distribution on the low end. there is a flag isNoise_ for hits, too, to check this.

another question, why a 4 GeV beam?

[EinarElen]

Hi everyone,

I don't think adding in the Hcal prototype would be too hard but I don't have the time to do it right now so if you don't need it for current studies id also keep it for later!

Otoh if you want to add it and have questions about the structure, just ask and I'll help out!

[tvami]

why a 4 GeV beam?

in 2025 my understanding is that we wont have the 8 GeV beam yet. Is that not the case? @bryngemark

[bryngemark]

tbh i don't know what the accelerator folks are planning... my interpretation is that LCLS-II is getting upgraded before we get anything in place, but i might be wrong. let's ask people in meetings this week? unless someone on this thread knows.

[therwig]

I can confirm that it is 4 GEV. The idea is to take a little bit of data before the high energy upgrade to the linac late next year. But yes, schedules are always a bit uncertain 😊

[therwig]

OK, I'm still confused about the 3rd TS pad. I don't see sim hits, but possible that I'm doing something wrong. Given this input from LK I might suggest shifting all of the pads to x=0 if thats where they're supposed to be, but we can leave any further optimization/studies for the future (along with HCal work).

[tvami]

ok so:

• single_4gev_e_upstream_tagger does not have the needed mom and pos functions, so those didnt do anything --> as a consequence the electron still followed a curved path --> solution: move to a real gun, see 3638922
• I moved all the TS to zero in X in 653e0a8, and I see sim hits in all the TS. I attach a plot that nicely shows the simhits as a function of Z

[bryngemark]

OK looks good! On second thought the beam energy matters less for geometry validation when there is no B-field 😄