K. Mahn, D. Ruterbories, K. Bays Luke Pickering, K ... · DUNE Collaboration Meeting Fermilab, 2018-05-16 Luke Pickering, K. McFarland, K. Mahn, D. Ruterbories, K. Bays

DUNE Collaboration MeetingFermilab, 2018-05-16

Luke Pickering, K. McFarland, K. Mahn, D. Ruterbories, K. Bays

L. Pickering 2

● The Code○ Design goals○ Current structure○ Next

● Systematic Errors for LBL○ QE-like○ Single pion○ Other○ ~timeline

L. Pickering 3

L. Pickering 4

● Basic unit of systematic error propagation: parameter variation ➡ response.

● Key goal -- Flexibility of response use:○ ‘Vertical’ (e.g. xsec weight) and ‘lateral’ (e.g. FS lepton momentum shift) responses○ Support Multi-universe/systematic throw paradigm, but not require it○ Parameterized response functions: Splines, fit polynomials

● Key goal -- Try not to force when responses should be generated:○ Generation code is tied to ART: Can run at generation time, or post event selection.○ Response interpretation code is not: hopefully helpful in writing fitters.

● Key goal -- Keep scope of code as wide as possible (and no wider):○ Try and provide a general solution, but don’t get bogged down trying to solve the

general problem.○ Should be used for: Flux, Interaction, and GEANT4-level uncertainties.○ Could be used for: Calibrations, detector systematics.

L. Pickering 5

● Current ART package: larsim/EventWeight○ I wanted to change the response format (no event-by-event strings), but didn’t want to

impose on MicroBooNE analyses that are actively using it.○ Plugin interface not well executed, required ART producer modules for experiment-specific

code.● New packages: larsyst, nusyst

○ All structural code is experiment non-specific: larsyst depends only on ART.○ Interaction systematics will not be DUNE specific: nusyst depends on nutools.

● larsyst provides: ○ Producer module, uses art::make_tool to load ‘syst_providers’ from more specific packages;

e.g nusyst.○ Tools for: consuming parameter meta-data, interpreting responses as splines, loading splines

into memory for fitters○ Meta-tool for making correlated throws between child tools (e.g. flux and xsec)

● nusyst contains a syst_provider for GENIEReWeight.● Header files are well documented. Full documentation ~end of week

L. Pickering 6

● A set of syst_providers is configured by arbitrary fhicl (user written)○ Configurations are translated to a common ‘parameter header’ format by each

syst_provider.○ Used to deterministically add relevant event response data product.○ Currently this is fhicl, but it is a bit clumsy for large sets of parameter throws.

● This configuration is then given to ART jobs that calculate and stash responses to all configured parameter variations for each input file.

● Response data product: std::vector<std::map<size_t,std::vector<double>>>○ For each ‘event’, for each parameter (size_t is unique parameter Id), list of

responses. Responses only stashed for parameters that affect a given event.○ ‘event’ is generalized, but likely to be neutrino interactions within a beam spill.

syst_providerfhicl

Generate configuration

Parameter header configuration

ART file 1ART file 2ART file 3ART file ...ART file NC

alc.

res

ps.

Ad

d d

ata

pro

d.

L. Pickering 7

● As responses are generalized, useful to have tools for interpreting them.

● Event responses must be fully interpretable from the parameter header configuration.

○ Format allows most to be generically interpreted.

○ For some applications, the parameter name might give the consumer a hint: e.g. EbFSMuMomShift

○ Arbitrary string options can also be used to pass information to interpreters: e.g. PolyOrder4.

L. Pickering 8

● User written fhicl: ExampleGENIEFFCCQEProviders.fcl

● Run: GenerateSystProviderConfig -c ExampleGENIEFFCCQEProviders.fcl

● Use generated fhicl in physics.producer

● Uses md5 of configuration as product instance name to preclude interpreting with the wrong configuration.

ExampleGeneratedMetaData_GENIEFFCCQE.fcl

L. Pickering 9

● Can spline calculated responses to allow approximated continuous evaluation between limits.

First 50 QE event response splines

L. Pickering 10

● More user-level documentation.● More tools:

