v6.0.0 namelist/runscript interaction

[egrell]

I am not sure if this is a design feature in v6; or a lack of understanding on my part as to the order of operations. It would be great to get some clarification.
I am running the LASSO_2016051812_MSDA case, and would like to use a timestep of 60s, rather than the standard 600s, with output every timestep. I added dt=60., n_itt_out=1, and n_itt_diag=1 to the case_config namelist for this case. In addition, I modified the column_area.
When I ran the SCM, though, only the column area was changed, according to the *.nml file in the output directory.
I then tried entering the 3 unchanged variables on the command line:
./run_scm.py -c LASSO_2016051812_MSDA -s SCM_GFS_v16 -dt 60. --n_itt_out 1 --n_itt_diag 1 > & testdt.out
And this worked. (Although I tried using --n_itt_diagt first, since that is what the User Guide has, but that looks like a typo: n_itt_diagt (in UG) should be n_itt_diag.)

My question is: What variables can be modified through the namelist in the case_config directory, and which have to be modified on the command line? (Or, why didn't the change to the time variables in the case_config namelist file affect the run, while the change to the column_area seems to have been used?)
A related question: Is there any way that I would be able to tell what timestep was used if I didn't output every timestep? I didn't see any printout from the model itself for v6.0, and this information does not seem to be in the logfile.

(Incidentally, I think there is a typo in the run_scm.py script, line 1014 (sutie should be suite)
active_sutie = suite(suite_name, tracers, namelist, -1, -1, False)
but this didn't impact my issue -- I just noticed it while searching for timestep.)

Thanks in advance for your response, and for all the effort to get this new version released!!

[grantfirl]

In #307, we moved variables that aren't really case-specific to command line arguments. These include the timestep, n_itt_out, and n_itt_diag. For the timestep, each suite has an associated default timestep listed in scm/src/suite_info.py that can be overwritten by the command line argument. It really doesn't make sense to specify this as "belonging" to a case. For the instantaneous and diagnostic intervals, those have default values in scm/src/run_scm.py and can also be specified by the command line. Even if they are included in the case configuration file, they are overwritten one way or another by the run script.

Which variables are on the command line and which are in the case configuration namelist file are listed in the updated v6 User's Guide (although it mistakenly mentions dt, n_itt_out, and n_itt_diag as being optional case configuration namelist variables -- they are not as explained above and I'll fix the User's Guide). See section 2.4.1 for the command line options and section 5.1.1 for the case configuration options (minus the mistake mentioned above).

The column area CAN be connected to a case (think of an observational field campaign domain), which is why it still exists in the case configuration namelist.

As for verification of the timestep used, the only way that I know of is to use the -v (verbose) argument to the run script so that it writes out iterations and modeled time. You're right that this would be good to write out to the logfile.

So, based on your comments, here is my TODO list:

1. Fix the User's Guide to remove dt, n_itt_out, and n_itt_diag as optional variables in the case configuration namelist file
2. Write the timestep and output intervals either as output in the run script or logfile (or both)
3. Fix the typo on line 1014 in the run script.

[egrell]

Thanks for the clarification -- that does help.
And sorry to give you a whole list of things to do!

[grantfirl]

FYI, while implementing these changes, I see that the timestep, n_itt_out, and n_itt_diag are written out to the namelist in the output directory already too. Regardless, I added some output from the run script too.

[egrell]

Sorry, I didn't phrase that question correctly. This must be really dumb, but I cannot find the printout from the executable. I only see the output from the run_scm.py script. What am I missing?

…

On Wed, Jul 6, 2022 at 11:03 AM Grant Firl ***@***.***> wrote: FYI, while implementing these changes, I see that the timestep, n_itt_out, and n_itt_diag are written out to the namelist in the output directory already too. Regardless, I added some output from the run script too. — Reply to this email directly, view it on GitHub <#337 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMPXGMMXQZZWD5GVJGYYJ3VSW335ANCNFSM52N5225Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[grantfirl]

One of the files written in the output directory is the case configuration namelist used, e.g. LASSO_2016051812_MSDA_SCM_GFS_v16.nml. It should have the values of dt, n_itt_out, and n_itt_diag used in the executable written to it.

[egrell]

Yes, I saw that. But I am looking for the printout (from the print and write statements in the scm executable).

…

On Thu, Jul 7, 2022 at 9:48 AM Grant Firl ***@***.***> wrote: One of the files written in the output directory is the case configuration namelist used, e.g. LASSO_2016051812_MSDA_SCM_GFS_v16.nml. It should have the values of dt, n_itt_out, and n_itt_diag used in the executable written to it. — Reply to this email directly, view it on GitHub <#337 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMPXGM72GTHPXPWXAJT7NDVS332ZANCNFSM52N5225Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[grantfirl]

So, you're referring to write statements from the executable that you see when using the -v option in the run script? If so, there are none; only what is documented by the run script. You can calculate the timestep since the iterations and modeled time are written to standard out, but there are no additional write statements denoting when data is being appended to the output file. It would be easy enough to add though if you really need it (perhaps when a debug option is set in order to not increase the standard output by default).