Linking To Online Trigger Algorithms

[ddrobner]

I've managed to link to the online trigger algs and successfully run the ADCSimpleWindow TA alg from it. Currently the triggeralgs are set up as a local product in my development environment in a somewhat hacky way, so to deploy this we'd need to create a proper offline-versioned package (à la DUNE/dunedetdataformats and DUNE/dunedaqdataformats).

There's also the question of how we want to handle running the linked trigger algs. The approach I've taken to get the ADCSimpleWindow algorithm running is to create a new tool which wraps the DAQ trigger algorithm, but in my opinion doing that for every single algorithm would be tedious and cumbersome.

Alternatively, I was thinking that we could have an alternative implementation of the Trigger{Primitive,Activity,Candidate}MakerTPC modules which handle the wrapping, and use something like a map to associate the parameter strings with the classes (which as far as I can tell is the best way since C++ lacks introspection). If anyone else has suggestions for the best way to do that please let me know.

[ddrobner]

So, it turns out that triggeralgs already has it's own factory classes for all of the different makers. In my last commit I wrote a small wrapper that takes the algorithm name and configuration (as a JSON string) as parameters from the fhicl, and is an art::tool so it can be used as the existing algorithms are. The benefit I see to doing it this way is that if changes are made to the offline trigger modules, it affects both the offline and online algorithms in the same way.

In terms of the algorithm configuration, I don't think we can have each parameter as it's own field in the fhicl job config, since they vary for each algorithm. I think the best generic way to deal with it would be by using json strings, unless there's something else I don't know about.

I can't get the factory registration to work locally, so I wasn't able to test this. I think that will have to wait until packaging is figured out.

[ddrobner]

After some messing around with CMake I managed to get the macros which register the algs with the factory working properly. For now I have the modified version of triggeralgs in my own fork here, but there are more elegant ways to handle this for production.

[ddrobner]

I took a look at the PlaneCoincidence algorithm and it uses a single function from detchannelmaps - I wrote a minimal header (taking only what's required) for the TPCChannelMap interface and an implementation which uses the larsoft geometry service. Still need to test it properly but it works initially at least.

[ddrobner]

I've written a completely new implementation of the TriggerActivityMaker for online algorithms - which properly does associations as well. I was hoping we could just do it as a tool, but since the online algorithm doesn't care about that, we have to do it after the fact.

I've also changed how the algorithm parameters are handled - they are now passed as their own fhicl::parameterset and then a json object is created from the paramters to pass to the algorithm. I think this is cleaner than just giving them a json string - but potentially has some complications if we have parameters that are not numeric types or booleans (although I haven't seen any in the DAQ configuration).

I haven't been able to track down the proper parameters for the run I've been using to test things, so I can't say for certain that it matches the online exactly. That being said the results I'm getting for now are close enough that it doesn't make me think something is going wrong.