CCLM for Middle East with ERA Interim – in #9: CCLM

  @burkhardtrockel in #cd01890

<p> Your post processing job does not work, therefore your job chain do not proceed to the next month. <br/> At the end of cclm.o272921 (i.e. after six month) the post job is submitted <br/> <pre> ----- CCLM finished *********************** * submitting POST job * *********************** 272978.admin </pre> <br/> However, ccpost.o272978 is empty. <br/> This is the same for your other attempts. <br/> You may try “subchain post”. If this still gives an empty output there is something wrong in the the post job. In that case I am afraid you have to put some “echo test” commands in your post job to find the line where it stops. </p> <p> By the way, please adopt the paths to the <span class="caps"> NCO </span> and <span class="caps"> CDO </span> routines properly, e.g. I found a wrong path to nccopy in the post job: <br/> <pre> /var/spool/PBS/mom_priv/jobs/272720.admin.SC[106]: /sw/aix61/netcdf-4.2.1.1/bin/nccopy: not found [No such file or directory] </pre> </p>

  @redc_migration in #44631bf

<p> Dear experts! <br/> I have performed a 2 year experiment with <span class="caps"> ERA </span> Interim driving data using two (50 km and 12 km) nested domains over the eastern Mediterranean region. The results appear reasonable to me except for the annual monthly… precipitation amounts which are about 50% lower than those observed. A positive T2m bias may also be indicated. The run has been performed using cclm 4.08_clm19 and the standard settings which are possibly are optimal for midlatitudes but are less appropriate for the subtropical area. What would be your recommendations on the subject? Which changes of the tuning parameters may help? <br/> Regards, Simon </p>

  @hans-jürgenpanitz in #a982179

<p> Dear Simon, </p> <p> without any further information <span class="caps"> NOBODY </span> , even the most experienced expert, can help. <br/> One needs at least a <span class="caps"> YUSPECIF </span> file, created by <span class="caps"> CCLM </span> , for both of your simulation, the 50 km one and the 12 km on. </p> <p> Best regards </p> <p> Hans-Juergen </p>

  @redc_migration in #073f463

<p> Dear Hans-Juergen,colleagues, <br/> Attached are the <span class="caps"> YSPECIF </span> produced in the 12 km and 50 km <span class="caps"> CCLM </span> runs indicated in my previous message as well as the corresponding pictures with the seasonal precipitation and T2m obtained. For the resolution please see the file names. <br/> Regards, Simon </p>

  @redc_migration in #493a9ee

<p> Dear colleagues, <br/> Attached please see the files indicated in my previous message. <br/> Simon </p>

  @hans-jürgenpanitz in #9469293

<p> Dear Simon, </p> <p> I am afraid, there will not be the “one and only” parameter that might improve your results. <br/> However, I have, at first, two suggestions, which you can try, and which require re-calculations of <span class="caps"> CCLM </span> only. <br/> That means, you can further use your forcing data that you have calculated with INT2LM <br/> The first suggestion: <br/> one tuning parameter, which might be of interest, is “rat_sea”, which has a default value of 20, which you have used. <br/> Decrease this parameter to the lowest value, which is allowed: rat_sea=1. <br/> My experience is, that decreasing the value of rat_sea increases the precipitation; however, in my sensitivity runs for Africa the <br/> increase was not very large. </p> <p> The second suggestion: <br/> increase the parameter “rdheight” from 11000.0 m to 15000.0. <br/> rdheight has to be defined in Namelist group <span class="caps"> DYNCTL </span> . <br/> The value of 11000.0 is the default, so it might be possible that it is not set in your run-script. You have to do this if you change the default value. </p> <p> According to the height of your model domain (22700 m), a value of 15000.0 for rdheight is the maximum that makes sense. <br/> Perhaps you remember our discussion in Zurich last year where I explained why we had to increase the rdheight value over the <span class="caps"> CORDEX </span> Africa domain, which <br/> includes tropics and sub-tropics. <br/> Without this increase the precipitation was very much too low. </p> <p> For your case, I expect a larger impact from the increase of rdheight than from the decrease of rat_sea. <br/> Attached you find a <span class="caps"> YUSPECIF </span> file from our <span class="caps"> CORDEX </span> Africa evaluation runs. There you can find further differences between your <span class="caps"> CCLM </span> setup and the <span class="caps"> CORDEX </span> setup. <br/> If you like, study the impact of further adaptations to the <span class="caps"> CORDEX </span> Africa setup. </p> <p> Coming back to the height of your model domain. Looking at the geography of your model domain I doubt a little bit that the choice of <br/> 22700m for the top of the domain is appropriate. <br/> For <span class="caps"> CORDEX </span> Africa we chose 30000. <br/> But if you want to change the vertical grid, you have to re-run INT2LM, since the verical grid is defined in INT2LM, not in <span class="caps"> CCLM </span> . <br/> Without changing your number of vertical levels (40) and the thickness of the lowest layer (20m), the following vertical grid could be reasonable (has to be defined in <br/> INT2LM, Namelist Group LM_GRID) </p> <p> vcoord_d= 30000.00, 27800.00, 25710.00, 23730.00, 21860.00, 20080.00, 18410.00, 16830.00, 15350.00, 13960.00, 12660.00, 11440.00, 10300.00, 9250.00, 8265.00, 7360.00, 6520.00, 5750.00, 5045.00, 4400.00, 3820.00, 3290.00, 2815.00, 2390.00, 2015.00, 1680.00, 1388.00, 1134.00, 915.00, 729.00, 573.00, 443.00, 338.00, 253.00, 186.00, 134.00, 95.00, 64.00, 41.00, 20.00, 0.00 </p> <p> Hans-Juergen </p>

  @redc_migration in #3ec3cd5

<p> Hi Hans-Juergen, </p> <p> I want to follow your recommendation and re-run my expertiment with different values for height of the model domain, <br/> number of vertical levels, and the thickness of the lowest level. Which namelist parameters are to be changed to do it? </p> <p> By the way, is there a way for running the model without defining vcoord_d values explicitly. <br/> What should I do to run the model with ke_tot = 56 and the highest level is located higher than the data from driving model? </p> <p> And also please let me know if there is a way for changing the </p> <p> entrpen <br/> entrmid <br/> and other parameters in Tiedtke convection scheme without recompiling the code. </p> <p> How sensitive the model results (precipitation) may be to such changes? </p> <p> Thanks, Simon </p>

  @redc_migration in #bcea2bf

<p> Dear colleagues, <br/> I have tried to find answers to some of my questions from my previous message but apparently failed. PLease have a look at logout file, scripts and <span class="caps"> YUSPECIF </span> . <br/> Best wishes, <br/> Simon </p>

  @hans-jürgenpanitz in #74fe1fd

<p> Dear Simon, </p> <p> a few answers to you last but one question: <br/> all changes related to number of vertical levels (ke_tot), height of the model domain,and <br/> thickness of lowest layer (both via vcoord_d, for example) have to be defined in the Namelist of INT2LM and require a <br/> re-run of INT2LM. </p> <p> vcoord_d: yes, in INT2LM there are some default combinations of ke_tot and vcoord_d, which I do not know by heart <br/> and which are too much to be listed here. You have to look into the code (src_namelist.f90) </p> <p> If you want to change hard-coded values of variables in the Tietke scheme you have to do it by hand in the code. <br/> Of course, afterwards, the module has to be compiled again. </p> <p> Impact of changes related to the variables “entrpen” “entrmid” and others: no experience </p> <p> Answer to your last question: <br/> Your <span class="caps"> CCLM </span> job failed due to an error in Namelist “ <span class="caps"> PHYCTL </span> ”. <br/> You defined the parameters lprog_prec = <span class="caps"> TRUE </span> , (which, by the way, must be lprogprec, without underscore) ltrans_prec = <span class="caps"> TRUE </span> </p> <p> Both parameters have been deleted as Namelist parameters since <span class="caps"> COSMO </span> Version 4.23, but you are using Version 5.0, aren’t you? </p> <p> Such errors are indicated in the standard output, in your case in “cclme6001.job”. <br/> Unfortunately, you only get the info that something is wrong, but not what is wrong <br/> This requires to have a look into the code and to compare the existing Namelist parameters of the corresponding Namelist whith the <br/> definitions in your script. </p> <p> Or, what is always as must, lokk into the “misc.global” file of the version you are using and look for changes in the corresponding Namelist. </p> <p> Best regards </p> <p> Hans-Juergen </p>

  @redc_migration in #186184b

<p> Dear coleagues, dear Hans-Juergen, </p> <p> I tried to follow your recommendation to increase the top level of the atmosphere in my experient with <span class="caps"> COSMO </span> 5.0 (starter package 1.4) with 40 model levels defined (I think) in accordance with the earlier sent by Hand-Juergen list of values for vccord_d. <br/> This has not worked and lead to a NaN value for pressure at the highest model level. <br/> My attempt to delete the highest level (i.e to run the model with 39 level instead of 40) has also failed – the code complains about attempting to interpolate above the model top. <br/> Indeed, I have not found any parameter explicitly defining the pressure at model top. This is probably the cause of my mistake. <br/> Please tell me may be done to solve my problem. <br/> Please see some files with results of the runs attached. <br/> Kind regards <br/> Simon </p>

  @hans-jürgenpanitz in #ed2163b

<p> Dear Simon, </p> <p> if you have a look into the <span class="caps"> YUCHKDAT </span> file of your INT2LM run you will see <br/> that the field “PP” (pressure perturbation) is undefined in the uppermost layer (search for “laf” and/or “lbfd” strings; <br/> there you find the PP values). That is deadly! <br/> The reason certainly is that you used the old reference atmosphere (irefatm=1), which makes no sense for <br/> a model domain height of 30 km, since, for the old reference atmosphere, the reference temperature T0 is decreasing steadily, <br/> and it might become negative (below absolute Zero) if the top of the model domain is too high. <br/> Thus, you have to use the new reference atmosphere, which you get if you set irefatm=2 in Namelist “lmgrid”. <br/> The new ref. atmosphere is much closer to the standard atmosphere. <br/> And there are, in principle, no restrictions with respect to the top height of the model domain. <br/> The only restriction is the top height of the driving large-scale model. </p> <p> Best regards </p> <p> Hans-Juergen </p>