astrophysics

We could look into using the diskcache package to cache MAST search operations:

https://pypi.org/project/diskcache/

The package is a disk-based key-value store which makes it easy to specify an expiration time for each entry. This would allow us to e.g. cache search queries for 24 hours, which would significantly speed up searches across different Python processes, whilst largely avoiding

castro.change_max = 1.0 means that the timestep can only ever stay the same or decrease relative to its initial value. I think we should disallow this value, I have a hard time imagining a use case for this (if you want a fixed timestep, use fixed_dt, and if you want a timestep cap but still allow the timestep to decrease, use max_dt). It causes problems with the retry functionality.

The python implementation of leapfrog does not make use of the fact that drifts can be combined when not storing output, causing it to be slower than necessary. Comparing to the C implementation, it also appears to not be as precise.

Describe the bug
TARDIS uses a specific version of astropy constants (astropy.constants.astropy13constants).
The intended way to import these constants is: from tardis import constants as const. However, this is currently not done everywhere in the code (see e.g. https://github.com/tardis-sn/tardis/blob/master/tardis/simulation/base.py).

It was never meant for use outside Astropy, as per
astropy/astropy#11500

The following seminar work of Hernquist details a light profile called the Hernquist profile:

https://ui.adsabs.harvard.edu/abs/1990ApJ...356..359H/abstract

The intensity calculation for a spherical model is given by equations (32-35):

It would be good to implement this light

🎯 Todo

Post #287 #302 and a few other changes to the dataframe that will follow, a lot of columns in the dataframe will be made as attributes of the dataframe instead of an entire column. We are currently using df_metadata (a manually created dictionary) and df.attrs (an inbuilt dataframe attribute) to handle this.