An issue in using 30000 m model top over Asian domain – in #10: INT2LM
in #10: INT2LM
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 encountered a problem with using 30000 m model top over Asian domain. The interpolated temperature (T) at the top model level of
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
has some abnormal values (even minus Kelvin) over the northern part of our model, associated with other parameters (such as PP, U and V) wrong as well. It seems that these abnormal T values are related to the very low temperature in the uppermost model level, and the problem is only seen in the winter season, but not in summer. Also, if I use the default model top (i.e. about 23000 m), there is no such problem. I am wondering whether there might be some bugs in vertical interpolation of T for the case when the model top of
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
is higher than that of the driving model? We use output from ECHAM5 T31, 19 level.
</p>
<p>
Attached is our
<span class="caps">
OUTPUT
</span>
file of INT2LM (int2lm_091216_1.10_clm9) and an example of our driving data (cfsd******.nc) and output data from INT2LM (lbfd******.nc). Any suggestions on possible solutions for this problem would be highly appreciated!
</p>
<p>
Best regards,
</p>
<p>
Hui
</p>
<p>
Dear all,
</p>
<p>
I encountered a problem with using 30000 m model top over Asian domain. The interpolated temperature (T) at the top model level of
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
has some abnormal values (even minus Kelvin) over the northern part of our model, associated with other parameters (such as PP, U and V) wrong as well. It seems that these abnormal T values are related to the very low temperature in the uppermost model level, and the problem is only seen in the winter season, but not in summer. Also, if I use the default model top (i.e. about 23000 m), there is no such problem. I am wondering whether there might be some bugs in vertical interpolation of T for the case when the model top of
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
is higher than that of the driving model? We use output from ECHAM5 T31, 19 level.
</p>
<p>
Attached is our
<span class="caps">
OUTPUT
</span>
file of INT2LM (int2lm_091216_1.10_clm9) and an example of our driving data (cfsd******.nc) and output data from INT2LM (lbfd******.nc). Any suggestions on possible solutions for this problem would be highly appreciated!
</p>
<p>
Best regards,
</p>
<p>
Hui
</p>
An issue in using 30000 m model top over Asian domain
I encountered a problem with using 30000 m model top over Asian domain. The interpolated temperature (T) at the top model level of
COSMO
-
CLM
has some abnormal values (even minus Kelvin) over the northern part of our model, associated with other parameters (such as PP, U and V) wrong as well. It seems that these abnormal T values are related to the very low temperature in the uppermost model level, and the problem is only seen in the winter season, but not in summer. Also, if I use the default model top (i.e. about 23000 m), there is no such problem. I am wondering whether there might be some bugs in vertical interpolation of T for the case when the model top of
COSMO
-
CLM
is higher than that of the driving model? We use output from ECHAM5 T31, 19 level.
Attached is our
OUTPUT
file of INT2LM (int2lm_091216_1.10_clm9) and an example of our driving data (cfsd******.nc) and output data from INT2LM (lbfd******.nc). Any suggestions on possible solutions for this problem would be highly appreciated!
<p>
If just the upper level of
<span class="caps">
CCLM
</span>
is higher than the driving model, this should be handled by INT2LM. However, I am not sure what happens, if two
<span class="caps">
CCLM
</span>
levels are above the driving model.
<br/>
Can you check whether this is the case in the grid boxes where these unrealistic values appear?
</p>
<p>
If just the upper level of
<span class="caps">
CCLM
</span>
is higher than the driving model, this should be handled by INT2LM. However, I am not sure what happens, if two
<span class="caps">
CCLM
</span>
levels are above the driving model.
<br/>
Can you check whether this is the case in the grid boxes where these unrealistic values appear?
</p>
If just the upper level of
CCLM
is higher than the driving model, this should be handled by INT2LM. However, I am not sure what happens, if two
CCLM
levels are above the driving model.
Can you check whether this is the case in the grid boxes where these unrealistic values appear?
<p>
Burkhardt might be correct.
<br/>
As far as I remember, the INT2LM Version 1.10 is already able to handle the case where the uppermost
<span class="caps">
CCLM
</span>
layer is above the highest
<span class="caps">
GCM
</span>
layer.
<br/>
If I interpret the ECHAM5 vertical coordinate correctly, the highest level with meaningful values is at 20 hPa, which,
<br/>
with respect to the standard atmosphere is slightly higher than 26000 m.
<br/>
Thus, for INT2LM/CCLM you really have an additional layer from 27800 to 30000 m.
<br/>
Just in order to test Burkhardt’s hypothesis, delete the 27800 m level.
<br/>
Then you have 34 layers, the uppermost one from 25710 to 30000 m.
<br/>
See what happens.
<br/>
But be aware that this case is only for testing!!!!!
<br/>
Don’t use my suggestion as the new vertical coordinate for your simulations. It does not make sense!!!!
</p>
<p>
An alternative could also be not to use results of ECHAM5 as driving data but those of ECHAM6 (
<span class="caps">
MPI
</span>
-ES-LR)
</p>
<p>
Hans-Juergen
</p>
<p>
Burkhardt might be correct.
<br/>
As far as I remember, the INT2LM Version 1.10 is already able to handle the case where the uppermost
<span class="caps">
CCLM
</span>
layer is above the highest
<span class="caps">
GCM
</span>
layer.
<br/>
If I interpret the ECHAM5 vertical coordinate correctly, the highest level with meaningful values is at 20 hPa, which,
<br/>
with respect to the standard atmosphere is slightly higher than 26000 m.
<br/>
Thus, for INT2LM/CCLM you really have an additional layer from 27800 to 30000 m.
<br/>
Just in order to test Burkhardt’s hypothesis, delete the 27800 m level.
<br/>
Then you have 34 layers, the uppermost one from 25710 to 30000 m.
<br/>
See what happens.
<br/>
But be aware that this case is only for testing!!!!!
<br/>
Don’t use my suggestion as the new vertical coordinate for your simulations. It does not make sense!!!!
</p>
<p>
An alternative could also be not to use results of ECHAM5 as driving data but those of ECHAM6 (
<span class="caps">
MPI
</span>
-ES-LR)
</p>
<p>
Hans-Juergen
</p>
Burkhardt might be correct.
As far as I remember, the INT2LM Version 1.10 is already able to handle the case where the uppermost
CCLM
layer is above the highest
GCM
layer.
If I interpret the ECHAM5 vertical coordinate correctly, the highest level with meaningful values is at 20 hPa, which,
with respect to the standard atmosphere is slightly higher than 26000 m.
Thus, for INT2LM/CCLM you really have an additional layer from 27800 to 30000 m.
Just in order to test Burkhardt’s hypothesis, delete the 27800 m level.
Then you have 34 layers, the uppermost one from 25710 to 30000 m.
See what happens.
But be aware that this case is only for testing!!!!!
Don’t use my suggestion as the new vertical coordinate for your simulations. It does not make sense!!!!
An alternative could also be not to use results of ECHAM5 as driving data but those of ECHAM6 (
MPI
-ES-LR)
<p>
Dear Hans-Juergen and Burkhardt,
</p>
<p>
Thank you very much for your reply. Hans is right. If I remove the 27800 m level, the problem is gone. The highest level has correct values. So there should be some thing wrong with interpolating more than one additional levels above the driving model?
</p>
<p>
Unfortunately, for our experiments, I have to use the ECHAM5 output. And I also found that raising the model top to 30000 m is critical to get summer precipitation over the monsoon region correct with 0.44×0.44 resolution. Is there any way I could develop a relatively reasonable scheme to extrapolate data to the additional levels (more than 1 levels) above the driving model?
</p>
<p>
Best regards,
</p>
<p>
Hui
</p>
<p>
Dear Hans-Juergen and Burkhardt,
</p>
<p>
Thank you very much for your reply. Hans is right. If I remove the 27800 m level, the problem is gone. The highest level has correct values. So there should be some thing wrong with interpolating more than one additional levels above the driving model?
</p>
<p>
Unfortunately, for our experiments, I have to use the ECHAM5 output. And I also found that raising the model top to 30000 m is critical to get summer precipitation over the monsoon region correct with 0.44×0.44 resolution. Is there any way I could develop a relatively reasonable scheme to extrapolate data to the additional levels (more than 1 levels) above the driving model?
</p>
<p>
Best regards,
</p>
<p>
Hui
</p>
Thank you very much for your reply. Hans is right. If I remove the 27800 m level, the problem is gone. The highest level has correct values. So there should be some thing wrong with interpolating more than one additional levels above the driving model?
Unfortunately, for our experiments, I have to use the ECHAM5 output. And I also found that raising the model top to 30000 m is critical to get summer precipitation over the monsoon region correct with 0.44×0.44 resolution. Is there any way I could develop a relatively reasonable scheme to extrapolate data to the additional levels (more than 1 levels) above the driving model?
<p>
The only quick possibility I see is to reduce the top of the
<span class="caps">
CCLM
</span>
domain from 30000 to 28000, if this is still appropriate,
<br/>
and to define new levels.
<br/>
Here is an example:
</p>
28000.00, 25800.00, 23720.00, 21760.00, 19915.00,
18180.00, 16550.00, 15030.00, 13610.00, 12280.00,
11050.00, 9900.00, 8850.00, 7870.00, 6975.00,
6155.00, 5405.00, 4723.00, 4106.00, 3550.00,
3051.00, 2605.00, 2210.00, 1860.00, 1555.00,
1288.00, 1058.00, 859.00, 689.00, 544.00,
421.00, 315.00, 224.00, 143.00, 70.00,
0.00,
<p>
The number of levels is still 35, the thickness of the lowest layer still 70 m, that of the top layer still 2200 m.
<br/>
If this is not suitable for your problem then I don’t have further ideas. Remaining with 30000 m means that you have to choose a thickness of about 4500 m for the top layer.
<br/>
This is rather thick (coarse) and then you might get problems in order get a stretching of the vertical grid which still produces results being numerically stable.
</p>
<p>
The only quick possibility I see is to reduce the top of the
<span class="caps">
CCLM
</span>
domain from 30000 to 28000, if this is still appropriate,
<br/>
and to define new levels.
<br/>
Here is an example:
</p>
28000.00, 25800.00, 23720.00, 21760.00, 19915.00,
18180.00, 16550.00, 15030.00, 13610.00, 12280.00,
11050.00, 9900.00, 8850.00, 7870.00, 6975.00,
6155.00, 5405.00, 4723.00, 4106.00, 3550.00,
3051.00, 2605.00, 2210.00, 1860.00, 1555.00,
1288.00, 1058.00, 859.00, 689.00, 544.00,
421.00, 315.00, 224.00, 143.00, 70.00,
0.00,
<p>
The number of levels is still 35, the thickness of the lowest layer still 70 m, that of the top layer still 2200 m.
<br/>
If this is not suitable for your problem then I don’t have further ideas. Remaining with 30000 m means that you have to choose a thickness of about 4500 m for the top layer.
<br/>
This is rather thick (coarse) and then you might get problems in order get a stretching of the vertical grid which still produces results being numerically stable.
</p>
The only quick possibility I see is to reduce the top of the
CCLM
domain from 30000 to 28000, if this is still appropriate,
and to define new levels.
Here is an example:
The number of levels is still 35, the thickness of the lowest layer still 70 m, that of the top layer still 2200 m.
If this is not suitable for your problem then I don’t have further ideas. Remaining with 30000 m means that you have to choose a thickness of about 4500 m for the top layer.
This is rather thick (coarse) and then you might get problems in order get a stretching of the vertical grid which still produces results being numerically stable.
An issue in using 30000 m model top over Asian domain
Dear all,
I encountered a problem with using 30000 m model top over Asian domain. The interpolated temperature (T) at the top model level of COSMO - CLM has some abnormal values (even minus Kelvin) over the northern part of our model, associated with other parameters (such as PP, U and V) wrong as well. It seems that these abnormal T values are related to the very low temperature in the uppermost model level, and the problem is only seen in the winter season, but not in summer. Also, if I use the default model top (i.e. about 23000 m), there is no such problem. I am wondering whether there might be some bugs in vertical interpolation of T for the case when the model top of COSMO - CLM is higher than that of the driving model? We use output from ECHAM5 T31, 19 level.
Attached is our OUTPUT file of INT2LM (int2lm_091216_1.10_clm9) and an example of our driving data (cfsd******.nc) and output data from INT2LM (lbfd******.nc). Any suggestions on possible solutions for this problem would be highly appreciated!
Best regards,
Hui
If just the upper level of CCLM is higher than the driving model, this should be handled by INT2LM. However, I am not sure what happens, if two CCLM levels are above the driving model.
Can you check whether this is the case in the grid boxes where these unrealistic values appear?
Burkhardt might be correct.
As far as I remember, the INT2LM Version 1.10 is already able to handle the case where the uppermost CCLM layer is above the highest GCM layer.
If I interpret the ECHAM5 vertical coordinate correctly, the highest level with meaningful values is at 20 hPa, which,
with respect to the standard atmosphere is slightly higher than 26000 m.
Thus, for INT2LM/CCLM you really have an additional layer from 27800 to 30000 m.
Just in order to test Burkhardt’s hypothesis, delete the 27800 m level.
Then you have 34 layers, the uppermost one from 25710 to 30000 m.
See what happens.
But be aware that this case is only for testing!!!!!
Don’t use my suggestion as the new vertical coordinate for your simulations. It does not make sense!!!!
An alternative could also be not to use results of ECHAM5 as driving data but those of ECHAM6 ( MPI -ES-LR)
Hans-Juergen
Dear Hans-Juergen and Burkhardt,
Thank you very much for your reply. Hans is right. If I remove the 27800 m level, the problem is gone. The highest level has correct values. So there should be some thing wrong with interpolating more than one additional levels above the driving model?
Unfortunately, for our experiments, I have to use the ECHAM5 output. And I also found that raising the model top to 30000 m is critical to get summer precipitation over the monsoon region correct with 0.44×0.44 resolution. Is there any way I could develop a relatively reasonable scheme to extrapolate data to the additional levels (more than 1 levels) above the driving model?
Best regards,
Hui
The only quick possibility I see is to reduce the top of the CCLM domain from 30000 to 28000, if this is still appropriate,
28000.00, 25800.00, 23720.00, 21760.00, 19915.00, 18180.00, 16550.00, 15030.00, 13610.00, 12280.00, 11050.00, 9900.00, 8850.00, 7870.00, 6975.00, 6155.00, 5405.00, 4723.00, 4106.00, 3550.00, 3051.00, 2605.00, 2210.00, 1860.00, 1555.00, 1288.00, 1058.00, 859.00, 689.00, 544.00, 421.00, 315.00, 224.00, 143.00, 70.00, 0.00,and to define new levels.
Here is an example:
The number of levels is still 35, the thickness of the lowest layer still 70 m, that of the top layer still 2200 m.
If this is not suitable for your problem then I don’t have further ideas. Remaining with 30000 m means that you have to choose a thickness of about 4500 m for the top layer.
This is rather thick (coarse) and then you might get problems in order get a stretching of the vertical grid which still produces results being numerically stable.