dune / 2x2_sim Goto Github PK

Adapt Sam's DUNE/larnd-sim#153

• Set ARCUBE_ACTIVE_VOLUME to volTPCActive in the convert2h5 spec
• Update TPC offsets in larnd-sim's 2x2 yaml
• Add updated GDMLs to 2x2_sim repo
• Update GDML files (ARCUBE_GEOM etc.) in the nu/rock specs (in fireworks4dune)
• Add MiniRun5-Nu and MiniRun5-Rock sections to GNuMiFlux.xml with <beampos> ( 0, -0.42, 0 ) = ( 0, 0, 1036.48837 ) </beampos>

See https://docs.dunescience.org/cgi-bin/sso/ShowDocument?docid=27141 for suggestions for licensing

As suggested by Zach, update the edep-sim macro to include something like

/edep/hitSeparation volLArActive -1 mm

This should ensure that each hit segment has only one contributing trajectory, which would be good, since we only save one contributor during the HDF5 conversion, so multiple contributors would lead to a loss of information.

ClarkMcGrew/edep-sim@49e0ac9
https://github.com/ClarkMcGrew/edep-sim/blob/0a6975949368dc50c4802f1511f4bbd52d5b7cf9/src/EDepSimSegmentSD.cc#L77
https://github.com/ClarkMcGrew/edep-sim/blob/0a6975949368dc50c4802f1511f4bbd52d5b7cf9/src/EDepSimHitSegment.cc#L96

Add cathodes, anodes, and module boundaries to the 3D validation plots, e.g. to see whether they align with gaps in tracks.

Particle timing precision is dependent on location within file --> at the beginning of file, better timing precision.

Example below:

File # 1 (towards the end)
vertex time: 236400000.0 microseconds
proton time: 236400000.0 microseconds
dt: 0.0 microseconds
vertex to proton start distance: 38.5 centimeters
parent momentum: 183.6 MeV/c

FILE # 2 (towards the beginning)
vertex time: 2.4213922 microseconds
proton time: 2.4286613 microseconds
dt: 0.007269144058227539 microseconds
vertex to proton start distance: 94.7 centimeters
parent momentum: 186.6 MeV/c

The script run-convert2h5/convert_edepsim_roottoh5.py should be moved into larnd-sim. It is producing input h5 files especially formatted to work with larnd-sim and is therefore more appropriate there.

Then the entire run-convert2h5 could be removed and the conversion can happen at the beginning of the run-larnd-sim/run_larnd_sim.sh script.

segments['pdg_id'] is not filled correctly. Will fix it together with 'traj_id' renaming.

The edep-sim ROOT files will usually keep a copy of the GDML geometry in the form of a TGeoManager called EDepSimGeometry. This can be used downstream (e.g., in larnd-sim) as it is a record of the geometry used for making the edep-sim file. One example of this is a larnd-sim PR for getting the TPC offsets from the EDepSimGeometry (DUNE/larnd-sim#153).

However, currently the TGeoManager is not retained after the spill building step, so it cannot be used downstream. The TGeoManager is present in both the rock and nu individual files and the hadd'ed files. I attached two images below taken from a ROOT TBrowser showing the TGeoManager. It should be noted that in the hadd'ed files, it looks like there are 10 copies of the TGeoManager (I think because there are 10 files hadd'ed together). I'm wondering if this is artificially inflating the size of these files, as we only need one. Anyway, I digress.

But after the spill building step, there is no TGeoManager in the file:

I suggest that we retain a copy of the TGeoManager in the spill built file, so that we can keep a record of the geometry in each file. It will also allow the larnd-sim PR#153 to work on new 2x2 files. It looks to me like this can be accomplished by modifying this script to open and save a copy of the TGeoManager: https://github.com/DUNE/2x2_sim/blob/main/run-spill-build/overlaySinglesIntoSpills.C

Quoting Jeremy:

One thing I have discovered in trying to do the GENIE matching without ugly hacks is that the run number saved inside the GENIE files (as opposed to the one we maintain in the filename) is "always" (at least---in the two files I checked 😄) 0. Could we start setting this correctly? I think it's as simple as passing -r <run number> to the gevgen or gevgen_fnal command that's being used

and, actually, I wonder if would make sense to set it to the thing edep-sim is going to use for the offset in the vertexID? (i.e. the "1E6 * TaggedRunId" with "TaggedRunId = RunId + (1E9 if rock else 0)" from https://github.com/DUNE/2x2_sim/wiki/Production-changes-and-validation-findings#file-format-differences)?

If we use the TaggedRunId then we should change the edep-sim run ID to be the same (since that one currently doesn't including the "1E9 if rock" offset).

@cuddandr 's plot of segment lengths shows we have some pretty long hit segments inside the 2x2.

We should put in something into https://github.com/DUNE/2x2_sim/blob/main/run-edep-sim/macros/2x2_beam.mac like:

/edep/hitLength volTPCActive 5 mm
/process/eLoss/StepFunction 0.0001 5 mm
/process/eLoss/StepFunctionMuHad 0.0001 5 mm

@peter-madigan has studied different settings in the past and should be able to advise us on what was used to get good data/mc agreement out of module0,1.