Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Moving nest problem with sst_update and adaptive time steps


New member

I am trying the moving nest option in WRF 4.4, together with the sst_update option. That works well with fixed time steps but crashes with adaptive time steps:


It looks like the first time stamp after 03:00:00 is 03:00:04. WRF tries to read the wrflowinp_d02 file and doesn't find that time, then tries to read the next value until the file is exhausted:


The parameters step_to_output_time and adjust_output_time did not help.

When I turn off the sst_update option, the problem disappears. But I would like to update SST.

The case shown here is without nudging, but when I use spectral nudging a similar problem appears. The "time in file" read from the wrffdda_d02 file is falling exactly at 03:00:00 while the "Time om domain" is falling at 03:00:01, which results in reading the next time in the wrffdda_d02 file and ending up crashing.

Is there something I can do with that?

I uploaded relevant files to the cloud storage: the file name is emc_to_ncar.tar.gz

Thanks for your help



  • namelist.wps
    743 bytes · Views: 2
  • namelist.input
    5.3 KB · Views: 5
Hi Emmanuel,
The problem is likely that you're using output_diagnostics=1 with use_adaptive_time_step = .true. Unfortunately at this time, those will not work together.
The diagnostics option doesn't account for variable steps. There may be ways to modify the code to allow you to use both, but at this time, we don't have a solution. Perhaps someone else will see this and have some suggestions. I apologize for the inconvenience.
Thanks for your quick answer!
I can live without the diagnostics (I was aware the values were not reliable). No problem
I tried to simply set output_diagnostics=0 in namelist.input. This did not help. But I noted that the diagnostic files were surprisingly still created...
I removed all other lines having to do with auxhist3 in the namelist file and retried. Unfortunately the error is still there...
Thanks for trying that. When you run real.exe, is it actually creating a wrflowinp_d02 file?

I looked through some older correspondence I had with other users over the years and found that apparently the sst_update option does not run properly with vortex-following. The reason is that the update is only modified by the wrflowinp file, but that file shouldn't be created for d02 when running a vortex-following case. It's possible there are others who may read this and have been able to successfully make modifications to the code to allow for it, but at this time, we do not have any code that can do this.

The wrflowinp_d02 file is created by real.exe. I agree that it should not, since real.exe does not know were d02 is going to move...

I tried to remove the wrflowinp_d02 file, but then, the code crashed, protesting because of the absence of the file.

Note that I have tested option 2,2 for nudging and that the fdda_d02 file was, surprisingly, also created then... Logically, it fails with
grid_fdda = 2,2 and not with grid_fdda = 2,0

For now I will continue without update of SST and try the ocean model instead.