MC truth y offset

[mjkramer]

ndlar_flow/src/proto_nd_flow/reco/charge/raw_event_generator.py

Line 145 in fb1fc2a

tracks_copy[field] = (tracks[field] + 21.8236) #* units.cm

L158 L172

We're adding an offset of 21.8236 cm to the y coordinates in the truth datasets. This looks like a holdover from one of Peter's old analyses. We should probably get rid of it, but maybe I'm missing something.

[mjkramer]

Hijacking this issue as a braindump: We're also swapping x and z (with the goal of achieving "z = beam"), but at this point larnd-sim is already writing all of the truth with "z = beam".

[peter-madigan]

Yes, all of the funny business here is done to fix the old inconsistent coordinate system from the larnd-sim files (which had different origins / units / coordinate axes between the trajectories and the tracks). These are both safe to remove for the future.

[peter-madigan]

On the topic of units, I outlined a unit system in util/units.py that could be helpful as long as it is religiously followed when you read in data from "non-ndlar_flow" objects (e.g. config files / larnd-sim files / etc).
E.g. whenever you read in a value from something outside of ndlar_flow, you multiply by the appropriate units:
p_ndlar_flow = p_larnd_sim_file * units.MeV
pixel_x_ndlar_flow = pixel_yaml_value * units.mm
Then it's pretty straightforward to set the global unit system (just update what units.mm is), or to be able to specify units in config files (getattr(units, unit_spec)).

I can't say that I successfully did this in all of my code but always better to try and start off on the right foot.

[cuddandr]

Yeah, that was the plan in a future commit once I got more feedback on what units we wanted (or silent approval). The current state was to get files out now for reco development.