CALWRF multiple hour run crash

[Federico Carotenuto]

Kind All,

I'm currently trying to run a simulation with CALMET v6.5 using as meteorological input some 3D.dat files that I've created with CALWRF from a 43 hours long WRF simulation going from midnight of the 27 May 2005 up to 18:00 of the next day.

I'm experiencing a quite strange problem: if I try to run a simulation of two consecutive hours (say 04 to 05) it works perfectly, but as soon as I try to increase this step to 3 or more hours the software crashes with a "GAP in records error". 

All the relevant 3D.dat files are listed in the calmet.inp and in the correct folder, and this does not seem to be a file-related error: in the .lst file I find something like:

ERROR - in Subroutine RDMM5 - STOP
  Gap in MM5 record
  Current ending LST TIME (yyyyjulhr-sec):    200514705  -         3600
  Current LST MM5 TIME (yyyyjulhr - sec):    200514706  -            0
  Next LST MM5 TIME (yyyyjulhr - sec):    200514707  -           15
  MM5 Timestep:        3600

Initially I thought there was some "bad" 3D.dat file in the bunch, but this happens no matter what's the initial hour of the run: as soon as I try to make a simulation more than 2 hours long, it returns an error.

Did anybody experienced a similar problem? 

Thank you for your answers!

[Dreaming]

Hi Carotenuto .

It seems there's something wrong with your m3d file.

Would you please show your CALWRF.LST?

[Federico Carotenuto]

Dear Dreaming,

Thanks for your reply! Here in attachment there's the output LST file

[Dreaming]

I meant the LST file of CALWRF, not CALMET.

[Federico Carotenuto]

Sorry, I misunderstood! Here's the file. 

Since I had multiple WRF files and CALWRF accepted only one input, CALWRF was ran in loop through a MATLAB script. The latter changed the inp file on the basis of the file to process, launched a system command to execute the CALWRF executable, and renamed the output m3d file so that the next iteration of the cycle avoids to overwrite it.

[Dreaming]

Of course CALWRF can process multiple WRFOUT files. Set the number of WRFOUT files, and then specify the paths of WRFOUT files with one per line. Following the example in the attachment.

Try this.

Good luck.

[Federico Carotenuto]

Dear Dreaming,

I've used your .inp template to process some hours of my WRF outputs, but, alas, there are still some errors that elude me:

1) CALWRF completes succesfully, but for all files it complaints about the lack of "DYN_OPT" attribute. I thought it was weird since it's only the variable that tells if the netcdf file has been produced by NMM or ARW. I checked the files and the attribute is, in fact, truly absent: is this crucial for CALMET?

2) No matter the error, CALWRF produces correctly a 3D.dat file: size is consistent (roughly 7 mb per hour) and all the required information seem present in the file. Still, CALMET returns the same error if asked to run for more than 2 hours: GAP in MM5 files. I've manually checked the "Times" variable of my WRF files and the string is consistent: each files is tagged with the beginning of the hour it pertains to. 

CALWRF completes succesfully, so it doesn't seem to be a problem of reading the files...could it be some issue with the CALMET "clock" function? 

[Federico Carotenuto]

For anyone wondering: thanks to a private suggestion by Dreaming I ran it under Windows and it ran flawlessly. There's some unix thing under the hood that I cannot find causing such an error...

[Natasha Frilingou]

Hi everyone,

I run Calwrf through unix but Calmet through Windows and exprerience the same error " STOP in RDMM5 - GAP in records" when running more than one hour in Calmet.
I attach calwrf.lst and calmet.lst.
Any help of how this can be solved will be much appreciated!

Thanks,
Natasha

[Torrew]

I found a solution for the problem in UNIX.

When compiling with gfortran (v6), you need to specify the -Msave option (equivalent to -fno-automatic).

There is a problem with a msec variable otherwise.

This is also written at line 20615 of CALMET.FOR.

Right now, the program works fine in both UNIX and MAC OS X as well.