Hi Jeremy.
The RvnCC1pi parameter affects several aspects of the simulation for free nucleon targets
(CC inclusive xsec, CC1pi xsec, hadronization) and, of course, impacts the simulation for nuclear targets.
I do not object to any change, given there is sufficient evidence to back it up.
By evidence, I mean data/MC comparisons produced by GENIE.
I admit I do not know what data/MC comparisons Rodrigues et al. actually checked, but I would
be ready to bet that their tune breaks at least as many data/MC comparisons as it fixes.
Looking at https://dl.dropboxusercontent.com/u/45977020/GENIEv3_characterization_v1.0.pdf
I note that perhaps we do not do such a great job for free nucleon data CC 1pi+ (pages 43,44)
but other distributions are spot on (for example, the probability to get 1 charged hadron in neutrino
interactions, page 317). The comparisons to inclusive CC cross-section data for an isoscalar
free nucleon target don’t look bad either (page 21). Comparisons with MiniBooNE CC1pi+
(pages 121 onwards), MiniBooNE CC1pi0 (page 259 onwards), T2K numu CC inclusive
(page 284 onwards) do not look bad either. So if we want to tweak RvnCC1pi in v3.0.0,
we need a comprehensive evaluation of its effect.
About your question: The R{v,vbar}{n,p}{CC,NC}{1,2}pi knobs correspond to the parameters
listed in lines 602-617 in:
https://genie.hepforge.org/trac/browser/generator/trunk/config/UserPhysicsOptions.xml
They are used by the DIS cross-section model - the method in line 238 in
https://genie.hepforge.org/trac/browser/generator/trunk/src/PartonModel/QPMDISPXSec.cxx
The *same* parameters also affect hadronization - line 406 in
https://genie.hepforge.org/trac/browser/generator/trunk/src/Fragmentation/KNOHadronization.cxx
and you can find the actual application of these parameters in line 84 onwards in
https://genie.hepforge.org/trac/browser/generator/trunk/src/Fragmentation/HadronizationModelBase.cxx
Not sure I get the flavour of the comment about duty to clean up reweighing,
and tweaking knobs that don't correspond to changes that we can identify with parameters
we want to change, or overlap with other knobs - This is mainly because it is not clear who “we” is.
Most emphatically, the reweighing package is not a production-level package with a complete
systematic error analysis for our default (or any other) model.
Several important uncertainties are not captured there because they are not reweigtable:
This limits the utility of the reweighing package and should not be advertised as a silver bullet for
propagating all GENIE uncertainties. There are several other weight calculators that can be
configured in multiple and often conflicting ways. There are several ways to include the same uncertainty.
This is because there is no single way people go about evaluating the effect of an uncertainty.
In addition, weight calculators have varying degrees of validation and certainly, they are not tested as
part of our release validation. Not only they can be broken, some of them are unfinished and have no effect.
But I am confident that since the reweighting infrastructure is critical to Fermilab experiments,
they do not use these tools blindly and they carefully evaluate their correctness and validity.
cheers
C.
On 22 Nov 2016, at 19:46, Jeremy Wolcott <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi Costas,
Since we didn't have a chance to discuss this further this morning:
a point was made before that no one actually runs with free nucleon
targets. A change to reproduce ANL/BNL in the default tune is by
itself unwarranted if not supported by comparisons to nuclear data.
So we need to study the suggested model configurations against all
data, before deciding whether we want to introduce a similar change
in one or more configurations (default or not).
The issue was not unknown to GENIE before the Rodrigues paper, and
their tuning can not be copied into GENIE as a host of things have
changed wrt to the version of GENIE used by Rodrigues et al. So we
need to investigate our own independent solution. For one, Rodrigues
et al have not investigated -I think- the impact of their tune on
other data/MC comparisons where GENIE did well.
I'll note that anecdotally that the correction Rodrigues et al. suggest via the RvnCC1pi knob does improve agreement with both MINERvA and NOvA ND data.
But I suppose whether it is the right thing to do or not also depends on how the current tuning of the underlying parameters originated. If the underlying parameters were only tuned with bubble chamber data in the first place, or if they correspond simply to free nucleon parameters, then there's basically no reason not to update them, even if they will be corrected again with a more sophisticated tuning effort later.
Which leads me back to the questions from before: what parameters do the R{v,vbar}{n,p}{CC,NC}{1,2}pi knobs actually correspond to? Are there even corresponding parameters that one could directly change in the configuration to get the same effect as these reweight knobs? Or are they somehow related to the Bodek-Yang model parameters that set the DIS production rates? Does that mean there is overlap with the BY reweight knobs? I haven't been able to figure any of this out from reading the code or the documentation, so I was hoping for somebody to offer the history.
I'll echo the comment that Gabe made further down in this thread. The reweighting infrastructure is critical to our Fermilab experiment users, at least, because it's traditionally the only mechanism they use to obtain uncertainties on the neutrino interaction parameters. (You know at least as well as I do, I think, that they can't do a Professor-style generation with different configurations because they can't afford to re-do the expensive detector response simulation and reconstruction stages they need to get fully simulated events.) So if the knobs that we provide are unreasonable, don't correspond to changes that we can identify with parameters we want to change, or overlap with other knobs, I think we're offering the community misinformation and have something of a duty to clean them up.
-Jeremy
|