adopt features from snewpy

[JostMigenda]

snewpy is a SNOwGLoBES frontend developed by members of the SNEWS 2.0 collaboration. Like SNOwGLoBES, it’s not a replacement for sntools; but it does have features that would be useful in sntools, too:

• support for more flavour transformations
• support for more supernova models

Time- and energy-independent flavour transformations should be straightforward to add to sntools, analogous to the current implementation of MSW effect in normal/inverted mass ordering. (However, it will be necessary to change the command line interface to e.g. --transformation=AdiabaticMSW_NMO (instead of --ordering=normal), once additional transformations are available.)

Time- or energy-dependent flavour transformations will require further changes to sntools.

For additional supernova models, I need to check if it’s possible to write an adapter that maps snewpy’s interface to the one expected of an input format in sntools.

[JostMigenda]

First steps are now on the JostMigenda/SNEWPyIntegration branch.

[JostMigenda]

I’ve added the majority of the models and transformations in a PR earlier today.

The following flavor transformations from SNEWPY are not yet supported:

• NoTransformation and AdiabaticMSW: identical to the transformations already natively supported by sntools (in fact, the native implementations were renamed for consistency)
• NeutrinoDecay: has energy-dependent transformation propabilities, which requires additional changes to sntools
• AdiabaticMSWes and NonAdiabaticMSWes: requires additional input parameters (sterile mixing angles)

The following supernova models from SNEWPY are not yet supported:

• Fornax_2019 and FornaxModel: alternative implementations of the same model; will wait until SNEWPY has decided how to move forward.
• Janka: inconsistent return type of get_time(), see issue 45 on SNEWPY repo. [deleted in Jankacleanup snewpy#48]
• Warren_2020: identical to the native warren2020 input format already supported by sntools.

Additional open issues:

• SNEWPY currently needs to be installed separately by the user. Once it is available on PyPI, it should be added as a regular dependency in requirements.txt and setup.py.
• Using a supernova model from SNEWPY is currently much slower than a model that’s natively supported by sntools. E.g. using --format SNEWPY-Warren_2020 is about 3× slower than using the native --format warren2020 on the same input file. See the issue on the SNEWPY repo linked above for details.
• Should the format names in sntools be renamed for consistency with SNEWPY SupernovaModels?

[JostMigenda]

5b11008 improves performance for SNEWPY supernova models, reducing the difference in the Warren_2020 example to under 2×. Still not ideal, but this was probably the lowest-hanging fruit.

[JostMigenda]

Several new models were added to SNEWPY over the last few months:

• Tamborra_2014, Walk_2018 and Walk_2019: straightforward in principle, but gives ValueError: 'x' must be strictly increasing sequence. because input files have duplicate values ➔ fixed in remove duplicate times from Tamborra, Walk models snewpy#161, added to sntools in support for new models added in SNEWPY v1.1 #40
• Fornax_2021: current implementation of the class cannot run in a ProcessPoolExecutor (fails with TypeError: h5py objects cannot be pickled) ➔ see Fornax_2021.get_initial_spectra() performance improvements and bug fixes snewpy#166 and Fornax models: get_initial_spectra() returns wrong units snewpy#167
• OConnor_2013: needs mass and EOS as arguments (instead of path of input file), which would require more changes to accommodate