Harmonize access to Mors and stellar object

[lsoucasse]

Getting the bolometric flux and the star radius with Mors and the Spada model (case 0) does not seem to take the rotation rate as an input parameter as it should. Also, it would make more sense to harmonize the access to stellar data between submodules (i.e. the bolometric flux for the atmospheric modules is get with the Value function while the XUV flux for the escape module is get through the Track function).

This issue can be addressed together with designing a wrapper for stellar modules #126 .

[lsoucasse]

This is also important now we use a fix time stepping to access Spada data. We need to make sure to create star object only once.

[lsoucasse]

I would like to address this issue but the current state is very confusing to me:

• Why do we currently set up a star radius as an input parameter in the config while it is actually an output of Mors (either Spada/Baraffe data)? same remark with lbol_now and Teff?
• When the get_new_spectrum function is called, it takes some star properties computed at the init step (star radius, various fluxes...) that are never updated in time. Is this the normal behaviour?

I was thinking of deleting the get_property function in the mors synthesis module and instead generating the whole track data on the proteus side and get the properties from there as time evolves. Does that sound good @nichollsh ?

[nichollsh]

A few of these variables are the modern values - i.e. those observed at the current time. These are needed for knowing how to scale the modern spectrum backwards in time.

This is related to the properties which are only calculated at the init step - we need to know what the star looks like now, in order to know how to scale the modern (observed) spectrum backwards in time. When the model first starts, it takes the modern spectrum and calculates the band-integrated fluxes. Of course the modern spectrum isn't changing over time, so that's why this is only done once at the start.

The Teff and radius parameters are also needed for the dummy star module, although we could feasibly move those into config.star.dummy.

[lsoucasse]

OK, I understand these are frozen. But I think it would be better to extract them from the whole track data otherwise it will not be consistent. Workflow would be:

• create the star track data from mass and rotation rate
• extract properties at initial time (modern properties if I get it correctly) for spectrum synthesis
• extract properties as time evolves to be stored in helper file and used by other submodule (instellation, xuv flux for escape...)

Would that be OK?

[nichollsh]

Yeah I think that makes more sense. However, for the dummy star module we will still need to provide radius and Teff, so those can go into config.star.dummy I suppose.

[lsoucasse]

Yeah I think that makes more sense. However, for the dummy star module we will still need to provide radius and Teff, so those can go into config.star.dummy I suppose.

Yes, sure! It will be clearer then that the radius and effective temperature are an input for the dummy and an output for Mors.

[lsoucasse]

Also if I am not mistaken the input config parameter config.star.lum_now is not needed and can be replaced by getting the bolometric flux from baraffe track at initial time and keep it frozen.

[nichollsh]

Yeah that makes sense too. We can get it from the tracks when using Mors, and when using the dummy module it isn't needed anyway.

It's quite nice to remove parameters from the configuration file - there's already so many.

[nichollsh]

Also age_now can be moved into the mors table,since it's not needed for the dummy star module.