Isochrones do not recalculate if filters are changed

[zangston]

TLDR

After creating an isochrone object, changing the filters, while keep all else constant, does not cause SPISEA to not recalculate that isochrone.

Suspected cause

This appears to be due to the naming scheme of isochrone files, as well as the way the program checks to see if a particular isochrone file exists, which does not check for changes in filter. The program creates a savefile name parameterized by filepath/age/metallicity/extinction/distance, then checks to see if that file exists in specfied isochrone directory. If it does exist, it checks the isochrone's metadata array for changes in evolution model, atmosphere function, and reddening law; if any of the aforementioned changed, the program goes ahead with recalculating the isochrone.

Current workaround

This can be easily remedied by deleting the file or specific directory where a script saves isochrone files to, but this also appears to be the only parameter that does not prompt reconstruction or recalculation after being changed. All other parameters after being changed will either result in a new isochrone object being made, or the originally constructed object to be recalculated.

Reproducing the Defect

My team and I noticed this problem when we ran \docs\Quick_Start_Make_Cluster.ipynb, creating an isochrone object, then going back to edit code cell 2 so that filt_list contained strings for 2mass filters instead of HST. Running the rest of the cells looked like as if the program had not been changed at all, as printing the astropy table still showed "m_hst_153m" in the headers, and the resulting isochrone and cluster did not appear any different.

[jluastro]

This is a “feature” so that when doing forward modeling of star clusters with different IMFs, you don’t recalculate the isochrone every time. Perhaps we should add a recalc flag?

[zangston]

This is a “feature” so that when doing forward modeling of star clusters with different IMFs, you don’t recalculate the isochrone every time

Can you elaborate? Based on my review of synthetic.py, isochrone and IMF are two separate object parameters for the cluster constructor, which doesn't call the isochrone constructor in any way. I don't see how implementing recalculation in the event of filters being changed will affect this.

Perhaps we should add a recalc flag?

As far as I understand, the IsochronePhot constructor does already take a boolean parameter recomp that can be passed in to prompt a recalculation.

[jluastro]

The cluster constructors take an isochrone object and an IMF object (also IFMR and sometimes other parameters). The cluster constructor then uses the isochrones alone with the other objects/parameters to make stars with observable properties (including apparent magnitude). An example use case would be a likelihood function that would create a new cluster with some set of free parameters such as: age, distance, reddening, IMF slope, IMF peak mass. Inside the likelihood function, you would instantiate a new cluster object each time (with updated parameter values). And then use the cluster object's stars to compare against some observations and compute a likelihood. In a Bayesian inference, you would need to make ~10,000 calls to this likelihood function and thus generate 10,000 different clusters. In such a scenario, the selection of filters would never change. You can see an example in the synthetic.py code here.

The most expensive part of this process is actually making the synthetic photometry... so to speed up this process and not re-run it when you are just changing IMF parameters, we don't recalculate isochrones with the same parameters (e.g. age, metallicity) if they already exist. This is why we opted to re-use whenever possible.

And yes, the recomp=True flag is what you should use anytime you change the filter set. I just added a clarifying sentence to the documentation.