Update neutrino.py

[jpkneller]

SNEWPY v 2.0 will require mass splittings

[JostMigenda]

The test failures are unrelated, should be fixed in #190.

[Sheshuk]

As far as I understand, you want to have the possibility to override the mixing parameters for the FlavorTransformations. Would it make sense to modify these values in the MixingParameters class instance, and then pass this instance to the transformation, for example:

my_params = MixingParameters(MassHierarchy.NORMAL)
my_params.theta12 = 45 * u.deg
my_params.theta13 = 0 * u.deg
my_params.theta23 = 45 * u.deg
my_params.dm21_2 = 1.234e-5 * u.eV**2
my_params.dm32_2 = 5.678e-3 * u.eV**2

flavor_xform = AdiabaticMSW(my_params)

This would reduce the amount of repeating code and also the number of arguments in the constructor.

I suggest:

1. Make MixingParameters a dataclass (so it will be more clear for the user, that this is a container class, and all the parameters' types and units will be documented). For example:

2. Make each FlavorTransformation class constructor to receive onlyMixingParameters (or leave the constructors as is, if we want backward compatibility, but create construction classmethods? But the constructor change is more natural way)

[jpkneller]

You're right, that is probably a better solution.

[jpkneller]

I removed the mass_squared_differences argument and now assign the default values based on the mh argument.

[Sheshuk]

Now the problem is that pars just gets generated each time, so it will hold only the default best fit values for the given mh.
I suggest just directly pass MixingParameters instance here into flavor transformation constructor

[Sheshuk]

This PR has been stale for some time. I suggest to:

• Pass MixingParameters as an object to FlavorTransformations

so one can tweak the initial MixingParameters object to change the mixing angles etc.
For example

#create parameters
pars = MixingParameters(MassHierarchy.NORMAL)
#change mixing angle
pars.theta12 = 180<<u.deg
#pass parameters to new transformation
transform = AdiabaticMSW(pars)

@jpkneller if you agree, I can implement this, and commit to this branch.

[jpkneller]

I agree but does this break backwards compatibility? Are we starting version 2.0? If yes, I have other suggestions for changes.

[JostMigenda]

@Sheshuk: If we turn MixingParameters into a dataclass, how would that work for FlavorTransformations like AdiabaticMSWes, which require non-standard additional mixing parameters like theta14? My naïve first try gives kinda awkward results:

>>> from dataclasses import dataclass
>>> @dataclass
... class MixingParameters:
...     theta12: float = 33.41
...     theta13: float = 8.58
...     theta23: float = 42.20
... 
>>> f = MixingParameters()
>>> f
MixingParameters(theta12=33.41, theta13=8.58, theta23=42.2)
>>> g = MixingParameters()
>>> g.theta14 = 0.001  # additional attributes can be added …
>>> g  # … but are not displayed …
MixingParameters(theta12=33.41, theta13=8.58, theta23=42.2)
>>> f == g  # … and not used for comparisons(!)
True
>>> f.theta14
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'MixingParameters' object has no attribute 'theta14'
>>> g.theta14
0.001

I guess we could include all non-standard parameters that are used by at least one transformation in the dataclass, and then just set the ones that aren’t applicable to None? Or is there a cleaner solution?

---

@jpkneller Yes, it would; e.g. sntools is using things like TwoFlavorDecoherence(mh=MassHierarchy.INVERTED). However, that doesn’t mean we should delay working on it. It will be useful to know as early as possible all the changes we’re planning, to ensure we don’t make any decisions now that would complicate those future changes.
Also, it might be possible to write a hack that allows the old and new ways of initialising FlavorTransformations to coexist; that way we could implement that in v1.4, and show a warning message when used in the old way, so users have more time to update their scripts before any incompatible changes in v2.0.

[Sheshuk]

If we turn MixingParameters into a dataclass, how would that work for FlavorTransformations like AdiabaticMSWes, which require non-standard additional mixing parameters like theta14?

That's right, this might be problematic. Having
Possible solution can be a subclass for a new parameter set, like this:

@dataclass
class MixingParameters:
    theta12: float = 33.41
    theta13: float = 8.58
    theta23: float = 42.20

@dataclass
class MixingParametersSterile(MixingParameters):
    theta14:float = 0

par = MixingParametersSterile(theta12=45, theta14=30)

however we don't have an easy and explicit way of extending existing parameters, which would be really nice:

par = MixingParameters()

par1 =MixingParametersSterile(par, theta14)

So I think your proposal to include additional parameters with zero default values is better.

[jpkneller]

I think Andrey's solution for the cases where we have sterile neutrinos is a good one.

[jpkneller]

Right now there are two additional changes I would like to make to the Flavor Transformations. The first is to replace the 8 prob_xy methods with one method (get_probabilities) that returns a 2D matrix of probabilities. The [x][y] element of the matrix is the probability that nu_y -> nu_x. The second change I would like to make is to add an additional argument altaz into the constructor for future Earth matter effect calculations.

[Sheshuk]

The first is to replace the 8 prob_xy methods with one method (get_probabilities) that returns a 2D matrix of probabilities

I've added issue #242 for this. Probably this can be a backward-compatible change - we can still keep the prob_* methods for some time, using that matrix.

The second change I would like to make is to add an additional argument altaz into the constructor for future Earth matter effect calculations.

Do you mean adding it to the FlavorTransformation constructor? Probably it would make sense to add it in the child class c-tor, specific for that transformation (constructors of the children classes don't have to be similar to the base)

[jpkneller]

I've added issue #242 for this. Probably this can be a backward-compatible change - we can still keep the prob_* methods for some time, using that matrix.

That's okay with me.

Do you mean adding it to the FlavorTransformation constructor?

Yes. Right now we can only do Earth matter effect calculations for 3 flavor neutrinos, not 4. The plan I have of how to implement Earth matter effects is that if the AltAz argument to the constructor of whichever FlavorTransformation class the user has picked is not None, we will store the coordinates of the supernova and then when the user calls the get_probabilities method and supplies a neutrino energy (or provides a list of them) we will call a routine in a separate module which I have written which does the Earth matter effect calculation and use its results in place of the three parameters which are called De1, De2 and De3.

[JostMigenda]

The plan I have of how to implement Earth matter effects is that if the AltAz argument to the constructor of whichever FlavorTransformation class the user has picked is not None, we will store the coordinates of the supernova and then when the user calls the get_probabilities method and supplies a neutrino energy (or provides a list of them) we will call a routine in a separate module which I have written which does the Earth matter effect calculation and use its results in place of the three parameters which are called De1, De2 and De3.

Can you take a look at the “composite flavour transformations” @sybenzvi worked on in #203 and check if that would work for you? The idea behind that PR was to make it easy to add Earth matter effect (or any other transformations, if it makes physical sense) on top of other FlavorTransformations, rather than modifying all other FlavorTransformations to make a special case for EME.

[jpkneller]

I think this could be made to work. I want to check the math because SNEWPY doesn't distinguish between mu and tau neutrinos and calls them the x flavor, and the probabilities involving x have additional factors of 2 floating around.

[JostMigenda]

It looks like the changes from this PR are fleshed out more in #198, so I’ll close this PR now.
The rest of the discussion can continue in #203 and #242.