[Halld-offline] halld_recon versioning

[Beni Zihlmann]

Hi Thomas,
I do not understand you statements.
hd_root and hd_anal are based on the same halld_recon code. There is no 
difference other than hd_root will create root trees.
However the when running over REST files the kin fitter code is in 
halld_recon too and has to be  tracked.
are you suggesting to break that part out of halld_recon?

cheers,
Beni





On 5/2/19 8:30 AM, Thomas Britton wrote:
> 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 
>> specifiedcontains 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
>
> _______________________________________________
> Halld-offline mailing list
> 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/23a7959b/attachment-0002.html>