FIX: Clean up the module ordering for the FITS and L0 savers

[mwy-wing]

This PR addresses issues from #198 . I made a few changes to how the module picking behaves:

1. The generic MModuleSaverMeasurementsFITS is removed, since it was redundant. I also removed the m_OutputDataLevelCombo, because it is no longer needed.
2. The L0 saver is now available only after an event loader and the DEE.
3. The L1a saver now needs to immediately follow a measurement loader, so it does not appear after the calibration steps.
4. The L1b and L2 savers come after strip pairing, depth calibration, and event reconstruction.

[mwy-wing]

The tests failed because ImmediatelyPreceeding and SetTypeExclusive are new features I added to MEGAlib.
We should only merge this PR after zoglauer/megalib#127.

[zoglauer]

Mark it as draft - I take a look at the MEGAlib PR either tonight or tomorrow

[fhagemann]

Just checking: is it correct to have me as reviewer on this?
I haven't worked on FITS/L0 savers before.

[zoglauer]

OK.
Try with that Nuclearizer version:
https://github.com/zoglauer/megalib/tree/feature/supervisor-hardening

[zoglauer]

@fhagemann : I want you to test this PR with the new MEGAlib version https://github.com/zoglauer/megalib/tree/feature/supervisor-hardening
If that does not cause any issues with how you use Nuclearizer.
There are lots of changes in MSupervisor and MModule, which were triggered by Wings changes, and I just want to make sure it still works for everybody.

[fhagemann]

EDIT: Seems like it didn't pull all the latest commits from feature/supervisor-hardening, pulled again and will retry.

I can't get nuclearizer with the code in this PR to compile, even after updating megalib to feature/supervisor-hardening:

src/MModuleSaverMeasurementsL0.cxx:77:3: error: ‘SetTypeExclusive’ was not declared in this scope
   77 |   SetTypeExclusive(false);
[...]
src/MModuleSaverMeasurementsFITS.cxx:85:3: error: ‘SetTypeExclusive’ was not declared in this scope
   85 |   SetTypeExclusive(false);
      |   ^~~~~~~~~~~~~~~~
src/MModuleSaverMeasurementsFITS.cxx: In member function ‘void MModuleSaverMeasurementsFITS::ConfigurePreceedingModules()’:
src/MModuleSaverMeasurementsFITS.cxx:156:3: error: ‘ClearPreceedingModuleTypes’ was not declared in this scope; did you mean ‘GetNPreceedingModuleTypes’?
  156 |   ClearPreceedingModuleTypes();
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |   GetNPreceedingModuleTypes
src/MModuleSaverMeasurementsFITS.cxx:160:28: error: no matching function for call to ‘MModuleSaverMeasurementsFITS::AddPreceedingModuleType(const uint64_t&, bool, bool)’
  160 |     AddPreceedingModuleType(MAssembly::c_EventLoaderMeasurement, true, true);
      |     ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
make[1]: *** [Makefile:175: ~/Software/COSItools/megalib/lib/MModuleSaverMeasurementsFITS.o] Error 1
make: *** [Makefile:133: all] Error 2

[fhagemann]

I can get it compile, and I can only select the FITS module in the following combination of preceding modules
(I did not run anything, just checking that I can select modules):

L0

I can select L0 anytime after loading simulations and applying the DEE, regardless if I add further steps in the forward pipeline after it. I cannot add any modules after L0. Are both of these behaviors intended?

Case 1	Case 2	Case 3

L1a

It seems like I can only select L1a after choosing a data loader module

L1b / L2

Both appear after applying energy/TAC calibration, strip pairing, depth calibration and event reconstruction (Revan)

[fhagemann]

I can test if this affect how I run nuclearizer tomorrow 😉

[mwy-wing]

Hi Felix,
L1a, L1b, and L2 all look as intended.

For L0, when I designed this I was mostly thinking of the Case 1 scenario, where we write the simulation straight to a file without running any calibration or the rest of the pipeline. We could enforce Case 1 by requiring the DEE to be immediately before the L0 saver: AddPreceedingModuleType(MAssembly::c_DetectorEffectsEngine, true, true); Thanks for catching this.

@zoglauer @ckierans Does the Case 1 scenario also match what you were thinking for the L0 pipeline?

[zoglauer]

Yes, I think the L0 saver was exactly designed for case 1.

[fhagemann]

I was able to run the DEE after updating megalib to feature/supervisor-hardening and using this PR.
However, removing m_PreceedingModulesHardRequirement in feature/supervisor-hardening resulted in some errors when switching to other branches in nuclearizer, without downgrading megalib to the current develop-cosi.

If we want to merge this, I would suggest to merge this PR and feature/supervisor-handling at the same time, and require everyone to update megalib and to rebase their branches on top of this PR.

[fhagemann]

Whatever changes we have to make after merging the changes in megalib/feature/supervisor-hardening should be added to BOTH nuclearizer/develop/em, but also nuclearizer/main.
(I think we had this in the past, where updating nuclearizer/develop/em but not nuclearizer/main led to people installing "fresh" megalib/nuclearizer using cosi-setup to have compilation errors)