new mesa metallicity and data dirs

[ipelupessy]

just a couple of questions for the new mesa @rjfarmer :

• how do I run models with different metallicity?
• does mesa need anything else form the src/mesa directory besides the data?

[rjfarmer]

Same as the old way:

stellar_evolution = MESA(version='15140')
stellar_evolution.parameters.metallicity = 0.001
masses=[1.0] | units.MSun
stars = datamodel.Particles(len(masses), mass=masses)
stars = stellar_evolution.native_stars.add_particles(stars)

There are other options if you want more control, like setting the helium fraction.

MESA itself shouldn't need anything other than its data directory. But there are a number of dependencies we had to install that sit in the mesa_r1540/src folder that may need files.

[ipelupessy]

I get

WARNING: requested initial_z does not match zams file initial_z.
                                    zams file initial_z    2.0000000000000000D-02
                                    requested initial_z    1.0000000000000000D-03



 failed in get_zams_model
 star_load_zams ierr          -1
 do_load1_star ierr          -1
 before_evolve_loop ierr          -1

end then it returns a -1

[rjfarmer]

I should of course check my own code before making suggestions, try this instead (after setting the parameters):

stars = stellar_evolution.pre_ms_stars.add_particles(stars)

[ipelupessy]

ok, this seems to work..

it reports writing a bunch of stuff to src/mesa-r15140/data/kap_data/cache

I am still thinking about a way to handle this..it used to be the case that there was a global data directory with input and output..I changed this (for eg mesa_r2208) to have a data directory in the code directory (this is copied over automatically in case of package install) and output in the cwd (by default) in a directory _amuse_code_output ..for codes like mesa it may still be a good idea to have it write output in a globally shared location since it writes stuff that gets reused later (otherwise it will regenerate it each time you run in a different directory)...hmm..

[rjfarmer]

it reports writing a bunch of stuff to src/mesa-r15140/data/kap_data/cache

Yes as MESA runs and loads new data files it writes a binary version back to file, so that next time MESA runs it can read the binary version and be faster.

.for codes like mesa it may still be a good idea to have it write output in a globally shared location since it writes stuff that gets reused later (otherwise it will regenerate it each time you run in a different directory)...hmm..

Not sure I understand, as that is what it is doing already.

What happens is when you run MESA and it encounters a data file its not read before it reads a text version of the file from src/mesa-r15140/data/ then it writes a binary version to a temporary folder (handled by python's tempfile.mkdtemp) then once the file is written it gets moved to back to src/mesa-r15140/data/ so that it can be read by other MESA runs. We do this so multiple MESA's can run at the same time and not see files partially written (if we write directly to src/mesa-r15140/data/ then another MESA may try reading a file thats not been fully written yet). If you where to run the same model again you should not see the lines about writing stuff to kap_data.

We con reconfigure where everything is getting read/written to if you want? During initialization we just need to set a folder. But that would need the whole contents of src/mesa-r15140/data/ to be there.

[ipelupessy]

its ok it reads from src/mesa-r15140/data/ though preferably it should be just /data (only this directory is installed), but that is just a matter of moving..

it should not write back to that directory though (it may not be writeable or may be shared (though the temperorary stuff is a nice solution for that))..on the other hand, the default setup for codes with data directories now has the output directory as the run directory of the script, which is also not optimal..

[rjfarmer]

it should not write back to that directory though (it may not be writeable or may be shared (though the temperorary stuff is a nice solution for that))..

It will currently just print an warning if it fails to write to that directory. And for being shared, yes we did spend alot of time to design the system so it works when running many jobs on the same cluster.

#874 Now lets you set the the new location of the folder that was src/mesa-r15140/data/ . So if you want that to be a different location then either change the default_path_to_MESA_data method in the mesa_interface.py or change what happens when we call MESA.init in interface.py (just make sure that you have moved the folder before setting the option)

[ipelupessy]

so apart from the data dir, mesa seems to need files from src/mesa-r15140/star/defaults and it tries to open src/mesa-r15140/stop_warnings_for_rel_E_err but that is not there, doesn't seem to mind though

[rjfarmer]

src/mesa-r15140/star/defaults

Forgot about those files. While I turned off mesa's normal file output, we still read the config files for the file output in case we turn on output later. This can be patched out.

src/mesa-r15140/stop_warnings_for_rel_E_err

I did not even know we tried to do that. Seems to be some debugging code to stop the run if certain errors occur. This can also be patched out.

[ipelupessy]

ok, now when I run the low z multiple times it everytime will reinit a new pre-ms model..it doesn't seem to save the file like r2208 (or it doesn't find it back?)??

[ipelupessy]

oh, and what was the gyre stuff (and does it need to read this?)

[rjfarmer]

ok, now when I run the low z multiple times it everytime will reinit a new pre-ms model..it doesn't seem to save the file like r2208 (or it doesn't find it back?)??

No it doesn't save a pre-ms model when you change z.

oh, and what was the gyre stuff (and does it need to read this?)

gyre is for asteroseismology to calculate pulsation modes. It shouldn't be doing anything with gyre unless you pass a gyre input file when initializing MESA (stellar_evolution = MESA(version='15140',gyre_in='./gyre.in')). Is gyre loading files now as well?

[ipelupessy]

ok, then I don't have to look for the output ;-)

for the gyre: no I don't think it is, however if it is used, this will need files from src/mesa-r15140/gyre? I think with the exception of this and the above mentioned files (star/defaults etc) everything comes from the src/mesa-r15140/data directory (even if the lookup uses src/mesa-r15140)?

[rjfarmer]

for the gyre: no I don't think it is, however if it is used, this will need files from src/mesa-r15140/gyre?

Digging in the code i think it does, but it looks like its just another path we can pass in to set its final location.

I think with the exception of this and the above mentioned files (star/defaults etc) everything comes from the src/mesa-r15140/data directory (even if the lookup uses src/mesa-r15140)?

Yes, though with #874 you now set default_path_to_MESA as src/mesa-r15140 and default_path_to_MESA_data as src/mesa-r15140/data .

For gyre if you copy src/mesa-r15140/gyre to os.path.join(default_path_to_MESA,'gyre') then it will already pick up the move (if you change default_path_to_MESA to a new location). You could do the same for the files in star/defaults, just copy the contents to os.path.join(default_path_to_MESA,'star','defaults')

[ipelupessy]

ok, thanks, I think I know enough!!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 28 days if no further activity occurs. Thank you for your contributions.