Closed JostMigenda closed 2 months ago
Actually, this comment applies to all models. Right now, they all require not only the value but also the units for the model initialization. If we want to be self-consistent, this model should also keep the u.MeV after the value, or we should change that for all models accordingly.
@mcolomermolla I wouldn’t mind treating 0 as a special case here, since a mass of 0 is perfectly clear even without units; whereas e.g. a mass of 100 is meaningless without units. So I don’t think this would apply to most other models? But you’re right; it’d be more consistent to require units everywhere and just update the notebook.
I created PR #317 to unbreak the notebook. About loading the model directly from a file, you're right that the model is set up to take axion_mass
and axion_coupling
as required parameters and is duplicating the loader. Do you want to have a go at that @JostMigenda ?
Two separate issues I noticed while trying to use the recently added
Mori_2023
model from sntools:The demo notebook
Mori_2023.ipynb
fails to run:It’d be nice to let users enter
0
instead of requiring0 * u.MeV
, so we should add code to handle this special case.Loading a model directly from file via
fails with a
KeyError
, since the loader class extracts entries from themetadata
dictionary. However,metadata
is an optional argument (like for all loader classes), so if it isn’t present, we should handle that gracefully.(Of course, the loader classes are not a public API; but they’re useful for internal testing/usage.)
I’m happy to fix both; just one question @sybenzvi: Is there a particular reason to add
self.axion_mass
etc. as instance attributes, rather than accessing them viaself.metadata['axion_mass']
? This looks like unnecessary duplication to me; and we don’t generally do this for metadata entries in other models.