add Calorimeter detector and output scheme

[gipert]

I'm a bit unsatisfied by the fact that we still have a jagged energy structure in the output, even if I would like to store only the total energy deposited. I'm not sure we want to implement an exception for this scheme though.

[tdixon97]

I agree with your dissatisfaction

[tdixon97]

I think it is worth storing this as flat, since it allows some users to read it in with numpy or pandas, for some applications I think its a nice selling point for remage, and a way to convince people that LH5 file output is maybe fine for them.

[gipert]

Thank you @ManuelHu for checking I can fix (or someone else can take over if they have time).

The question now is how to flatten this array in the python wrapper without implementing ugly things. Any idea?

[tdixon97]

• custom reboost config? (just ak.flatten() one each)
• detect that a VoV is really 1D and automatically flatten?

[gipert]

The question is how do we identify the calorimeter table. at the moment it differs just for the field names.

[ManuelHu]

you have not only the field names, but the name of the output scheme for each table available in the output scheme

[gipert]

You mean via IPC?

[ManuelHu]

yes, this info is sent via IPC:

remage/src/RMGOutputManager.cc

Lines 64 to 66 in 3ab5091

	RMGIpc::SendIpcNonBlocking(
	RMGIpc::CreateMessage("output_ntuple", std::string(oscheme).append("\x1e").append(table_name))
	);

[gipert]

This should be now good, I just need to add some tests

[gipert]

I realized that the unflattening doesn't make sense (actually creates problems) if the user requested all the detectors to be in one single table and more than a calorimeter is defined... What should we do?

[EricMEsch]

I dont understand the logic here. So there is only ever 1 hit in the Calorimeter hit collection?

And this hit sums the energy, but keeps only the physical volume, uid and time of the last hit?

So what is even the use of tracking the last physical volume etc.?

[EricMEsch]

Also the timestamp of the last hit is completly random. It is not even guaranteed to be the last hit in time, as the time sequence does not play any role for the order in which G4 tracks particles

[gipert]

yeah good point, we might just keep all values and store the lowest time at the end.

[EricMEsch]

That would also be more useful for custom outputschemes. As a customscheme would have access to the hitcollection and can then just store away any time wanted.

And i think you would need a new hit for each hit anyways if you want to differentiate between the different registered calorimeters

[EricMEsch]

The way it is written now, shouldnt there always only be one entry per event? So after the unflattening there would always just be one entry no matter what?

And if the user requested all of the calorimeters to be in a single table, that table would contain the det_uid of the last hit.

On the other hand, requesting one table per calorimeter would not really make sense, as there would only be an entry for one of the calorimeters in which the last hit occured? And that entry would contain the total energy of all calorimeters?

Am i misunderstanding the current implementation?