Harmonize missing inlist/section in inlist handling

[VincentVanlaer]

I was looking a bit deeper into the issues @mathren highlighted in #954 where missing a missing pgbinary inlist causes somewhat of messy exit. While the fix is not too hard (it even simplifies the code), I did notice that the same code is repeated in various parts of the code base, but with slight differences.

• kap, eos, and colors allow the first inlist file in a chain to be missing. Missing kap and eos namelist sections lead to a warning, but no hard error.
• binary_job, binary_controls, astero_search_controls, astero_pgstar_controls, controls, pgstar, and pgbinary produce a hard error whenever the can't read a file or don't find their namelist sections (assuming the module is enabled).

I can see benefits for both cases: early warning to the user if they made a mistake vs. less unneeded noise.

Do we want to keep the current behaviour or pick one of the options? The difference for refactoring the code is limited.

[matthiasfabry]

In theory no single inlist section is necessary to supply because we can fall back to defaults, but I would say that when doing a binary run, in basically all cases you are modifying at least binary_job, binary_controls, star_job, and controls to create a specific setup for your science.

For astero it's likely the same thing: search_controls define crucial parameters about the behavior of the module, whereas pgstar_controls only about visualization (independent of any output that you are likely post-processing for science anyway).

Therefore I am in favor of not letting missing pgstar/pgbinary crash mesa.

eos and kap are more subtle ones. They control how mesa functions, but imagine that many users are ok with just the defaults. Colors i would say is essential when the module is turned on, since the user likely wants to specify their own passbands/filters and would generally want to change the defaults.

[mathren]

It's also likely that the "special" behavior of eos and kap (and colors) is because these were introduced later, so there was an argument of not making the code crash when re-using old inlist missing these namelist.

I agree with @matthiasfabry that it makes sense to avoid pgstar/pgbinary to crash mesa (that is just visualization) - but it shouldn't throw a traceback to the user (which can be scary for unexperienced users, and for just visualization this doesn't seem necessary). I could be in favor of making kap and eos "mandatory" (the change is not that new anymore, and we don't guarantee backward compatibility anyways), because while it's true many users use the default, that argument could be used also for any other parameter, and opacities and equations of state are key physical ingredients needed to run a stellar evolution simulation, so at some point "forcing" the users to confront what the default are doesn't seem bad (or worse than requiring setting their controls namelist, which kap and eos used to be part of).

colors being a new module, its namelist could go the way of kap and eos, as in for now throw a warning if the colors module is being used and the namelist is missing, with maybe a future aim to switch to the astero_search_control as in throw an error if module is being used without a corresponding namelist.

[Debraheem]

-> "(kap, eos, and colors allow the first inlist file in a chain to be missing. Missing kap and eos namelist sections lead to a warning, but no hard error.)"

I prefer this behavior. I don't think the inlists should be required to have these fields as long as the user is informed of the fallback when they are missing.

However for star/binary job and controls, I think it makes more sense to complain since the parameters for a model are defined in this files, not just the default microphysics prescriptions like in eos/kap/colors.

I could see the case for relaxing this requirement for pgstar, although it's against my better judgement since I am a huge pgstar fan, and I prefer to force it onto users.

I think i prefer the current approach, with more warnings potentially.

[VincentVanlaer]

One thing to note as well, is that none of this guarantees that the user actually sets any options we would like them to set. The namelist section could be completely empty! I am not sure whether that is super relevant in the sense that we are just trying to prevent the user from doing something pathologically wrong in that case. But that would mean that there is a possible extension of this where we also warn/error if certain options are never set even if the sections are present in the inlist files (this might break some use cases where options are set through run_star_extras, so we would need to be careful with that).

[Debraheem]

There is something to be said for forcing users to see empty namelist fields so their existence is known and recognized. In which case, forcing eos/kap/colors to be listed is better than not.