Closed robertdstein closed 1 year ago
I've finally got to testing this, but I can't reproduce this error or the related #207. Which version of Python are you using? If you try with Python 3.10, astropy 5.1 and numpy 1.23, do you still get an error?
I tried with the latest github version of Mosfit (1.1.8), python 3.10.4, astropy 5.1, numpy 1.23.3, and I do still get the error. For reference this is on a Mac M1 (2021).
I then tried the a clean install on a random linux machine:
and there I get exactly the same error. So it does not seem to be platform-specific for me. Anything obviously wrong there?
We're now seeing this error in the conda-forge feedstock build process: https://github.com/conda-forge/mosfit-feedstock/pull/50 . Current builds are with Astropy 5.1.1, Numpy 1.23.4, across Python versions.
I believe I have now fixed this!
I'm bumping the version number so we can update the distributions. I've done this on pypi -- Peter would you be able to do it on conda-forge? I'm not sure of the process for that.
Would also be great to get confirmation that this is working for others
@mnicholl Great! The conda-forge update should be close to automatic — we have bots that look for new releases and automatically submit pull requests to initiate the updates. I'll ping you if anything comes up but you basically shouldn't have to worry about that part of the process.
I confirm that I just tested this with astropy 5.1.1. The error is reproduced for mosfit 1.1.8, but is completely solved in 1.1.9, so it looks like the fix works. Thanks @mnicholl!
As seen in https://github.com/conda-forge/mosfit-feedstock/pull/51, the new release builds successfully in conda-forge too. I think it's safe to mark this one as solved.
Some features of Mosfit are not compatible with astropy 5, because astropy Quantity values are no longer directly compatible with
numpy.logspace
(see e.g https://github.com/astropy/astropy/issues/10573).A minimal example, with
astropy==4.3.1
andnumpy=1.22
:mosfit -m slsn
which runs without errors. However, repeating the same command with
astropy==5.0
andnumpy=1.22
yields:I am pretty sure this is the same problem problem described in #207.
I think this problem would be rather complex to solve. It would involve ensuring that all variables passed in Mosfit are either always an astropy quantity or always a numpy float/int etc. Right now some variables can swap between the categories. An example is
self._rest_t_explosion
indensetimes.py
, which causes the error above and is both an astropy quantity and numpy float at different points during the call ofmosfit -m slsn
. If the variables were reliably in one class or the other, the astropy quantities would then need to be converted each timenp.logspace
are used.For https://github.com/guillochon/MOSFiT/blob/b9d1895aef54e06669fba09e11248f8d2f65777f/mosfit/modules/arrays/densetimes.py#L38 you can't simply replace with
np.log10(max_times - self._rest_t_explosion.value)
because ifself._rest_t_explosion
is not an astropy quantity this will throw an error.