Moving nest issue with high resolution input geographical

[flaounas]

Good afternoon,

I have an issue with running WRF in a moving nest configuration (preset moves). The model works great and we have performed several simulations. Now we would like to use high resolution input fields for the geographical features but it seems that we came across several problems. Here are the steps we've followed up to now

1) We use model version 4.4.2 compiled with TERRAIN_AND_LANDUSE option activated (please find our configure.wrf in the attachments)

2) For WPS we have downloaded the "Highest Resolution of each Mandatory Field" but it seems that geogrid.exe cannot find the landuse for 30s when using 'usgs_30s+default’' in the namelist.wps (in the attachment). If however we download landuse_30s_with_lakes dataset for simulations prior to 2000, then it seems that geogrid can run if we select 'usgs_lakes'.

3) We have then downloaded the dataset from here: https://www2.mmm.ucar.edu/wrf/src/wrf_files/data4movingnest.html and included the necessary entries to the namelist.input (see attachment).

4) The real.exe runs well but wrf crushes after performing the first move (rsl.error/out.0000 in the attachment).

5) If we run the model with input_from_hires = .false., .false., then it runs without problem.

6) One additional question about the high resolution fields: Should high resolution geographical features be interpolated to the nested domain only after the first move or since the first model output? (in our case the nested domain starts same time with the parent domain).

Thank you for all help,

Kind regards,
Manos

 

[flaounas]

just an update... in case it is helpful

in case I run the model with 'usgs_30s+default’, I need to set 24 land categories and I get the attached rsl.error.0000 that relates to interpolation error for lakes. The model again crushes only when the domain is moving.

 

[kwerner]

Hi,
Unfortunately the high-resolution terrain/landuse option for moving nests is only applicable with the vortex-following configuration of WRF, so it will not work when WRF is compiled for preset moves.

 

[flaounas]

Many thanks for the reply,

I would like to give it a shot and try to modify the code myself so that high-resolution is also applicable to preset moves.

I guess however that there is a chain of calls in the different drivers of the model where the code checks whether TERRAIN_AND_LANDUSE option is included in the configure.wrf. If you have any tips about this chain of calls it would be just very helpful! In any case many thanks for the confirmation!

 

[kwerner]

Hi,
I'm not very familiar with that part of the code, but I would advise that you just follow that chain one step at a time, and use the vortex-following option as an example. Good luck!

 

[tacol55]

Hi,
Related to the question by flaounas, I would like to confirm the usage of the high-resolution topographical data in the preset moving nest.

As for an initial test before modifying the code in WRF, as mentioned in the earlier comment, I bit changed a compilation setting as attached (I changed the format to .txt to avoid the upload error), then compiled the WRF code. I replaced all the flags -DLANDREAD_STUB=1 to -DTERRAIN_AND_LANDUSE in this change.
Unlike my first expectation, the compilation was finished without any errors, and the model seems to run successfully, updating the child nest's topography to the high-resolution data. During this simulation, WRF v4.1.2 was used.

Meanwhile, I also doubt that this change was reasonable since the combination (i.e., the preset moving option + the high reso. data) has not been supported officially. Therefore, I would like to share the above experience and know whether this change is correct.

 

[kwerner]

@tacol55
The documentation just says that it works for the vortex-following case, but it does not specifically say it doesn't work for the preset moves option. We haven't tested it for that case. I would suggest taking a look at the fields in your output to make sure they are reasonable. If so, then perhaps it is okay to use.

 

[tacol55]

Hi Kwerner,

Sure. I will take a look at the result more deeply. Thank you for your response.