FATAL error in unpacker

[ManuelXarepe]

Hello everyone,

I'm "GLAD" to inform you that the changes implemented in the #712 are working as intended. I checked the unpacker that we used for the S522 and S509 experiments and a FATAL exception is thrown due to an error when mapping some items.

The failed mapped items are the ones related to MWPC3/4, and the problem arises from the fact that in our experiment we only use 2 MWPC detectors, but in the ext_...hh file for the mwpc detectors all 4 MWPC are mapped together.

This means that even though we use the setter in the reader class for the mwpc that sets the max number of detectors, mwpcreader->SetMaxNbDet(2); it still throws the FATAL exception.

To Reproduce
Steps to reproduce the behavior:

1. Use most recent R3BRoot version
2. Did not test with other unpackers but you should see this with any experiment unpacker that uses less than 4 MWPC.

Expected behavior
It should just give a FATAL exception and stop the unpacker macro, also a list of what is not mapped should appear before

Logs / Screenshots

System information (please complete the following information):
I was running on GSI machines

[jose-luis-rs]

In R3BRoot/r3bsource/base/R3BUcesbSource.cxx

Look for the lines:

        R3BLOG(fatal,
               "ext_data_clnt::setup() mapping failure may "
               "cause unexpected analysis results due to missing "
               "data members. Unpacker needs fixing.");

and change R3BLOG(fatal, ... by R3BLOG(error,...

[ManuelXarepe]

Thank you for the fast response. To be clear what you are suggesting is to open a PR with this change, which is essentially reverting #712?

[ManuelXarepe]

I apologize, as I had not read through the entire discussion on #712 before, and just went through it now. If I understood correctly from #712 (comment), the proposal is to do a local modification that changes the R3BLOG(fatal, back to R3BLOG(error,.

I am afraid, however, this is not a sustainable solution long term. I believe that other people will also run into this issue and maintaining local changes that are not merged long-term can become messy and difficult to maintain. It will also generate many requests for support as students encounter this issue and don't know how to fix it.

I am a little out of my depth here, but if we were able to find a solution for the underlying issue, which is that different experiments required a different set of ext_* files, it would be ideal.

My naive solution would be to divide this ext_file in 4 different ext files, treating each MWPC as a different detector, all being called by the same reader class. However, I don't really know how this would be implemented. Is this even a feasible solution?

I will change the code as you suggested in my working environment for now, to unblock me, but will keep this issue open so that we can discuss a better solution.

[klenze]

This issue was anticipated by me and discussed here.

Personally, I do not particularly like the nested arrays (implemented by ntuples which have indices as part of their name) and would prefer to move to a flat structures like CALIFA does. This involves a bijection between ${\mathbb{N}_0}^m$ and $\mathbb{N}_0$ (e.g. an absolute channel index), but such have been known to exist since Cantor.

The main problem is that is such changes have to be synchronized between the unpackers and R3BRoot, which is non-trivial.