Do not overwrite namelist configuration when starting ungrib

[hugohartmann]

Describe the bug There is a possibility to change/save the namelist.wps configuration file. However, after starting ungrib, the namelist.wps is 'overwritten'by the default values (saved changes are lost).

To Reproduce Steps to reproduce the behavior:

1. Go to Run
2. Click on 'Open configuration.', make changes and "Save"
3. Click on 'Run Ungrib'
4. Check content of namelist.wps to see that changes made earlier are lost

Expected behavior Changes should not be overwritten

Operating System Information (please complete the following information):

• Windows 10

[letmaik]

I'd like to understand your scenario a bit better.

Those variables that are overwritten are derived directly from the domain configuration and met data selection, so changing them in the namelist is not supported. Other variables unrelated to that are not touched (if they are, it's a bug). You can see all the overwritten variables here: https://github.com/GIS4WRF/gis4wrf/blob/16148c7ddda7e1b18f6b975e117d3de316a04f3c/gis4wrf/core/transforms/project_to_wps_namelist.py#L24-L80

Did you try to change any of these? If so, why did you want to change them?

In terms of user interface I admit it should be made obvious which variables will be overwritten and shouldn't be changed in the editor.

[hugohartmann]

For a test case, I added a custom met data set with 3 hourly steps. When adding this dataset I prescribed a time resolution of 10800 seconds. I also set by mistake a wrong end date. Ungrib runs, but ends with an obvious error because of the wrong end date. So, I changed the end date in the WPS namelist and pressed "Save". However, this end date is overwritten by the wrong end date that I had set when adding the custom met dataset.

Secondly, I wanted to rerun ungrib with a time resolution of 3600 seconds (forcing ungrib to produce hourly interpolated output). However, this time resolution is also overwritten by what I had prescribed when adding the custom met dataset.

Of course I can change the settings in "Add a custom dataset", but it would be convenient to do this in "Open configuration".

If this is not desired, then clearly specify which fields can be changed in "Open configuration".

[dmey]

This is partially related to #78.

@hugohartmann: The first issue you described -- about not being able to change the value of interval_seconds -- was something we chose. I agree that this may be a bit confusing at the start but it should reduce errors when users configure namelists. I have made a note in #87 and will update the documentation accordingly. I think that when #78 is implemented, this will be less of an issue as users will no longer need to manually enter this information. If you think this is too restrictive let me us know and we can look at an alternative.

Re your second issue, I am not sure what you mean. Can you give me an example of how you would 'forcing ungrib to produce hourly interpolated output'?

[hugohartmann]

In this screenshot you see that I added 33 grib files with 3 hourly resolution. I have set "Interval in seconds" to 3600, forcing ungrib to produce hourly output.

[dmey]

I was not aware you could have a different value for interval_seconds than what's in the input files. The documentation describes interval_seconds as:

The integer number of seconds between time-varying meteorological input files. 

@hugohartmann are you sure that this is the expected use of interval_seconds -- I have not had a look at the code yet but I wonder if ungrib interpolates fields over time when given a different interval_seconds value. And if so what type of interpolation is it used?

If interval_seconds can be any arbitrary positive integer value not related to the input data then we should allow the user to change this in the configuration.

[hugohartmann]

ungrib.log

Here is the logfile when I set the interval to 3600s

[dmey]

OK, thanks. This needs a bit more investigation on what is actually being done by Ungrib in this case and if interval_seconds is meant to be used in this way.