WRF MP28 + SST/QNA update: “Could not find matching time in input file” with 3 domains (FNL input)

K

KL.ARUN

New member
I am running WRF with mp_physics = 28 using GFS FNL data as meteorological input. The simulation works in 2 domains, but fails when all three domains are active together with SST and QNA updates. It is running fine when either QNA or SST update is off. But when both options are turned on in 3 3-domain simulation, it is giving an error after 6 hours, which is the input interval for the Aux input files. I would appreciate help identifying what is wrong.
  • WRF version: 4.7.1
&time_control
interval_seconds = 21600,
input_from_file = .true., .true., .true.,
history_interval = 360, 180, 60,
frames_per_outfile = 1, 1, 1,
restart = .false.,
io_form_history = 2,
io_form_restart = 2,
io_form_input = 2,
io_form_boundary = 2,
auxinput4_inname = "wrflowinp_d<domain>",
auxinput4_interval = 360, 360, 360,
io_form_auxinput4 = 2,
auxinput17_inname = "wrfqnainp_d<domain>",
auxinput17_interval = 360, 360, 360,
io_form_auxinput17 = 2,
force_use_old_data = .true.,

&domains
p_top_requested = 3000,
num_metgrid_levels = 32,
num_metgrid_soil_levels = 4,
wif_input_opt = 1,
num_wif_levels = 30,
dx = 9000, 3000, 1000,
dy = 9000, 3000, 1000,
grid_id = 1, 2, 3,
parent_id = 1, 1, 2,

&physics
mp_physics = 28, 28, 28,
ra_lw_physics = 4, 4, 4,
ra_sw_physics = 4, 4, 4,
sf_sfclay_physics = 1, 1, 1,
sf_surface_physics = 2, 2, 2,
bl_pbl_physics = 1, 1, 1,
cu_physics = 1, 1, 0,
isfflx = 1,
ifsnow = 1,
icloud = 1,
surface_input_source = 1,
num_soil_layers = 4,
num_land_cat = 20,
qna_update = 1,
sst_update = 1,
tmn_update = 1,
sst_skin = 1,
/

ERROR,,
1765957977836.png

Any suggestions or examples of a working three‑domain MP28 + QNA + SST‑update configuration would be very helpful.

Thank you in advance for your help.
 
Thank you William for taking you time to see into my problem. I have attached below the zip of .out and .error files as you have asked.
 

Attachments

@KL.ARUN
Thanks for attaching the rsl files and the namelist. The error message you're getting is:

Code: 
d03 2018-08-13_06:00:00  Error trying to read metadata
d03 2018-08-13_06:00:00  Input data is acceptable to use:
           4  input_wrf: wrf_get_next_time current_date: 2018-08-13_06:00:00 Status =         -102
d03 2018-08-13_06:00:00  ---- ERROR: Could not find matching time in input file

This typically means you're missing some data in one of your input files for WRF. Can you issue the following commands and then attach all the *.txt files created?

Code: 
ncdump -v Times wrfbdy_d01 >& wrfbdy.txt

ncdump -v Times wrflowinp_d03 >& wrflowinpd03.txt

ncdump -v Times wrfqnainp_d03 >& wrfqnainpd03.txt
 
kwerner said:
@KL.ARUN
Thanks for attaching the rsl files and the namelist. The error message you're getting is:

Code: 
d03 2018-08-13_06:00:00  Error trying to read metadata
d03 2018-08-13_06:00:00  Input data is acceptable to use:
           4  input_wrf: wrf_get_next_time current_date: 2018-08-13_06:00:00 Status =         -102
d03 2018-08-13_06:00:00  ---- ERROR: Could not find matching time in input file

This typically means you're missing some data in one of your input files for WRF. Can you issue the following commands and then attach all the *.txt files created?

Code: 
ncdump -v Times wrfbdy_d01 >& wrfbdy.txt

ncdump -v Times wrflowinp_d03 >& wrflowinpd03.txt

ncdump -v Times wrfqnainp_d03 >& wrfqnainpd03.txt
Click to expand...
Thank you for your suggestion. I have already checked this and could not identify any missing time in the input files. Another notable observation is that the error does not occur when either the SST update or the QNA update is disabled; it appears only when both options are enabled simultaneously. The .txt files you mentioned are included as attachments for your reference.
 

Attachments

Last edited:
Hi,
I just want to let you know that I've been able to repeat your issue with a basic case I ran, turning on both sst_update and qna_update together, and only when running 3 domains (versus 2). It may take a while to get to the bottom of this, but I'm looking into it. Thank you for your patience while we determine a solution.
 
Hi again, I've found that this issue is resolved when I remove "force_use_old_data = .true." from the namelist prior to running real.exe. I was able to do this because my input data are later than V4 data. Are you having to use older input for your simulation?
 
Hello Kwerner,
Thank you for taking the time to look into my error. I'm using only WRF V4 inputs (no older versions), so I'll rerun the simulation without the force_use_old_data option and update you on the results.
 
Hello again,
After setting force_use_old_data=.f, the error has changed to an input error at the same 6th hour(given below). But I'm only using the same version of WRF.

