Specify ESMF Config File via environment variable?

[mathomp4]

In talking with @darianboggs about some ESMF stuff I was reminded of #2233 which fixed #2133, a request from @lizziel to allow the ability to set the ESMF logging level via a file rather than via command line option.

But, it is hardcoded that the file name is ESMF.rc and nothing else. Now, in MAPL3 land, this will need to be (or should be) a YAML file. So that means ESMF.yml or ESMF.yaml.

But but, @darianboggs reminded me that get_environment_variable does exist in Fortran.

So my thinking is maybe we should do something like:

1. Look for environment variable ESMF_CONTROL_FILE or whatever (@tclune will have good opinions on this). If found, check if the file ends in .rc, .yml or .yaml. If so, feed that in. (Note: I believe ESMF depends on a file ending in .yml or .yaml to trigger hconfig, so we would want to enforce that and then it makes our life easy if we say ESMF_Config files end in .rc.)
2. If no environment variable, look for ESMF.rc, ESMF.yml or ESMF.yaml, and use that
3. Check for command line argument.

Now, I suppose, the command line argument should maybe "win" this battle, but I also know the arguments might be going away in favor of yamls so... 🤷🏼

I suppose the question is: would this be useful? I can sort of see maybe having a set of control files for scripting purposes with different names and then using the environment variable to select?

[tclune]

ESMF logging can be controlled with the config file passed to ESMF_Init. No need for get_environment_variable. MAPL3 is already doing it this way.

[tclune]

Sorry - I think my previous answer misunderstood where the question was going.

This should be an issue for main.F90. MAPL3 will use a command line option (but a very simple one) to determine the top config file. GCHP can readily have their own main.F90 that uses get_environment_variable for the same purpose.

We could then consider somehow maintaining both variants inside MAPL for simplicity so that if things change we correct both. (Ideally these top files do very very little though.)

[lizziel]

Using get_environment_variable in the main driver fortran file works for us. And I support moving to yml too. I can make the updates in GCHP when we update to MAPL3.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. If there are no updates within 7 days, it will be closed. You can add the ":hourglass: Long Term" label to prevent the stale action from closing this issue.

[mathomp4]

@darianboggs Did we ever get something like this in?

[tclune]

For MAPL3, we will do this by virtue of the ESMF_Initialize() call accepting a config file that can specify ESMF logging level. Would be nice if MAPL2 does it that way too, but I've not looked to see if that conflicts with other choices.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. If there are no updates within 7 days, it will be closed. You can add the ":hourglass: Long Term" label to prevent the stale action from closing this issue.

[mathomp4]

Un-staling. I should work on this. This should be a very simple addition to MAPL.