profile_interval control has unexpected dependance on history_interval

[evbauer]

I happened to have these settings while working today:

profile_interval = 1
history_interval = 10

Instead of writing a profile every step, MESA only wrote one every 10 steps. Right now MESA will only save a profile if it is also writing to the history file for that step. I don't think this is consistent with the documentation of how these controls are supposed to work, so we should probably change it.

[rjfarmer]

@evbauer are you sure? I just ran with those settings for 100 steps and got 100 profile files outputted. Did you have priority_profile_interval set in some way that might be deleting the intermediate profiles?

[evbauer]

Hmmm, thanks for checking. Going back to it, it's not as easy to reproduce as I had thought. I'll look a bit closer. I think you're right that there's something going on with the profile priority.

[evbauer]

Weird. It took me a while to come up with a good MWE because it turns out that terminal_interval is involved as well. Here's a very simple MWE:

&controls

      profile_interval = 1
      history_interval = 10
      terminal_interval = 10

/ ! end of controls namelist

Empirically, it looks to me like the profiles end up getting saved on this interval max(profile_interval,min(history_interval,terminal_interval))

[evbauer]

Well, now that I'm reading the code, it seems pretty intentionally set this way. Why?

Here's where we decide if we're going to write a profile. https://github.com/MESAHub/mesa/blob/185398e6f1252d32c2497edec57ad71ecc6cd5dd/star/private/do_one_utils.f90#L1527-L1529

And here's where we set that logical to depend on either writing to history or writing to terminal. https://github.com/MESAHub/mesa/blob/185398e6f1252d32c2497edec57ad71ecc6cd5dd/star/private/do_one_utils.f90#L529

[rjfarmer]

Maybe the profile output at some point in time depended (or still does?) on something from the history/terminal output being set?

[evbauer]

Oh, maybe the profile header information? I suppose it could be sufficient just to document this behavior in controls.defaults, but I might try to track this logic a little further before deciding what to do.

[rjfarmer]

I think everything in the header gets setup by do_report which gets called independent of the output. It may just be leftover code that no one noticed

[rjfarmer]

What about just trying some models with/without the logged check and see if the profile files match?