Update neutrino.py

[jpkneller]

SNEWPY v 2.0 will require mass splittings

[JostMigenda]

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

[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]

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 https://github.com/SNEWS2/snewpy/issues/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.