NDLAr flow workflow

[alexbooth92]

This PR brings the "first" version of an ndlar_flow workflow for a full NDLAr geometry into develop. An important thing to note for this PR is that nothing here will have any impact on the 2x2 workflow unless a user wants it to.

Things are set up such that, with the exception of the geometry resource, all resources that are used are the protons_nd_flow ones (the ones used by 2x2) with NDLAr specific configurations where necessary. For example:

yamls/ndlar_flow/workflows/charge/charge_event_building.yaml

points back to

raw_event_generator: # groups time-sorted data packets from larpix datalog files
  !include yamls/ndlar_flow/reco/charge/RawEventGenerator.yaml

which in turn points back to

yamls/ndlar_flow/reco/charge/RawEventGenerator.yaml.

The module pointed back to in this yaml from proto_nd_flow

path: proto_nd_flow.reco.charge.raw_event_generator

but one of the parameter is changed to be NDLAr appropriate

  event_builder_config:
    window: 3000 # ExtTrigRawEventBuilder

As originally suggested by @krwood, the geometry service can (and should in the future) be used as a common, detector agnostic version of the 2x2 hardcoded proto_nd_flow/resources/geometry.py. For now it is only tested with full NDLAr.

I gave a talk at the May collaboration meeting discussing these changes in detail (with a full suite of validation plots).

Work since then has been tweaks - bringing the branch up to date with develop and testing with updated inputs. A latest set of validation plots can be found at docdb-31528 in the pdf MicroProd*flow* (minus any plots using calib_final_hits since, like 2x2, the 5th charge workflow is not being run).

[krwood]

Looks good to me. There are a couple of empty.yaml files that may not need to be committed

[alexbooth92]

Looks good to me. There are a couple of empty.yaml files that may not need to be committed

Thanks Kevin! Regarding the empty yamls I was taking the lead from here - I thought maybe important for the build or running h5flow.