Push notifications in your browser are not yet configured.
You are not logged in, you may not see all content and functionalities. If you have an account, please login .
gribout ERROR plev for interpolation above model top
Dear colleagues,
I’m doing CCLM simulations over East-Asia with ERA -Interim data.
cclm version: cosmo_131108_5.0_clm2
int2lm version: int2lm_131101_2.00_clm1
webpep version: EXTPAR -2.0.2
First in a smaller domain, around 17~42N 100~130E (see domainsGEscreen.jpg attached below), all seems ok.
Then in a larger domain, around 6~62N 65~165E, the gribout error happened when it tried to write the first simulated output for plevs (e.g. lffd1995010106p.nc) other than the initial time (e.g. lffd1995010100p.nc), with this error messages:
—————————————————————————————— * PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED * IN ROUTINE : p_int * ERROR CODE is 1004 * plev for interpolation above model top! ——————————————————————————————My cclm namelist options and run log for the larger domain are attached below too.
BUT if I chose not to interpolate model level data to pressure levels, it could run continiously.
Thank you very much for any suggestions!
Weidan
I cannot see what can be wrong. It might be a bug in the program. You want to have the variables U,V,W,T,RELHUM,FI,QV on p-levels. Can you check it without W, i.e. yvarpl=‘FI’,‘QV’,‘T’,‘U’,‘V’,‘ RELHUM ’,
and put the variable ‘P’ in GRIBOUT group 3 and check the first level in the output?
Hello Weidan,
in your cclm_735_stdout.txt file I see, that you get CFL violations during the run. The output for lffd1995010106p.nc is the first after these violations where you interpolate on pressure levels.
You should check, whether these CFL -violations ruin your simulation. Often, the interpolation to pressure levels is the first part, where the model notices that.
Ciao
Uli
Dear colleagues, I have faced the same problem recently. I have done the nesting simulation (cclm-to-cclm) from 0.165 to 0.025 resolution. After 1 day it crashes with the error ‘plev for interpolation above model top’ (see slurm-1151761.out). I have mentioned the NaN values in YU* files before crash. According to your advice about CFL -criterion, I have adopted the dt parameter (by decreasing it at first to 30 and then to 20), but it didn’t change the result. Besides, this simulation is associated with extreme winds (up to 30-40 m/s near surface). Maybe, it could also affect these results? Could you give any suggestions about many namelists parameters or something other?
I’m attaching also YU* files, output in point (M_Teriberka) and script (cclm5_arctic_nest_modified.sh).
Thank you for any hints.
Dear all
When running simulations with CCLM on a 0.025° resolution grid (~2.8 km) I have encountered the same issue described here. In my case, the output of the running jobs yields no warning message referring to the violation of the CFL criterion. Nonetheless the same NaN values in the YUPRMASS file appear.
I have tried reducing the time step of the model up to 5 seconds, but this won’t make any difference. Besides, I have tried to choose a different set of pressure levels to interpolate to, with, obviously a lower highest pressure level, but this neither has an impact on my simulations.
Does anybody else know of a different solution? I was thinking in increasing the number of model levels since I think this could interfere with the fact that I have anomalously big values of wind speed in my simulations.
Any help would be appreciated.
With kind regards
Alberto
PS I attach the output of my model runs
Dear all
I have managed to overcome the problem of the ERROR 1004 interpolation to the pressure levels.
Trying a denser number of model levels yielded no difference, instead I have been playing with the parameters in the TUNING namelist.
I have managed to isolate the problem, that arises when the scheme for the fast waves number two is adopted (fast_waves_sc.f90) where, accordingly the type of bottom boundary conditions needs to be changed.
So for example if my settings were ldyn_bbc = .FALSE., rlwidth=50000.0, nrdtau = 5, iadv_order = 5, itype_bbc_w = 114, itype_fast_waves = 2,
The error would be shown, as opposite to the settings:
ldyn_bbc = .TRUE., rlwidth=50000.0, nrdtau = 5, iadv_order = 5, itype_bbc_w = 1, itype_fast_waves = 1,That entail no error.
Regards
Alberto
Dear colleagues,
I am writing again in this thread since unfortunately I got the same error message some time steps later in my simulation.
The settings I described in my last contribution to the thread were able to delay the appearing of NaN values in YUPRMASS until the time step 5568 (before it would stop on a previous time step ).
This time, I got some error messages mentioning the CFL criterion. In order to avoid this problem I reduced the time step to 10 seconds. I am using a 2.8km grid so normally with 20 seconds it should suffice.
Once done that, the CFL -criterion violation messages disappear, still I am getting the plev interpolation error messages.
I also tried substituting W for OMEGA in the GRIBOUT parameters, nevertheless the values shown in YUPRMASS still explode to NaNs.
Does anybody know where the problem could be? Or if anybody did CCLM simulations on a 2.8 grid over mountain areas such as the Alps, could you send me the settings used?
I attach the settings that I am currently using together with the model debugging output.
Thanks in advance
Alberto
Hi Alberto,
looking at your data I saw a few things that are rather strange for me.
1.) What is the reason of applying a vertical grid spacing of 240 m between the surface and the first level above the surface (see YUSPECIF file)
2.) Your T_S and T_SO fields (see your laf-file) do have very high maximum values (larger than 340K, see YUCHKDAT ). If I interpret you model domain correctly (mostly southern France, part of the Med-Sea, western parts of
Switzerland and Italy, a little bit of Spain) I would not expect such high values.
3.) Minimum T values (3-D Temperature on Model Levels) fall below 200 K in the lowest model level during your simulation (see YUCHKDAT ). I would say this is much too low even for the highest summit of the Alps. ( I did not check where the low value occurs)
My conclusion: your problem is due to some completely unphysical conditions that occur during the simulation and which let the model explode. The error message that you get is due to a follow up error.
Hans-Juergen