Error running ndown : "Found *date*_06:00 before I found *date*_00:00"

[Arty]

Hello,

I got previous data from a 33 vert. levels simulation accross South Pacific I want to use for a downscaling simulation over a smaller area. I'm aware of UPP possibilities and I intend to try it next, but I would like to make it work with ndown.

I passed the real.exe step and got all required files (including specific ndown files) cheating a little bit : I got 33-levels wrfouts* but 50-levels met_em --> that's the only way I managed to run real.exe / else I got "Not enough levels to reach p_top (5000)" error when setting 33 levels. I was said it shouldn't be problematic, but it might anyway (now or later), so it seems legit to inform you.
So, when I run my test configuration (see attached file for namelist) for 5 days, it crashes immediately and I get this in rsl.error.0000 :

-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 366
Found 2005-02-02_06:00:00 before I found 2005-02-02_00:00:00.
-------------------------------------------

I checked (the best I could) all paths in the PBS script to exclude this possibilty : seems OK. Anyway, this doesn't seem like a file location problem, as one file is found, but not the previous one. I also checked that I have all met_em* and other files for each required 6-hours timesteps : I do ; only wrfout* used as input for downscalig are recorded as daily files.

I'm kind of stuck here so if anyone have an idea how to solve this problem, it'd be great.

Also : could someone tell me where should I look about this line :

FATAL CALLED FROM FILE: <stdin> LINE: 366

There must be something intersting to understand the error, but I don't know where to look (except the LINE number).

Thank you.

 

[kwerner]

Hi,
A couple of questions:
1) Are you getting this error when you run ndown.exe? Can you detail the steps you took and which files you have before/after each step?
2) When you say you obtained previous data, do you mean you have wrfout* files from a previous run? Do you still have the wrfbdy_d01 file for the parent domain?
3) Can you attach the full output/error file (e.g., rsl.error.0000)?
Thanks!

 

[Arty]

Hi,
A couple of questions:
1) Are you getting this error when you run ndown.exe? Can you detail the steps you took and which files you have before/after each step?
2) When you say you obtained previous data, do you mean you have wrfout* files from a previous run? Do you still have the wrfbdy_d01 file for the parent domain?
3) Can you attach the full output/error file (e.g., rsl.error.0000)?
Thanks!

Hello kwerner

1) Yes (see Help & tips using ndown for config details)

2) Yes, wrfout* I'm willing to use as input come from previous PhD work
And no : I recreated wrfbdy from a new config which d01 is exactly the same as my wrfout* and forced by CFSR --> because I've been told I only need few timesteps (via real.exe) to initiate ndown/wrf.exe.

3) I didn't save it and I circumvented the problem (and got new errors... so much fun xD) :
I just changed my namelist to start simulation on the 3rd of February instead of 2nd. First timestep is always 06:00 and not 00:00 hence I was missing the 00:00 timestep for the 2nd of February and simulation crashes.

This case can be closed. Thanks for your answer anyway, it's very conforting not feeling alone in all this.

 

[kwerner]

Thank you for updating the post with the problem and solution. It may help another user in the future! Glad you got it figured out.

 

[Kongs]

Hello kwerner

1) Yes (see Help & tips using ndown for config details)

2) Yes, wrfout* I'm willing to use as input come from previous PhD work
And no : I recreated wrfbdy from a new config which d01 is exactly the same as my wrfout* and forced by CFSR --> because I've been told I only need few timesteps (via real.exe) to initiate ndown/wrf.exe.

3) I didn't save it and I circumvented the problem (and got new errors... so much fun xD) :
I just changed my namelist to start simulation on the 3rd of February instead of 2nd. First timestep is always 06:00 and not 00:00 hence I was missing the 00:00 timestep for the 2nd of February and simulation crashes.

This case can be closed. Thanks for your answer anyway, it's very conforting not feeling alone in all this.

Hello, I have also encountered this problem with you. May I know how to solve it?

 

[Arty]

Hello, I have also encountered this problem with you. May I know how to solve it?

I had input files which started at different times between wrfinput (created by WPS/REAL) starting at 00:00 and wrfout (input for ndown.exe) starting at 06:00. I was missing a timestep so I just did post-schedule my ndown-run start-time to the next day (I could have post-scheduled from just 1 timestep).
Does this help ?

 

[Kongs]

我的输入文件在 wrfinput（由 WPS/REAL 创建）从 00:00 开始和 wrfout（ndown.exe 的输入）从 06:00 开始之间的不同时间开始。我错过了一个时间步，所以我只是将我的 ndown-run 开始时间后安排到第二天（我可以只从 1 个时间步开始后安排）。
这有帮助吗？

Thank you very much for your reply. My input file time is consistent with the wrfout time, but this error still occurs. I will try again. Thank you

 

[george_victor]

Hi! @Kongs, in case you haven't solved the issue yet; the issue is probably because the model is expecting inputs at a certain time interval (interval_seconds in namelist.input), but the wrfout_d0*_<date> file that you use is having a different data/time interval. This mis match results in the error. Changing "interval_seconds" in namelist.input would therefore solve the concern.

For example: interval_seconds=3600 (1 hour)... but your model wrfout_d*_<date> file have data every 3hours, then this error will pop up.

In case there is another reason like @Arty pointed out, please share with us.

 

[samudra]

I have been experiencing the same issue while using the ndown.exe. I have even kept the interval_seconds and wrfout_d* files in the same interval time as mentioned from namelist file too. I am attaching my rsl.error file and namelist.input files herewith. I have done all the steps as mentioned in the user guide.

 

[Arty]

I have been experiencing the same issue while using the ndown.exe. I have even kept the interval_seconds and wrfout_d* files in the same interval time as mentioned from namelist file too. I am attaching my rsl.error file and namelist.input files herewith. I have done all the steps as mentioned in the user guide.

From your rsl* file, I can read that your wrfndi_d02 does not start at the same date as the namelist states (edit : in fact it is not the start, but the second time-step - see last message) :

Input data is acceptable to use: wrfndi_d02
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:     368
Found 2006-08-01_01:01:12 before I found 2006-08-01_01:00:00.

Moreover, I find it quite strange that your wrfndi_d02 or wrfout* used as input for NDOWN has a " 01:01:12 " time-stamp. Is it expected ?
Anyway, you need to make sure that the start dates and time-steps are the same between wrfndi/wrfout and the NDOWN namelist.

Also - it is more of a WRF than NDOWN remark -, I don't know for more recent version of WRF, but I'm surprised by the 108 seconds time-steps. I thought WRF prefered timestep value that divides 3600 giving an integer.

 

[samudra]

Hii,
I checked the time variable in the wrfndi file and it shows the same date as in my namelist file (attaching a screenshot). I have not made any changes to my namelist file in terms of time step between wrfout/wrfndi and NDOWN runs.
Secondly, even I have not been able to understand why I am having this time-stamp, I have initialized my interval seconds as 3600 and history interval to be the same, so I would expect my output files at an hourly separation.
Also, 108 sec timestep is based on my domain resolution, which i found in the documentation that time step should be ideally 3xDX or 4xDX, where DX is my domain resolution in kms. Since my outer domain is 27km, I went with 27x4= 108 as my time-step.

 

[Arty]

Hii,
I checked the time variable in the wrfndi file and it shows the same date as in my namelist file (attaching a screenshot). I have not made any changes to my namelist file in terms of time step between wrfout/wrfndi and NDOWN runs.
Secondly, even I have not been able to understand why I am having this time-stamp, I have initialized my interval seconds as 3600 and history interval to be the same, so I would expect my output files at an hourly separation.
Also, 108 sec timestep is based on my domain resolution, which i found in the documentation that time step should be ideally 3xDX or 4xDX, where DX is my domain resolution in kms. Since my outer domain is 27km, I went with 27x4= 108 as my time-step.

OK, did you already run your model (WRF) with this timestep ? If not, you might have to deal with the timestep later. BTW, from my knowledge, a 6DX timestep is OK (and will be less time consuming). I mentioned the timestep because I had trouble when originally setting my model timestep to 42s for a 7km resolution and WRF didn't want to run (3600/42 = not integer) : had to change it to 40s.

Oh... That makes me think. I believe I understand where your problem comes from :

Your rsl* file states that it finds a time-step at 01:01:12, which corresponds to 3600 + 60 + 12 = 3672 seconds : 3672 / 108 (your time-steps) = 34, an integer. I think you really must choose a timestep that divides 3600 seconds (= hourly outputs) by an integer. The fact is that the second timestep of your wrfout* does not match the second time-step of your namelist. You cannot get an output in the middle of an unprocessed time-step.

Lastly : the 6DX (or 4DX) rule is not a "rule" per se : it is more of an order of magnitude to avoid CFL crash. It is advised however not be higher than 6DX. Example, my case above : 6DX = 42 ; I could have chosen 45s (that also divides 3600 in an integer) but I rather chose 40s.
Please note, however, that this rule only applies for the mother domain : if you ever model nested domains, then the nested domain's time-step may not be an integer as WRF will decompose the new time-step as its integer part plus its fraction part ; example with my own case : I nested a 2.333km domain inside my 7km domain, the time-step of 40s in d01 was divded by 3 (as the resolution ratio) which lead to a 13 + 1/3 time-step for d02 (see that 3600 / (13 + 1/3) = 270 : still an integer so that one hour always contains an integer number of time-steps).