○ I personally think that the best way to design this is to allow users access to internal calculations, but provide tools for interpreting them:

■ e.g. Parameter shifts and responses are available in arrays, but most users will ask the interface to give them a TSpline3, which they can use to get an approximated continuous response.

○ Start with basic set of tools, but welcome feedback/input/contriubtions from users.● Multi-dimensional response functions:

○ Needed when W(a’,b’)!=W(a’,b)*W(a,b’). e.g. Multi-parameter axial FF, long-range nuclear screening, etc...

● Exposed ad-hoc calculations:○ On T2K, some responses end up directly implemented in the fitters for optimization

reasons. Better to provide full model through the systematic tools.● Interface to CAFTreeMaker/CAFAna.● Host @ FNAL + UPS, currently just on my github...

L. Pickering 11

L. Pickering 12

● Want z-expansion axial form factor: More realistic uncertainties at high Q2.○ Response to parameters not independent: Assess, but probably ignore for

TDR-level studies.○ MINERνA data may constrain high Q2 more than Meyer et al, but requires study.

● GENIE Nieves 2p2h + MINERνA q0q3 gaussian tune.○ MINERνA tune is public, but mostly sensitive to Eν-independent terms.○ Low side of DUNE flux also sensitive to terms that go like 1/Eν.○ Would be interesting to compare to qualitatively similar NOνA tune .

● Low Q2 suppression (RPA):○ Use T2K-like RPA uncertainties, take care when overlaying on GENIE vX.Y.Z default.

● FSI cascade uncertainties beyond GENIE parameters:○ ad hoc proton to neutron energy dials to try to account for shortcomings.○ Applying ‘truth’ shift to ‘reco’ requires dedicated study on applicability, but can be

used to study shortcomings of model freedom against mock data.

L. Pickering 13

● MINERνA sees enhancement at lower invariant masses than predicted by R-S.

○ Similar shift predicted by models with res/non-res interference, e.g. MK model (Phys. Rev. D 97, 013002 (2018))

■ T2K study via (Eν,pμ,θμ) reweighting.■ Not clear that this is sufficient for LAr.

○ Could develop ad hoc freedom in (Eν,W,...)

● MINOS, MINERνA see a need for low Q2 suppression in SPP processes:

○ No theoretical basis for RPA (Low Q2 != low q0, low q3)○ Recent NOνA studies use QE-like RPA suppression as a

function of Q2 for good prediction of observed data[1].○ How to assign uncertainties: on vs. off, mock data?

● Can ‘fake’ a 2p2h-like effect by changing probability of events with multi-nucleon-like invariant mass (W above Delta peak).[1] http://if-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=306&filename=2018-04-23%20Wolcott%20NOvA%20XS%20model%20-%20FNAL%20NPC.pdf&version=1

MK

L. Pickering 14

● Hopefully borrow DIS/Multi-pi GENIE uncertainties from NOνA model.● ν μ/e interaction cross section differences:

○ Radiative corrections are essentially a guess. This is a cause for concern, but needs theoretical input.

○ Form factor differences are parameterizable for QE, but not well understood for other channels.

○ Investigation into phase space regions allowed in νe, but not νμ that may need inflated nue uncertainty.

● NC 1pi can look like a muon at the far detector:○ Parameterize extra freedom as a function of Tpi/q0 to allow more/less selected

background.

● Recommend Berger-Sehgal coherent pion with no extra uncertainties:○ Could formulate some uncertainties by comparison to MINERνA data, but lower

priority.

L. Pickering 15

Low priority

Critical

Would be goodMatt/Kirk

Luke (+Clarence)

Dan R.

Rochester?

L. Pickering 16

● Good progress on code-structure front of systematic error response package for ART.

○ Need to implement CAFAna interface ASAP.

● Brought together ‘extra’ uncertainties/concerns from T2K, MINERνA, NOνA:

○ Many are implementable on an O(1 month) timescale.○ Others require further study that may push the timescale past the TDR.○ Could develop mock-data fits to determine the effect of missing some of these

uncertainties.

● Question: Do we know what GENIE version will be used?○ Do we know the state of implementing mock-data studies from the Professor

output if using V3?

Thanks for listening

L. Pickering