Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not overwrite namelist configuration when starting ungrib #55

Open
hugohartmann opened this issue Sep 25, 2018 · 7 comments
Open

Do not overwrite namelist configuration when starting ungrib #55

hugohartmann opened this issue Sep 25, 2018 · 7 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@hugohartmann
Copy link

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
Copy link
Contributor

letmaik commented Sep 25, 2018

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:

wps['share'] = OrderedDict(
nocolons = True,
max_dom = num_domains
)
try:
met_spec = project.met_dataset_spec
except KeyError:
pass
else:
wps['share'].update(
start_date = [to_wrf_date(met_spec['time_range'][0])] * num_domains,
end_date = [to_wrf_date(met_spec['time_range'][1])] * num_domains,
interval_seconds = met_spec['interval_seconds']
)
# When a GIS4WRF project is not used, we construct the path
# to the geog folder with a dummy string.
try:
geog_data_path = project.geog_data_path + '/'
except:
geog_data_path = '/path/to/geog/folder'
wps['geogrid'] = OrderedDict(
parent_id = [1] + list(range(1, num_domains)),
parent_grid_ratio = [1] + [domain['parent_cell_size_ratio'] for domain in domains[:0:-1]],
i_parent_start = [domain['parent_start'][0] for domain in domains[::-1]],
j_parent_start = [domain['parent_start'][1] for domain in domains[::-1]],
# e_we and e_sn represent the number of velocity points (i.e., u-staggered or v-staggered points)
# which is one more than the number of cells in each dimension.
e_we = [domain['domain_size'][0] + domain['padding_left'] + domain['padding_right'] + 1 for domain in domains[::-1]],
e_sn = [domain['domain_size'][1] + domain['padding_bottom'] + domain['padding_top'] + 1 for domain in domains[::-1]],
map_proj = map_proj,
dx = outermost_domain['cell_size'][0],
dy = outermost_domain['cell_size'][1],
ref_lon = outermost_domain['center_lonlat'][0],
ref_lat = outermost_domain['center_lonlat'][1],
geog_data_res = project.geo_dataset_specs[::-1],
geog_data_path = geog_data_path
)
if map_proj in ['lambert', 'mercator', 'polar']:
wps['geogrid']['truelat1'] = innermost_domain['truelat1']
if map_proj == 'lambert':
wps['geogrid']['truelat2'] = innermost_domain['truelat2']
if map_proj in ['lambert', 'polar']:
wps['geogrid']['stand_lon'] = innermost_domain['center_lonlat'][0]
if map_proj == 'lat-lon':
wps['geogrid']['stand_lon'] = innermost_domain['stand_lon'] # rotation
# wps['geogrid']['pole_lat'] = innermost_domain['pole_lat']
# wps['geogrid']['pole_lon'] = innermost_domain['pole_lon']
wps['metgrid'] = OrderedDict(
fg_name = ['FILE']
)

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
Copy link
Author

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 dmey self-assigned this Sep 27, 2018
@dmey
Copy link
Contributor

dmey commented Sep 30, 2018

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
Copy link
Author

image

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
Copy link
Contributor

dmey commented Oct 1, 2018

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
Copy link
Author

ungrib.log

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

@dmey
Copy link
Contributor

dmey commented Oct 1, 2018

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.

@letmaik letmaik added the enhancement New feature or request label Nov 14, 2019
@letmaik letmaik added this to the Future milestone Nov 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants