extreme value of precipitation over tropic – in #8: General Questions
in #8: General Questions
Cookies disclaimer
Our site saves small pieces of text information (cookies) on your
device in order to verify your login. These cookies are essential
to provide access to resources on this website and it will not
work properly without.
Learn more
<p>
Dear all,
</p>
<p>
I am working on
<span class="caps">
CCLM
</span>
dynamic downscaling in
<span class="caps">
CORDEX
</span>
-EA. The driving data is
<span class="caps">
ERA
</span>
-Interim, and simulating period from 1979 to 2010. I found some grids have extreme precipitation (like 400 mm/3hr), especially in tropics. Is there anyone can help me?
</p>
<p>
Dear all,
</p>
<p>
I am working on
<span class="caps">
CCLM
</span>
dynamic downscaling in
<span class="caps">
CORDEX
</span>
-EA. The driving data is
<span class="caps">
ERA
</span>
-Interim, and simulating period from 1979 to 2010. I found some grids have extreme precipitation (like 400 mm/3hr), especially in tropics. Is there anyone can help me?
</p>
I am working on
CCLM
dynamic downscaling in
CORDEX
-EA. The driving data is
ERA
-Interim, and simulating period from 1979 to 2010. I found some grids have extreme precipitation (like 400 mm/3hr), especially in tropics. Is there anyone can help me?
<p>
Which
<span class="caps">
CCLM
</span>
version do you use? Also, please upload your
<span class="caps">
YUSPECIF
</span>
file. Other members running simulations in the tropics may want to compare their
<span class="caps">
YUSPECIF
</span>
with yours to find differences.
<br/>
I have also found such overshootings in single grid points when I used the default Tiedtke convection
<code>
itype_conv=0
</code>
, but have no explanation. With the
<span class="caps">
IFS
</span>
convection
<code>
itype_conv=4
</code>
it seems to be smoother.
</p>
<p>
Which
<span class="caps">
CCLM
</span>
version do you use? Also, please upload your
<span class="caps">
YUSPECIF
</span>
file. Other members running simulations in the tropics may want to compare their
<span class="caps">
YUSPECIF
</span>
with yours to find differences.
<br/>
I have also found such overshootings in single grid points when I used the default Tiedtke convection
<code>
itype_conv=0
</code>
, but have no explanation. With the
<span class="caps">
IFS
</span>
convection
<code>
itype_conv=4
</code>
it seems to be smoother.
</p>
Which
CCLM
version do you use? Also, please upload your
YUSPECIF
file. Other members running simulations in the tropics may want to compare their
YUSPECIF
with yours to find differences.
I have also found such overshootings in single grid points when I used the default Tiedtke convection
itype_conv=0
, but have no explanation. With the
IFS
convection
itype_conv=4
it seems to be smoother.
<p>
the
<span class="caps">
CCLM
</span>
version is cosmo_090213_4.8_clm19. So, I will make a sensitivity experiment for choosing
<span class="caps">
IFS
</span>
convection itype_conv=4. Let’s see how it will come.
</p>
<p>
thank you very much.
</p>
<p>
the
<span class="caps">
CCLM
</span>
version is cosmo_090213_4.8_clm19. So, I will make a sensitivity experiment for choosing
<span class="caps">
IFS
</span>
convection itype_conv=4. Let’s see how it will come.
</p>
<p>
thank you very much.
</p>
the
CCLM
version is cosmo_090213_4.8_clm19. So, I will make a sensitivity experiment for choosing
IFS
convection itype_conv=4. Let’s see how it will come.
<p>
yes, I know. There are only four options: 0,1,2,3. But no itype_conv=4.
</p>
<p>
To specify the type of convection parameterization
<br/>
0: Tiedtke scheme
<br/>
1: redThis option has been eliminated
<br/>
2: redThis option has been eliminated
<br/>
3: Shallow convection based on Tiedtke scheme
</p>
<p>
yes, I know. There are only four options: 0,1,2,3. But no itype_conv=4.
</p>
<p>
To specify the type of convection parameterization
<br/>
0: Tiedtke scheme
<br/>
1: redThis option has been eliminated
<br/>
2: redThis option has been eliminated
<br/>
3: Shallow convection based on Tiedtke scheme
</p>
yes, I know. There are only four options: 0,1,2,3. But no itype_conv=4.
To specify the type of convection parameterization
0: Tiedtke scheme
1: redThis option has been eliminated
2: redThis option has been eliminated
3: Shallow convection based on Tiedtke scheme
<p>
Hello Bo,
<br/>
most probably the high values of precipitation at individual grid points originate in the numerics of advection which cannot deal with convection at individual grid points.
<br/>
Instead of cooling feedback at the surface it is enhancing the convection.
</p>
<p>
In cosmo_4.8_clm19 there is still this problem.
<br/>
This has been fixed in a more recent version by Uli Blahak and will be available with 5.0.
<br/>
I would appreciate if you could implement this modification of advection in 4.8_clm19 and test it.
<br/>
Please contact me in the case, you would like to do that.
</p>
<p>
Greetings, Andreas
</p>
<p>
Hello Bo,
<br/>
most probably the high values of precipitation at individual grid points originate in the numerics of advection which cannot deal with convection at individual grid points.
<br/>
Instead of cooling feedback at the surface it is enhancing the convection.
</p>
<p>
In cosmo_4.8_clm19 there is still this problem.
<br/>
This has been fixed in a more recent version by Uli Blahak and will be available with 5.0.
<br/>
I would appreciate if you could implement this modification of advection in 4.8_clm19 and test it.
<br/>
Please contact me in the case, you would like to do that.
</p>
<p>
Greetings, Andreas
</p>
Hello Bo,
most probably the high values of precipitation at individual grid points originate in the numerics of advection which cannot deal with convection at individual grid points.
Instead of cooling feedback at the surface it is enhancing the convection.
In cosmo_4.8_clm19 there is still this problem.
This has been fixed in a more recent version by Uli Blahak and will be available with 5.0.
I would appreciate if you could implement this modification of advection in 4.8_clm19 and test it.
Please contact me in the case, you would like to do that.
<p>
Hi Andreas,
</p>
<p>
thank you for your information. I would like to do some effort for clm-community. However, I do not have any experience of work like that. Please tell me how to implement that modification of advection in 4.8_clm19, then I can do some tests.
</p>
<p>
Regards,
<br/>
Bo
</p>
<p>
Hi Andreas,
</p>
<p>
thank you for your information. I would like to do some effort for clm-community. However, I do not have any experience of work like that. Please tell me how to implement that modification of advection in 4.8_clm19, then I can do some tests.
</p>
<p>
Regards,
<br/>
Bo
</p>
thank you for your information. I would like to do some effort for clm-community. However, I do not have any experience of work like that. Please tell me how to implement that modification of advection in 4.8_clm19, then I can do some tests.
<p>
Hi Bo,
</p>
<p>
Hi Bo,
</p>
<p>
I saw in your
<span class="caps">
YUSPECIF
</span>
file that you use a value of 11000m for the parameter rdheight, which defines
<br/>
the lower boundary the Rayleigh damping layer in y=
</p>
<p>
In the tropics I strongly recommend a value of about 18000 m. The
<span class="caps">
CCLM
</span>
default
<br/>
value is 11000 m, which is too low.
</p>
<p>
But: when increasing rdheight you also have to increase the height of the model domain to
<br/>
about 30000m, which requires re-running of INT2LM.
</p>
<p>
However, I recommend to do this and to see what happens to your precipitation.
</p>
<p>
A possbible model setup that has been used for the
<span class="caps">
CORDEX
</span>
Africa simulations is available from the
<br/>
CLM Communities homepage
<br/>
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/texts/cosmo_clm_4/CCLM-AFR440_4.8_clm17.txt
</p>
<p>
Since I assume that you do not use the
<span class="caps">
MODIS
</span>
derived albedo, please change the parameter itype_albedo from 2 to 1.
</p>
<p>
Best
</p>
<p>
Hans-Juergen
</p>
<p>
Hi Bo,
</p>
<p>
Hi Bo,
</p>
<p>
I saw in your
<span class="caps">
YUSPECIF
</span>
file that you use a value of 11000m for the parameter rdheight, which defines
<br/>
the lower boundary the Rayleigh damping layer in y=
</p>
<p>
In the tropics I strongly recommend a value of about 18000 m. The
<span class="caps">
CCLM
</span>
default
<br/>
value is 11000 m, which is too low.
</p>
<p>
But: when increasing rdheight you also have to increase the height of the model domain to
<br/>
about 30000m, which requires re-running of INT2LM.
</p>
<p>
However, I recommend to do this and to see what happens to your precipitation.
</p>
<p>
A possbible model setup that has been used for the
<span class="caps">
CORDEX
</span>
Africa simulations is available from the
<br/>
CLM Communities homepage
<br/>
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/texts/cosmo_clm_4/CCLM-AFR440_4.8_clm17.txt
</p>
<p>
Since I assume that you do not use the
<span class="caps">
MODIS
</span>
derived albedo, please change the parameter itype_albedo from 2 to 1.
</p>
<p>
Best
</p>
<p>
Hans-Juergen
</p>
I saw in your
YUSPECIF
file that you use a value of 11000m for the parameter rdheight, which defines
the lower boundary the Rayleigh damping layer in y=
In the tropics I strongly recommend a value of about 18000 m. The
CCLM
default
value is 11000 m, which is too low.
But: when increasing rdheight you also have to increase the height of the model domain to
about 30000m, which requires re-running of INT2LM.
However, I recommend to do this and to see what happens to your precipitation.
A possbible model setup that has been used for the
CORDEX
Africa simulations is available from the
CLM Communities homepage
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/texts/cosmo_clm_4/CCLM-AFR440_4.8_clm17.txt
Since I assume that you do not use the
MODIS
derived albedo, please change the parameter itype_albedo from 2 to 1.
<p>
Hi Hans-Juergen,
</p>
<p>
thank you very much. I want to do some test as your suggestion. But how to change the height of the model domain? I didn’t find a parameter to control that.
</p>
<p>
Best regards,
</p>
<p>
Bo
</p>
<p>
Hi Hans-Juergen,
</p>
<p>
thank you very much. I want to do some test as your suggestion. But how to change the height of the model domain? I didn’t find a parameter to control that.
</p>
<p>
Best regards,
</p>
<p>
Bo
</p>
thank you very much. I want to do some test as your suggestion. But how to change the height of the model domain? I didn’t find a parameter to control that.
<p>
Hi Bo,
<br/>
please read my recent comment properly.
</p>
<p>
In order to modify the height of the model domain, you have to re-run INT2LM.
<br/>
The vertical structure of your model domain is defined there and transferred via the laf/lbfd files to
<span class="caps">
CCLM
</span>
.
</p>
<p>
Hans-Juergen
</p>
<p>
Hi Bo,
<br/>
please read my recent comment properly.
</p>
<p>
In order to modify the height of the model domain, you have to re-run INT2LM.
<br/>
The vertical structure of your model domain is defined there and transferred via the laf/lbfd files to
<span class="caps">
CCLM
</span>
.
</p>
<p>
Hans-Juergen
</p>
In order to modify the height of the model domain, you have to re-run INT2LM.
The vertical structure of your model domain is defined there and transferred via the laf/lbfd files to
CCLM
.
<p>
Hi Hans-Juergen,
</p>
<p>
but if I don’t change any parameter in run_int2lm, the output of int2lm should be the same. I found only kelm_tot to control the output of int2lm on vertical height. Now, the kelm_tot=40, and the height_toa=22700m. Shall I increase the kelm_tot?
</p>
<p>
Best,
</p>
<p>
Bo
</p>
<p>
Hi Hans-Juergen,
</p>
<p>
but if I don’t change any parameter in run_int2lm, the output of int2lm should be the same. I found only kelm_tot to control the output of int2lm on vertical height. Now, the kelm_tot=40, and the height_toa=22700m. Shall I increase the kelm_tot?
</p>
<p>
Best,
</p>
<p>
Bo
</p>
but if I don’t change any parameter in run_int2lm, the output of int2lm should be the same. I found only kelm_tot to control the output of int2lm on vertical height. Now, the kelm_tot=40, and the height_toa=22700m. Shall I increase the kelm_tot?
<p>
Unfortunately, the corresponding INT2LM namelist to the link Hans-Jürgen provided above is not given in the namelist tool (at least I cannot find it). In the following is the list of the namelist block you need to adapt in the INT2LM. Replace the
<code>
</code>
{xxxx}@ by the values you use. ke_tot=35
<br/>
<pre>
&LMGRID
ivctype = 2,
irefatm = 2,
ielm_tot=@{IE_TOT}, jelm_tot=@{JE_TOT}, kelm_tot=@{KE_TOT},
pollat = <code>{POLLAT}, pollon = </code>{POLLON}, polgam = <code>{POLGAM},
dlon=</code>{DLON}, dlat=@{DLAT},
startlat_tot = <code>{STARTLAT_TOT}, startlon_tot = </code>{STARTLON_TOT},
ke_soil_lm=@{KE_SOIL},
czml_soil_lm = @{CZML_SOIL},
vcflat=11000.0,
vcoord_d=30000., 27800., 25710., 23730., 21860., 20090., 18420., 16840., 15360., 13970.,
12670., 11450., 10320., 9260., 8280., 7370., 6540., 5770., 5060., 4420.,
3830., 3300., 2820., 2390., 2010., 1670., 1370., 1110., 880., 690.,
520., 370., 250., 150., 70., 0.,
/END
</pre>
</p>
<p>
Unfortunately, the corresponding INT2LM namelist to the link Hans-Jürgen provided above is not given in the namelist tool (at least I cannot find it). In the following is the list of the namelist block you need to adapt in the INT2LM. Replace the
<code>
</code>
{xxxx}@ by the values you use. ke_tot=35
<br/>
<pre>
&LMGRID
ivctype = 2,
irefatm = 2,
ielm_tot=@{IE_TOT}, jelm_tot=@{JE_TOT}, kelm_tot=@{KE_TOT},
pollat = <code>{POLLAT}, pollon = </code>{POLLON}, polgam = <code>{POLGAM},
dlon=</code>{DLON}, dlat=@{DLAT},
startlat_tot = <code>{STARTLAT_TOT}, startlon_tot = </code>{STARTLON_TOT},
ke_soil_lm=@{KE_SOIL},
czml_soil_lm = @{CZML_SOIL},
vcflat=11000.0,
vcoord_d=30000., 27800., 25710., 23730., 21860., 20090., 18420., 16840., 15360., 13970.,
12670., 11450., 10320., 9260., 8280., 7370., 6540., 5770., 5060., 4420.,
3830., 3300., 2820., 2390., 2010., 1670., 1370., 1110., 880., 690.,
520., 370., 250., 150., 70., 0.,
/END
</pre>
</p>
Unfortunately, the corresponding INT2LM namelist to the link Hans-Jürgen provided above is not given in the namelist tool (at least I cannot find it). In the following is the list of the namelist block you need to adapt in the INT2LM. Replace the
{xxxx}@ by the values you use. ke_tot=35
<p>
Hi Burkhardt,
</p>
<p>
it wasn’t a link to INT2LM Namelist but to
<span class="caps">
CCLM
</span>
Namelist, which exists.
<br/>
Of course, one has to be logged into the
<span class="caps">
CLM
</span>
Homepage as a member.
</p>
<p>
@Bo:
<br/>
You have to change the model levels in the way Burkhardt indicates in his comment.
<br/>
Using the Namelist parameter vcoord_d (I am talking about INT2LM namelist) you can define your own levels.
<br/>
They must be provided in descending order.
</p>
<p>
The example Burkhardt gave is again from the
<span class="caps">
CORDEX
</span>
Africa simulations with kelm_tot=35 (ke_tot=35 in
<span class="caps">
CCLM
</span>
Namelist).
</p>
<p>
In vcoord_d you have to define kelm_tot+1 values!!!!!!!!!!!!!!!!!!!
</p>
<p>
By the way, Bo.
<br/>
The whole system INT2LM/COSMO-
<span class="caps">
CLM
</span>
is not self-explaining.
<br/>
What users has really to do is to read the model documentations, at least the User’s Guide of
<span class="caps">
CCLM
</span>
which is Part
<span class="caps">
VII
</span>
of the general
<br/>
documentation, and the documentation of INT2LM which is Part V.
<br/>
All the questions you pose are answered in these documentations.
<br/>
And these documentions are available from the
<span class="caps">
COSOM
</span>
web-page
<br/>
www.cosmo-model.org
<br/>
Links to this page exist also on the
<span class="caps">
CLM
</span>
-Homepage.
</p>
<p>
Sorry for being a little bit harsh.
<br/>
But this is also some kind of user training.
</p>
<p>
Best
</p>
<p>
Hans-Juergen
</p>
<p>
Hi Burkhardt,
</p>
<p>
it wasn’t a link to INT2LM Namelist but to
<span class="caps">
CCLM
</span>
Namelist, which exists.
<br/>
Of course, one has to be logged into the
<span class="caps">
CLM
</span>
Homepage as a member.
</p>
<p>
@Bo:
<br/>
You have to change the model levels in the way Burkhardt indicates in his comment.
<br/>
Using the Namelist parameter vcoord_d (I am talking about INT2LM namelist) you can define your own levels.
<br/>
They must be provided in descending order.
</p>
<p>
The example Burkhardt gave is again from the
<span class="caps">
CORDEX
</span>
Africa simulations with kelm_tot=35 (ke_tot=35 in
<span class="caps">
CCLM
</span>
Namelist).
</p>
<p>
In vcoord_d you have to define kelm_tot+1 values!!!!!!!!!!!!!!!!!!!
</p>
<p>
By the way, Bo.
<br/>
The whole system INT2LM/COSMO-
<span class="caps">
CLM
</span>
is not self-explaining.
<br/>
What users has really to do is to read the model documentations, at least the User’s Guide of
<span class="caps">
CCLM
</span>
which is Part
<span class="caps">
VII
</span>
of the general
<br/>
documentation, and the documentation of INT2LM which is Part V.
<br/>
All the questions you pose are answered in these documentations.
<br/>
And these documentions are available from the
<span class="caps">
COSOM
</span>
web-page
<br/>
www.cosmo-model.org
<br/>
Links to this page exist also on the
<span class="caps">
CLM
</span>
-Homepage.
</p>
<p>
Sorry for being a little bit harsh.
<br/>
But this is also some kind of user training.
</p>
<p>
Best
</p>
<p>
Hans-Juergen
</p>
it wasn’t a link to INT2LM Namelist but to
CCLM
Namelist, which exists.
Of course, one has to be logged into the
CLM
Homepage as a member.
@Bo:
You have to change the model levels in the way Burkhardt indicates in his comment.
Using the Namelist parameter vcoord_d (I am talking about INT2LM namelist) you can define your own levels.
They must be provided in descending order.
The example Burkhardt gave is again from the
CORDEX
Africa simulations with kelm_tot=35 (ke_tot=35 in
CCLM
Namelist).
In vcoord_d you have to define kelm_tot+1 values!!!!!!!!!!!!!!!!!!!
By the way, Bo.
The whole system INT2LM/COSMO-
CLM
is not self-explaining.
What users has really to do is to read the model documentations, at least the User’s Guide of
CCLM
which is Part
VII
of the general
documentation, and the documentation of INT2LM which is Part V.
All the questions you pose are answered in these documentations.
And these documentions are available from the
COSOM
web-page
www.cosmo-model.org
Links to this page exist also on the
CLM
-Homepage.
Sorry for being a little bit harsh.
But this is also some kind of user training.
<p>
Dear Colleagues,
</p>
<p>
I agree with the suggestion of Hans-Juergen.
</p>
<p>
Please replace the link to the old namelist-tool whereever it still exists by the following link to the
<br/>
updated namelist-tool:
<br/>
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/index.htm
<br/>
Here you find int2lm as well.
</p>
<p>
Greetings, Andreas
</p>
<p>
Dear Colleagues,
</p>
<p>
I agree with the suggestion of Hans-Juergen.
</p>
<p>
Please replace the link to the old namelist-tool whereever it still exists by the following link to the
<br/>
updated namelist-tool:
<br/>
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/index.htm
<br/>
Here you find int2lm as well.
</p>
<p>
Greetings, Andreas
</p>
Please replace the link to the old namelist-tool whereever it still exists by the following link to the
updated namelist-tool:
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/index.htm
Here you find int2lm as well.
<p>
Dear Colleagues,
</p>
<p>
what happens if the atmophere in
<span class="caps">
CCLM
</span>
is “lifted” up to 30000 km (as Burkhardt suggested) but the Rayleigh damping height remains low (11000 m)?
<br/>
I assume the damping layer is thicker than with rdheight=18000 and, therefore, the damping is smoother. Has anybody tested such setup for the tropics? Did it work well or not?
</p>
<p>
Kristina
</p>
<p>
Dear Colleagues,
</p>
<p>
what happens if the atmophere in
<span class="caps">
CCLM
</span>
is “lifted” up to 30000 km (as Burkhardt suggested) but the Rayleigh damping height remains low (11000 m)?
<br/>
I assume the damping layer is thicker than with rdheight=18000 and, therefore, the damping is smoother. Has anybody tested such setup for the tropics? Did it work well or not?
</p>
<p>
Kristina
</p>
what happens if the atmophere in
CCLM
is “lifted” up to 30000 km (as Burkhardt suggested) but the Rayleigh damping height remains low (11000 m)?
I assume the damping layer is thicker than with rdheight=18000 and, therefore, the damping is smoother. Has anybody tested such setup for the tropics? Did it work well or not?
<p>
Hi Kristina,
</p>
<p>
relative easy answer:
<br/>
I did such excercise when “searching” an appropriate setup for the
<span class="caps">
CORDEX
</span>
Africa simulation.
</p>
<p>
“Did it work well?“
<br/>
Clear answer, NO!
</p>
<p>
The important and physically reasonable change is the increase of rdheight, which then implies the
<br/>
increase of the height of the model domain.
<br/>
Rule of thumb: the thickness of the damping layer should be approx. 1/3 of the whole vertical extent of the model domain.
</p>
<p>
Hans-Jürgen
</p>
<p>
Hi Kristina,
</p>
<p>
relative easy answer:
<br/>
I did such excercise when “searching” an appropriate setup for the
<span class="caps">
CORDEX
</span>
Africa simulation.
</p>
<p>
“Did it work well?“
<br/>
Clear answer, NO!
</p>
<p>
The important and physically reasonable change is the increase of rdheight, which then implies the
<br/>
increase of the height of the model domain.
<br/>
Rule of thumb: the thickness of the damping layer should be approx. 1/3 of the whole vertical extent of the model domain.
</p>
<p>
Hans-Jürgen
</p>
relative easy answer:
I did such excercise when “searching” an appropriate setup for the
CORDEX
Africa simulation.
“Did it work well?“
Clear answer, NO!
The important and physically reasonable change is the increase of rdheight, which then implies the
increase of the height of the model domain.
Rule of thumb: the thickness of the damping layer should be approx. 1/3 of the whole vertical extent of the model domain.
<p>
Important is to damp the gravity waves sufficiently.
<br/>
Hereto a test series should be considered with the alternative wave damping where w is damped only.
</p>
<p>
Using the standard approach the coefficient nrdtau can be chosen smaller to make the damping stronger.
<br/>
In this case the damping zone can be made thinner. However, too strong damping reflects the waves within the damping layer.
<br/>
A typical optimisation problem.
<br/>
In any case, the damping should be rather too strong than too weak.
<br/>
Higher mountains need stronger damping because the vertical propagation speed is increasing with the slope of the mountains.
</p>
<p>
I plan an article for the
<span class="caps">
COSMO
</span>
newsletter on this topic and a revision of the namelist parameter description.
</p>
<p>
Greetings, Andreas
</p>
<p>
Important is to damp the gravity waves sufficiently.
<br/>
Hereto a test series should be considered with the alternative wave damping where w is damped only.
</p>
<p>
Using the standard approach the coefficient nrdtau can be chosen smaller to make the damping stronger.
<br/>
In this case the damping zone can be made thinner. However, too strong damping reflects the waves within the damping layer.
<br/>
A typical optimisation problem.
<br/>
In any case, the damping should be rather too strong than too weak.
<br/>
Higher mountains need stronger damping because the vertical propagation speed is increasing with the slope of the mountains.
</p>
<p>
I plan an article for the
<span class="caps">
COSMO
</span>
newsletter on this topic and a revision of the namelist parameter description.
</p>
<p>
Greetings, Andreas
</p>
Important is to damp the gravity waves sufficiently.
Hereto a test series should be considered with the alternative wave damping where w is damped only.
Using the standard approach the coefficient nrdtau can be chosen smaller to make the damping stronger.
In this case the damping zone can be made thinner. However, too strong damping reflects the waves within the damping layer.
A typical optimisation problem.
In any case, the damping should be rather too strong than too weak.
Higher mountains need stronger damping because the vertical propagation speed is increasing with the slope of the mountains.
I plan an article for the
COSMO
newsletter on this topic and a revision of the namelist parameter description.
extreme value of precipitation over tropic
Dear all,
I am working on CCLM dynamic downscaling in CORDEX -EA. The driving data is ERA -Interim, and simulating period from 1979 to 2010. I found some grids have extreme precipitation (like 400 mm/3hr), especially in tropics. Is there anyone can help me?
Which CCLM version do you use? Also, please upload your YUSPECIF file. Other members running simulations in the tropics may want to compare their YUSPECIF with yours to find differences.
I have also found such overshootings in single grid points when I used the default Tiedtke convection
itype_conv=0, but have no explanation. With the IFS convectionitype_conv=4it seems to be smoother.the CCLM version is cosmo_090213_4.8_clm19. So, I will make a sensitivity experiment for choosing IFS convection itype_conv=4. Let’s see how it will come.
thank you very much.
Hallo Burkhardt,
I found that there is no option of itype_conv=4. So, what should I do?
itype_convis in the name list block&PHYCTLyes, I know. There are only four options: 0,1,2,3. But no itype_conv=4.
To specify the type of convection parameterization
0: Tiedtke scheme
1: redThis option has been eliminated
2: redThis option has been eliminated
3: Shallow convection based on Tiedtke scheme
The namelist tool is probably not up-to-date. There should be a line
4: IFS convection scheme
Hello Bo,
most probably the high values of precipitation at individual grid points originate in the numerics of advection which cannot deal with convection at individual grid points.
Instead of cooling feedback at the surface it is enhancing the convection.
In cosmo_4.8_clm19 there is still this problem.
This has been fixed in a more recent version by Uli Blahak and will be available with 5.0.
I would appreciate if you could implement this modification of advection in 4.8_clm19 and test it.
Please contact me in the case, you would like to do that.
Greetings, Andreas
Hi Andreas,
thank you for your information. I would like to do some effort for clm-community. However, I do not have any experience of work like that. Please tell me how to implement that modification of advection in 4.8_clm19, then I can do some tests.
Regards,
Bo
Hi Bo,
Hi Bo,
I saw in your YUSPECIF file that you use a value of 11000m for the parameter rdheight, which defines
the lower boundary the Rayleigh damping layer in y=
In the tropics I strongly recommend a value of about 18000 m. The CCLM default
value is 11000 m, which is too low.
But: when increasing rdheight you also have to increase the height of the model domain to
about 30000m, which requires re-running of INT2LM.
However, I recommend to do this and to see what happens to your precipitation.
A possbible model setup that has been used for the CORDEX Africa simulations is available from the
CLM Communities homepage
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/texts/cosmo_clm_4/CCLM-AFR440_4.8_clm17.txt
Since I assume that you do not use the MODIS derived albedo, please change the parameter itype_albedo from 2 to 1.
Best
Hans-Juergen
Hi Hans-Juergen,
thank you very much. I want to do some test as your suggestion. But how to change the height of the model domain? I didn’t find a parameter to control that.
Best regards,
Bo
Hi Bo,
please read my recent comment properly.
In order to modify the height of the model domain, you have to re-run INT2LM.
The vertical structure of your model domain is defined there and transferred via the laf/lbfd files to CCLM .
Hans-Juergen
Hi Hans-Juergen,
but if I don’t change any parameter in run_int2lm, the output of int2lm should be the same. I found only kelm_tot to control the output of int2lm on vertical height. Now, the kelm_tot=40, and the height_toa=22700m. Shall I increase the kelm_tot?
Best,
Bo
Unfortunately, the corresponding INT2LM namelist to the link Hans-Jürgen provided above is not given in the namelist tool (at least I cannot find it). In the following is the list of the namelist block you need to adapt in the INT2LM. Replace the
{xxxx}@ by the values you use. ke_tot=35&LMGRID ivctype = 2, irefatm = 2, ielm_tot=@{IE_TOT}, jelm_tot=@{JE_TOT}, kelm_tot=@{KE_TOT}, pollat ={POLLAT}, pollon ={POLLON}, polgam ={POLGAM}, dlon={DLON}, dlat=@{DLAT}, startlat_tot ={STARTLAT_TOT}, startlon_tot ={STARTLON_TOT}, ke_soil_lm=@{KE_SOIL}, czml_soil_lm = @{CZML_SOIL}, vcflat=11000.0, vcoord_d=30000., 27800., 25710., 23730., 21860., 20090., 18420., 16840., 15360., 13970., 12670., 11450., 10320., 9260., 8280., 7370., 6540., 5770., 5060., 4420., 3830., 3300., 2820., 2390., 2010., 1670., 1370., 1110., 880., 690., 520., 370., 250., 150., 70., 0., /ENDHi Burkhardt,
it wasn’t a link to INT2LM Namelist but to CCLM Namelist, which exists.
Of course, one has to be logged into the CLM Homepage as a member.
@Bo:
You have to change the model levels in the way Burkhardt indicates in his comment.
Using the Namelist parameter vcoord_d (I am talking about INT2LM namelist) you can define your own levels.
They must be provided in descending order.
The example Burkhardt gave is again from the CORDEX Africa simulations with kelm_tot=35 (ke_tot=35 in CCLM Namelist).
In vcoord_d you have to define kelm_tot+1 values!!!!!!!!!!!!!!!!!!!
By the way, Bo.
The whole system INT2LM/COSMO- CLM is not self-explaining.
What users has really to do is to read the model documentations, at least the User’s Guide of CCLM which is Part VII of the general
documentation, and the documentation of INT2LM which is Part V.
All the questions you pose are answered in these documentations.
And these documentions are available from the COSOM web-page
www.cosmo-model.org
Links to this page exist also on the CLM -Homepage.
Sorry for being a little bit harsh.
But this is also some kind of user training.
Best
Hans-Juergen
Dear Colleagues,
I agree with the suggestion of Hans-Juergen.
Please replace the link to the old namelist-tool whereever it still exists by the following link to the
updated namelist-tool:
http://www.clm-community.eu/namelist-tool/namelist-tool_portal/index.htm
Here you find int2lm as well.
Greetings, Andreas
Dear Colleagues,
what happens if the atmophere in CCLM is “lifted” up to 30000 km (as Burkhardt suggested) but the Rayleigh damping height remains low (11000 m)?
I assume the damping layer is thicker than with rdheight=18000 and, therefore, the damping is smoother. Has anybody tested such setup for the tropics? Did it work well or not?
Kristina
Hi Kristina,
relative easy answer:
I did such excercise when “searching” an appropriate setup for the CORDEX Africa simulation.
“Did it work well?“
Clear answer, NO!
The important and physically reasonable change is the increase of rdheight, which then implies the
increase of the height of the model domain.
Rule of thumb: the thickness of the damping layer should be approx. 1/3 of the whole vertical extent of the model domain.
Hans-Jürgen
Important is to damp the gravity waves sufficiently.
Hereto a test series should be considered with the alternative wave damping where w is damped only.
Using the standard approach the coefficient nrdtau can be chosen smaller to make the damping stronger.
In this case the damping zone can be made thinner. However, too strong damping reflects the waves within the damping layer.
A typical optimisation problem.
In any case, the damping should be rather too strong than too weak.
Higher mountains need stronger damping because the vertical propagation speed is increasing with the slope of the mountains.
I plan an article for the COSMO newsletter on this topic and a revision of the namelist parameter description.
Greetings, Andreas