<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Hi Thomas,<br>
I do not understand you statements.<br>
</font>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.<br>
However the when running over REST files the kin fitter code is in
halld_recon too and has to be tracked.<br>
are you suggesting to break that part out of halld_recon?<br>
<br>
cheers,<br>
Beni<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/2/19 8:30 AM, Thomas Britton
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:68282537-2EF4-44C4-B0AF-763245F63B25@jlab.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<span style="background-color: rgba(255, 255, 255, 0);">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. </span>
<div><span style="background-color: rgba(255, 255, 255, 0);"><br>
</span></div>
<div><span style="background-color: rgba(255, 255, 255, 0);">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.</span></div>
<br>
<div id="AppleMailSignature" dir="ltr">Thomas Britton</div>
<div dir="ltr"><br>
On May 2, 2019, at 8:11 AM, Peter Pauli <<a
href="mailto:ppauli@jlab.org" moz-do-not-send="true">ppauli@jlab.org</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span class="">Hi everybody,</span>
<blockquote class="" style="margin: 0px 0px 0px 40px; border:
none; padding: 0px;">
</blockquote>
<br class="">
<blockquote class="" style="margin: 0px 0px 0px 40px; border:
none; padding: 0px;">
</blockquote>
<span class="">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</span><span class=""> </span><span
class="">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 </span><span class="">recon-2017_01-ver03_hdr as
e.g. in </span><span class="">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 </span>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.<br class="">
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.<br class="">
<br class="">
Cheers,<br class="">
<div class=""><span class="">Peter</span></div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><span>_______________________________________________</span><br>
<span>Halld-offline mailing list</span><br>
<span><a href="mailto:Halld-offline@jlab.org"
moz-do-not-send="true">Halld-offline@jlab.org</a></span><br>
<span><a
href="https://mailman.jlab.org/mailman/listinfo/halld-offline"
moz-do-not-send="true">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></span></div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Halld-offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></pre>
</blockquote>
<br>
</body>
</html>