Timing for Writing wrfout_d03_2024-07-27_06:00:00 for domain 3: 54.10665 elapsed seconds
d03 2024-07-27_06:00:00 Error trying to read metadata
d03 2024-07-27_06:00:00 File name that is causing troubles =
d03 2024-07-27_06:00:00 You can try 1) ensure that the input file was created with WRF v4 pre-processors, or
d03 2024-07-27_06:00:00 2) use force_use_old_data=T in the time_control record of the namelist.input file
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 342
---- ERROR: The input file appears to be from a pre-v4 version of WRF initialization routines
-------------------------------------------
 
You'll need to re-run real.exe because the files created by real.exe still have some sort of data attached to them, indicating they are from a pre-V4 version of WRF. This is probably because you had force_use_old_data=t when you ran real.exe. Try running real.exe again, and then wrf.exe and see if that makes a difference.
 
kwerner said:
You'll need to re-run real.exe because the files created by real.exe still have some sort of data attached to them, indicating they are from a pre-V4 version of WRF. This is probably because you had force_use_old_data=t when you ran real.exe. Try running real.exe again, and then wrf.exe and see if that makes a difference.
Click to expand...
Hi, I have tried running "real" again with force_use_old_data=f with the same version of WRF. But still the same error persists. My WPS is 4.6, and WRF is 4.7.1.
 
Thanks for trying that. Can you send me the met_em* files for the initial time (2018-08-13_00:00:00) and 6 hours later (2018-08-13_06:00:00) for all 3 domains so that I can try to test this out? These files will be too large to attach here, so please see the home page of this forum for instructions on sharing large files. Thanks!
 
Hello Kwerner. Thank you for taking an interest in this issue. Sorry for the late reply.
I've uploaded the metfiles from another, smaller domain setup that has the same issue. I've also attached the namelist.input file and rsl.error.0000 for your reference. file name in the Box is : FILES01.post.59218.tar.gz
 
Thanks for sharing those files. Using your files and namelist, I was able to run the 6 hours without any issues. I'm not sure why you're seeing the error that you are. The only thing I know to suggest at this point is to have you get an entirely new/clean version of WRF, build it, and then try running this again, starting with real.exe, and then wrf.exe and see if that makes any difference. I know it sounds like a weird fix, but occasionally we see this solution work - likely because something has been modified in the code that the user didn't recall/realize.
 
Thank you again for the suggestion. I will definitely try compiling another WRF version and test the fix.
However, since I have encountered the same error on three different machines, I wanted to clarify one point: in my case, the simulation runs up to 6 hours without issues. The SST and QNA updates are both 6‑hourly, and the model successfully writes the output at the 6th hour. After that, when it proceeds beyond 6 hours, it crashes and produces the error shown in the rsl files I attached.
Could you please confirm whether, in your setup, the run continues past the 6th hour and actually writes the 7th‑hour output as well? [Metfiles are uploaded in the box FILES02.post.59218.tar.gz ]
 
Hi, I just want to let you know that I am now able to repeat the issue you are seeing, even with my own case. I also confirmed again this only happens when running with 3 domains - I encountered no issues when running 1 or 2 domains. I'm not sure why it's happening yet, but I'll keep you posted as I dig through the code.
 
Thank you for your continuous support in this regard. Hope we will find out soon.
kwerner said:
Hi, I just want to let you know that I am now able to repeat the issue you are seeing, even with my own case. I also confirmed again this only happens when running with 3 domains - I encountered no issues when running 1 or 2 domains. I'm not sure why it's happening yet, but I'll keep you posted as I dig through the code.
Click to expand...
 
@KL.ARUN, using the reproduced runs from @kwerner I believe I've identified the issue as improper IO data handle management in QNA that just got revealed in this particular model setup.

This should be the necessary fix to resolve this issue:
github.com

Ensure clearing of data handle upon freeing by islas · Pull Request #2292 · wrf-model/WRF

Certain parts of the code were not properly clearing data handles stored in grid variable, and this change makes any call to close_dataset always clear the value. TYPE: bug fix KEYWORDS: io, data_h...
github.com github.com

Fortunately the changes are very minor, so if you want you can test them out by incorporating them into your existing code.
 
islas said:
@KL.ARUN, using the reproduced runs from @kwerner I believe I've identified the issue as improper IO data handle management in QNA that just got revealed in this particular model setup.

This should be the necessary fix to resolve this issue:
github.com

Ensure clearing of data handle upon freeing by islas · Pull Request #2292 · wrf-model/WRF

Certain parts of the code were not properly clearing data handles stored in grid variable, and this change makes any call to close_dataset always clear the value. TYPE: bug fix KEYWORDS: io, data_h...
github.com github.com

Fortunately the changes are very minor, so if you want you can test them out by incorporating them into your existing code.
Click to expand...
Thank you for the quick response and for helping resolve this issue. I tested the suggested fix with a few cases, and it worked perfectly. Appreciate the prompt support and effort!
 
You must log in or register to reply here.
Back
Top