Hi Costas-
Sure, I'll put it on my list. I've got a bunch of NOvA things on my
plate this week but I'll get to it as soon as I can.
-Jeremy
On 11/28/2016 09:07 AM, [log in to unmask] wrote:
> Hi Jeremy
>
> no correction is implemented in the data archive.
>
> Would you like to do that? ( keeping the old dataset but adding an `ANL (corrected)’
> dataset or something ). Then we will then plug this into the revised set of data/MC comparisons
> as we move them into the new fmwk this week.
>
> To add a new dataset:
>
> - Add a text file with the data here:
> https://genie.hepforge.org/trac/browser/comparisons/trunk/data/measurements/vA/intg_xsec/archive
> Well, here, in particular:
> https://genie.hepforge.org/trac/browser/comparisons/trunk/data/measurements/vA/intg_xsec/archive/ccpi
>
> It is a very simple text file you need to add, defining the energy bins, the xsec central value and xsec errors.
> Look up the uncorrected files, which will provide a good starting point.
> The name of the experiment and a numerical ID are both used to define a unique key for each measurement
> (BEBC,2, BEBC,3, BEBC,16) - Please sure you add an unused ID for any new ANL or BNL datasets
> (whichever one was tweaked - can’t recall now)
>
> If you want add any new references here (optional):
> https://genie.hepforge.org/trac/browser/comparisons/trunk/data/measurements/vA/intg_xsec/archive/references.bib
>
> Also, add your new datasets in the summary file here:
> https://genie.hepforge.org/trac/browser/comparisons/trunk/data/measurements/vA/intg_xsec/archive/summary.txt
>
> If you run
> https://genie.hepforge.org/trac/browser/comparisons/trunk/data/measurements/vA/intg_xsec/archive/rootify.C
> it will read summary file and all data files with experimental measurements and it will re-generate
> the ROOT data file used for storing those historical datasets.
>
> Cheers
> Costas
>
>
> On 23 Nov 2016, at 14:03, Jeremy Wolcott <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>
> Hi again Costas,
>
> 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.
>
> I think at this point we're sort of in "violent agreement" -- mostly I want to make sure we have a look at this. Rodrigues et al. have pointed out a discrepancy whose resolution seems to improve the prediction for at least some current experiments, and possibly reduce the uncertainties, and I want to make sure we learn what we can from it. Once the MINERvA comparisons are working again maybe I will see if I can look at some comparisons (including the ones you suggest above) with the nominal and suggested retuned versions of the parameter.
>
> By the way--- hopefully the ANL & BNL data sets in the comparisons framework have been corrected according to their previous paper, in which they resolved the discrepancy between them?
>
> 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
>
> Thanks. Is there a prescriptive way of determining which configuration parameters correspond to the reweight knobs, for my future reference?
>
> 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.
>
> Agreed, I probably went too far in calling it a "duty." I think what I wanted to emphasize is that the reweighting machinery has proved to be exceptionally useful for running experiments, particularly the Fermilab ones, and any effort we invest in making the reweighting (1) more obviously correct (including fixing the default 1-sigma knob twist sizes where we recognize they're no longer appropriate) and (2) easier to use correctly will be very valuable contributions to the community.
>
> I wonder if I could propose a goal that might help users make more effective use of the reweighting system: Documentation that describes not only the 1sigma twist magnitudes but also the corresponding rationale for the knobs that exist. (Would make it easier to re-evaluate them when new data becomes available, for instance, and would help users determine whether the 1sigma twists are appropriate for their use cases.) It might also be helpful to point out which configuration parameters correspond to which knobs. I'd be willing to invest the effort to assemble this, though I'd need input from longtime GENIE members to trace back where the uncertainty sizes actually came from.
>
> [It would also be wonderful if we could offer some recommendations as to which parameters---reweightable or not---should be potentially considered as having uncertainties that affect an analysis, though I suspect this is pretty hard to do in a general way.]
>
> -Jeremy
>
>
|
