JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for NEUTRINO-MC-CORE Archives


NEUTRINO-MC-CORE Archives

NEUTRINO-MC-CORE Archives


NEUTRINO-MC-CORE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

NEUTRINO-MC-CORE Home

NEUTRINO-MC-CORE Home

NEUTRINO-MC-CORE  November 2016

NEUTRINO-MC-CORE November 2016

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: GENIE mtg to discuss v3/v4 - Nov 22?

From:

Costas Andreopoulos <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Tue, 22 Nov 2016 21:08:03 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (77 lines)

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

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
October 2020
September 2020
August 2020
July 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
July 2018
June 2018
May 2018
April 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
August 2016
June 2016
April 2016
March 2016
February 2016
January 2016
December 2015
April 2015
March 2015
September 2014
July 2013
June 2013
May 2013
April 2013
March 2013
September 2012


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager