I am using OpenIFS CY43R1 to simulate the AMORE-France region. I set up the model using the EartH2Observe dataset and run it with ERAI forcing for the period 1995 to 2004. Some months into the simulation, at the beginning of the first April, evaporation starts to explode over the course of a few days at a few grid cells. This seems to be caused by the variable PCFQTI having values larger than 4. in surfexcdriver_ctl_mod.F90 after subroutine VEXCS is called in line 711. Right before that subroutine is called the number of iterations for the solver in VEXCS is set to one (IITT = 1 in line 707). Increasing this number to 10 solves this problem. If I understand correctly, this means that the first solution that is calculated in VEXCS is not appropriate and iteration of the solver is required.
My question is why a value of 1 for IITT has been chosen here and if there is any argument against increasing this number.
Thanks
Stephan
p.s.: If you wish for a minimal working example, please indicate to me the files that you would like me to share.
4 Comments
Unknown User (nagc)
Hi Stephan,
Can you let us know which tile(s) it is that's blowing up? ( PCFQTI(:,KTILES) )
Thanks, Glenn
Unknown User (stephan.thober@ufz.de)
Hi Glenn,
it is tile 3 (JT=3).
Best,
Stephan
Gabriele Arduini
Hi Stephan,
The tile 3 corresponds to the interception reservoir tile. This tile represents a thin layer on top of the soil/vegetation and it evaporates at the potential rate. This could lead to some rapid change from stable to unstable conditions in the surface layer in some particular cases.
Coming to your question, the value of IITT = 1 was chosen as in principle the value of the monin obukhov length (L) from the previous time-step should be close to the one for the current time-step, so ensuring the convergence of the algorithm. The fact that increasing the number of iterations solves your problem let me think that this can be related to large variations in the value of L from one time-step to the next one. Do you see large variations in the skin temperature as well even if the model is numerically stable for this period?
However, we never encountered such an issue (model blowing up) running the land-surface model forced with ERA-Interim for very long periods (from 1979 to current days for instance).
Could you please let us know some more details about your model setup, as the height at which you apply the forcing, horizontal resolution, time step? Are the "exploding" grid points characterized by a particular orography (e.g. very complex terrain)?
Thanks,
Gabriele
Unknown User (stephan.thober@ufz.de)
Hi Gabriele,
you are right that there are large variations in skin temperature, particularly at 15:30 and 18:30, so the first time steps after the forcing at 15:00 and 18:00 hours enters the model. Large variations means that skin temperature easily exceeds 100 deg C (see timeseries below). Mostly, the model is able to reduce these high temperatures after a few time steps. This happens almost everywhere west of a specific longitude that moves east as the simulation time continues from January to April (see map below). In some of these grid cells the errors prevails throughout the entire simulation. I browsed through the forcing data, but could not find any specific values leading to these high temperatures. Also, orography does not seem to play a role. However, I changed NACCTYPE from 2 to 0 and LSWINT from True to False in the input namelist and that did the trick. Now, this issue does not pop up anymore. Does this make sense for you? I am a beginner using HTESSEL. I cannot remember modifying these entries of the input namelist. Did I overlooked anything? As I am a beginner, I would be grateful if you could have a quick look at the setup that I have created. I am attaching for you a minimal working example. Could you please use this to verify that you are getting the same error.
Thanks,
Stephan