An issue in using 30000 m model top over Asian domain – in #10: INT2LM

in #10: INT2LM

<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>

  @redc_migration in #2bd5c29

<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

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

View in channel
<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>

  @burkhardtrockel in #311c5d5

<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>

  @hans-jürgenpanitz in #d40d7c2

<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)

Hans-Juergen

<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>

  @redc_migration in #f0eda3a

<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>

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

<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>

  @hans-jürgenpanitz in #9bd2088

<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:

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,

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.