add MixingParameters presets

[JostMigenda]

Closes #195.
In addition to the NuFIT5.0 values, this PR adds NuFIT5.1 and PDG2022 mixing parameter values and an optional argument to select which version of the parameters to use. In the initial commit, the default remains NuFIT5.0. In an upcoming commit, I will explicitly set the version in any tests that depend on this, so tests don’t start to fail once we change the default to a more recent version of the parameters.

[JostMigenda]

The test failure is fixed in #207.

[Sheshuk]

Adding a version in the parameter into the constructor doesn't seem right to me. This way we'll have to expand the definition each time new version is available, changing the class.

What I think would be cleaner is:

1. Use the dataclass decorator (MixingParameters class is basically a data container). It will provide a nice constructor, where wwe can pass all the values separately.
2. For each NUFIT version make the objects of the MixingParameters class, so it would be available when you import these parameters, something like:

from snewpy.neutrino import pars_NuFIT_5_2

3. Pass these parameters as object to where they are used (FlavorTransformations)

If you agree, I can commit this implementation

[JostMigenda]

Re: 3., see my comment here. But I think that’s just a slight annoyance and not a reason to avoid dataclasses; so yes, please go ahead!

[Sheshuk]

Um, in the mixing parameters we have dm32_2 for NH and dm31_2 for IH, which is correct, but makes it hard to use with the dataclasses.

I did grep dm3 *.py in the code and looks like we don't actually use any of them.
It's rather hard to use them directly: one would have to make checks on hierarchy and choose the right value.

So maybe we can just name them dm2_small and dm2_large or something similar?

Another option would be to have separate classes for NH and IH, but I'd prefer otherwise

[Sheshuk]

So maybe we can just name them dm2_small and dm2_large or something similar?

Or dm2_21 and dm2_3l as it is in NuFIT

[JostMigenda]

Um, in the mixing parameters we have dm32_2 for NH and dm31_2 for IH, which is correct, but makes it hard to use with the dataclasses.

Careful, it’s even trickier: NuFIT gives dm32_2 and dm31_2 depending on the mass ordering, while PDG gives dm32_2 for both NMO and IMO.

I guess in principle, if we know dm31_2 and dm21_2 for NuFIT IMO, we can calculate dm32_2 from that and use that for all cases? That would certainly be easiest to implement in this PR; and if they’re not used anywhere right now, then it can’t cause a problem elsewhere.
But just to be sure—@jpkneller, do you see that causing any issues when implementing future FlavorTransformations?

[JostMigenda]

Or dm2_21 and dm2_3l as it is in NuFIT

Since l and 1 look very similar in many fonts, I’d really rather avoid that! (The NuFIT folks get around that by using the cursive 𝓁, but we can’t do that in code.)

[jpkneller]

If I have to pick, I would prefer dm32_2 over dm31_2. Even better would be to have all three available although that might open the possibility that a user could assign values that were not self consistent.

[Sheshuk]

I implemented the class to hold all dm_2, and calculate the missing ones (passed as None), also I added validation after the constructor, that the proper sum of dm_2 is zero.

@JostMigenda in your presets I see values of dm32 for NH and dm31 for IH, but I suppose it should be vice versa? Because on NuFIT site I read:

Note that Δm​2_3ℓ = Δm​2_31 > 0 for NO and Δm​2_3ℓ = Δm​2_32 < 0 for IO. 

So probably I should correct this in the test?

[JostMigenda]

Hope I’m not bike-shedding too badly here, but since the function name and docstring use two different spellings: I have a feeling “mass squared difference” (with the extra d in “squared”) is more common; so would prefer to rename the function accordingly.

[Sheshuk]

My English can be really bad sometimes, so I agree to whatever you decide here (and please feel free to check and correct my naming/docstrings).
But this part I just copied from @jpkneller implementation in #189 - I thought it would make sense to put in this PR.
I'll use mass_squared_difference

[JostMigenda]

Good catch about the 31/32 mixup, thanks!

I think the MixingParameters4Flavor class should have another mass-squared difference for the 4th neutrino flavour. (Or rather three, of which one needs to be provided, and two can be calculated automatically?)

[Sheshuk]

Okay, I've added the needed parameters.
Also I made it possible to create MixingParameters4Flavor like this, to support extending standard 3 flavor ones:

pars_3f = MixingParameters() #standard 3flavor mixing
pars_4f = MixingParameters4Flavor(**pars_3f, theta14=90<<u.deg, dm41_2=1<<u.GeV**2)

[mcolomermolla]

why setting them to zero instead of being an input parameter the user can give?

[JostMigenda]

Note that this is marked as a dataclass, which automatically generates a __init__ function to set them as input parameters. The value defined here is used as the default.

[Sheshuk]

Yes, as Jost said zeros will be default parameters in the constructor. So by default there is no mixing with sterile neutrinos, and only if user provides the mixing angles in the constructor, e.g.:

params4f = MixingParameters4Flavor(**params3f, theta24=45<<u.deg)

there will be an effect of sterile neutrinos

[mcolomermolla]

oh right, I missed it in that line. Looks good then!

[mcolomermolla]

I like the new way to handle the versions for the oscillation parameters!
Minor comment: is there a reason to have NuFit5.0 and 5.2 but not 5.1 version?

[JostMigenda]

We keep 5.0 as the initial value (for backwards compatibility) and 5.2 as the most up-to-date value. I don’t think there is a reason to newly add an outdated version.

I worked on this PR after my first review, so it's obsolete, and needs approval from others

[mcolomermolla]

Ready to be merged