[Halld-offline] halld_recon versioning

[Thomas Britton]

The correct long-term solution is to break the analysis things out into its own repository as was done with sim-recon. Remember, sim-recon was split because the reconstruction was really an anchor software set while sim could be rapidly iterated. The same thing applies here. Fortunately this split should be easier in principle as we know how to and The ana bits are less intertwined with the recon bits (although halld_ana would still be dependent on recon).  Moving forward, on the short term, the version sets used in each analysis launch should be recorded and saved in its entirety. MCwrapper could use the second xml or provided reaction filter. Is hd_root un modified if just the analysis bits change? If this is true the Jana configuration file would just need to change. David thinks that if you give a path to a plug-in in the Jana configuration file it will work.

So I propose to split halld_recon to truly leave an anchoring software (split the workflows up). And if the changes really on effects reaction filter (and other plug-ins) then we record the software used in the analysis launches more rigorously and modify the Jana config file to use the specific plugin version appropriate to produce the trees.

Thomas Britton

On May 2, 2019, at 8:11 AM, Peter Pauli <ppauli at jlab.org<mailto:ppauli at jlab.org>> wrote:

Hi everybody,

as Thomas already mentioned in the Analysis and Production meeting yesterday there is a problem the way most people probably use MCwrapper to produce their MC. The version.xml that can be specified contains a halld_recon version that should be chosen to match the halld_recon at the time of data production (for the latest reconstruction of spring17 that would be recon-2017_01-ver03_hdr as e.g. in version_recon-2017_01-ver03_8.xml). So the problem is that the analysis launches that produced the trees afterwards used more recent halld_recon builds with sometimes substantial changes to the analysis libraries. That means that if one produces MC with version_recon-2017_01-ver03_8.xml the reconstruction matches what was used for real data but the trees produced by ReactionFilter will not match what was produced in a subsequent analysis launch.
If this is a big or a small problem is very much channel dependent but surely we all agree that we want to be able to produce our MC such that it matches the trees that we analyse and not just the REST files. A quick fix to this problem is that each individual user needs to check the version.xml used for the analysis launch in question and rerun over the REST files produced by MCwrapper. This should yield the correct trees. Although this will work I don’t think it is a good solution in the long run and we should come up with something better in this working group.

Cheers,
Peter
_______________________________________________
Halld-offline mailing list
Halld-offline at jlab.org<mailto:Halld-offline at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-offline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20190502/e30330cf/attachment.html>