Markus,
Just to let you know that there are existing GENIE tools for helping create the "fully oscillated" (really, "flavor changed") fluxes from base fluxes. How convenient this is might depend a bit on what app/framework you're using to drive GENIE.
The following is most useful in the case of detailed ntuple-style fluxes (vs. simple histograms which can easily be re-assigned a flavor). This approach avoids creating new datafiles that would take up disk space.
The $GENIE/src/FluxDriver/GFluxBlender.h class acts like a standard flux driver to applications, but gets configured with flux generator (another GFluxI derived class, i.e. the flux driver you already use) + a flux mixer (GFlavorMixerI derived, which you can fetch from the GFlavorMixerFactory by name) -- the current only concrete class is GFlavorMap.h but users can extend the list with their own classes. GFlavorMap allows an arbitrary mapping of input flavor (from the underlying driver) to a output flavor (returned by the blender). Thus if one runs three times with the same input set but having the flavor map permute the flavors:
base driver set0 (unmod) permute1 permute2
nu_e -> nu_e nu_mu nu_tau
nu_mu -> nu_mu nu_tau nu_e
nu_tau -> nu_tau nu_e nu_mu
(and same for anti-nu) then one can construct any desired 4-flavor mixing post hoc (sterile just meaning weight = 0).
-robert
Robert W. Hatcher
Computational Physics Developer
Fermilab CS/SCD/SCS/PDS | WH9NW
PO Box 500 MS 234, Batavia IL 60510
[log in to unmask]
office: 630-840-3102
cell: 630-234-0091
> On Apr 5, 2016, at 12:31 PM, Costas Andreopoulos <[log in to unmask]> wrote:
>
> Dear Markus.
>
> You can generate events using an unoscillated flux and re-weight the output files (since you can get Etrue and neutrino flavour from the event record).
> This way you can apply the appropriate survival probability, e.g. P(nu_e -> nu_e), P(nu_mu -> nu_mu) to your our output sample.
> Depending on the details of what you do, you may also need “fully oscillated” samples (for example, generated nu_mu interactions, but with with a nu_e flux).
> You should reweigh the previous “fully oscillated” sample with the corresponding appearance probability P(nu_e -> nu_mu).
> You will need to combine several samples “nominal beam nu_e, nominal beam nu_mu, nominal beam nu_e_bar, … fully oscillated nu_e, fully oscillated nu_nu, fully oscillated nu_e_bar,…). But, still, the post-production oscillation reweighting should be much faster than generating samples for each oscillation model or set of oscillation parameters you want to plot.
>
> There are some fine details that depend on the `exotic oscillation model’ you plan to use.
> Will send you some details about the procedures we use in the VALOR fit group in another e-mail off this list.
>
> cheers
> Costas
>
>
> --
> Dr. Constantinos Andreopoulos
> Reader (Associate Professor) in Experimental Particle Physics
> University of Liverpool & STFC Rutherford Appleton Laboratory
> +44-(0)7540-847333 (Mobile)
> +44-(0)1235-445091 (Office/RAL)
> +44-(0)1517-943201 (Office/Liverpool)
> http://costas.andreopoulos.eu
> https://valor.pp.rl.ac.uk
> https://genie.hepforge.org
>
>
>
>
>
> On 5 Apr 2016, at 18:04, Markus Kurbel <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>
> Dear all,
> it might be trivial but i am not sure on the following.
> I am trying to analyse exotic oscillation models and asked myself, if one has to weight the input flux before the interaction simulation, or if one can use the unoscillated
> flux to generate a sample, which can be weighted for several models.
>
> Thanks in advance
> Markus
>
|
