We'd like to keep the possibility of running the trigger simulation using different versions of triggeralgs (and channelmaps).
Updating dunetrigger/dunetrigger/triggeralgs manually does not allow that, since in the larsoft tag will change for both the triggeralgs and the dunetrigger modules.
A proposal: create a separate repository DUNE/dunetriggeralgs (and DUNE/dunechannelmaps), with tags matching the DUNE-DAQ/triggeralgs ones (therefore, excluded from dunesw), and link them through ups/products_deps or as submodules. By changing the tag there, one can run different versions of triggeralgs within the same dunetrigger version.
However, fcl configuration should take that into account, since parameter names might change. I'm not sure of how, one option could be to have some parent fcls in DUNE/dunetriggeralgs that are imported by triggersim.fcl.
We'd like to keep the possibility of running the trigger simulation using different versions of
triggeralgs(andchannelmaps).Updating
dunetrigger/dunetrigger/triggeralgsmanually does not allow that, since in the larsoft tag will change for both the triggeralgs and the dunetrigger modules.A proposal: create a separate repository DUNE/dunetriggeralgs (and DUNE/dunechannelmaps), with tags matching the DUNE-DAQ/triggeralgs ones (therefore, excluded from dunesw), and link them through
ups/products_depsor as submodules. By changing the tag there, one can run different versions oftriggeralgswithin the same dunetrigger version.However, fcl configuration should take that into account, since parameter names might change. I'm not sure of how, one option could be to have some parent fcls in
DUNE/dunetriggeralgsthat are imported bytriggersim.fcl.