Strange wind data in small area over Alps in CCLM5 output – in #9: CCLM

in #9: CCLM

<p> Dear colleagues, </p> <p> I encountered a problem with <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> _5_clm16 version on 0.0275° resolution at a few grid points in the southern Alps (South Tyrol region). Immediately after model start (visible at first output after the start) unusual high winds (+/- 30 m/s) occur at these grid points and remain there without affecting neighbouring points. However, also surface temperature and fluxes are affected. The problem exists in a historical run, in a scenario run and also with different forcing. <br/> Does anyone of you face similar problems or has anyone a suggestion what is going on there? </p> <p> Best regards, </p> <p> Michael </p>

  @michaelhaller in #c57f822

<p> Dear colleagues, </p> <p> I encountered a problem with <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> _5_clm16 version on 0.0275° resolution at a few grid points in the southern Alps (South Tyrol region). Immediately after model start (visible at first output after the start) unusual high winds (+/- 30 m/s) occur at these grid points and remain there without affecting neighbouring points. However, also surface temperature and fluxes are affected. The problem exists in a historical run, in a scenario run and also with different forcing. <br/> Does anyone of you face similar problems or has anyone a suggestion what is going on there? </p> <p> Best regards, </p> <p> Michael </p>

Strange wind data in small area over Alps in CCLM5 output

MH wrote

Dear colleagues,

I encountered a problem with COSMO - CLM _5_clm16 version on 0.0275° resolution at a few grid points in the southern Alps (South Tyrol region). Immediately after model start (visible at first output after the start) unusual high winds (+/- 30 m/s) occur at these grid points and remain there without affecting neighbouring points. However, also surface temperature and fluxes are affected. The problem exists in a historical run, in a scenario run and also with different forcing.
Does anyone of you face similar problems or has anyone a suggestion what is going on there?

Best regards,

Michael

View in channel
<p> Hi Michael, </p> <p> I have to admit, I see it also, in my <span class="caps"> FPS </span> Convection simulations. <br/> It appears in all simulations, <span class="caps"> ERA </span> -Interim evaluation runs, and <span class="caps"> MPI </span> - <span class="caps"> ESM </span> -LR, hist and RCP8.5 10-years time slices. <br/> And in the direct neighborhood of a grid-point with high positive U_10m values there are points with large negative values. <br/> I did not look at V_10m yet. <br/> My runs are two nest simulations, this means, I further downscaled already existing <span class="caps"> CCLM </span> data to the final resolution of 0.0275 deg (=3km). <br/> Thus, I will have look into the results of the first nests. <br/> I looked into the soiltype data in that area. In my data the code there is 5 (loam). <br/> Can steepness of orography be a problem? <br/> Perhaps, it might be worth to activate filtering of orography and, in a second step, valley filling. <br/> But both settings have to be done already in INT2LM. </p> <p> Best <br/> Hans-Juergen </p>

  @hans-jürgenpanitz in #e23d841

<p> Hi Michael, </p> <p> I have to admit, I see it also, in my <span class="caps"> FPS </span> Convection simulations. <br/> It appears in all simulations, <span class="caps"> ERA </span> -Interim evaluation runs, and <span class="caps"> MPI </span> - <span class="caps"> ESM </span> -LR, hist and RCP8.5 10-years time slices. <br/> And in the direct neighborhood of a grid-point with high positive U_10m values there are points with large negative values. <br/> I did not look at V_10m yet. <br/> My runs are two nest simulations, this means, I further downscaled already existing <span class="caps"> CCLM </span> data to the final resolution of 0.0275 deg (=3km). <br/> Thus, I will have look into the results of the first nests. <br/> I looked into the soiltype data in that area. In my data the code there is 5 (loam). <br/> Can steepness of orography be a problem? <br/> Perhaps, it might be worth to activate filtering of orography and, in a second step, valley filling. <br/> But both settings have to be done already in INT2LM. </p> <p> Best <br/> Hans-Juergen </p>
HP replied

Hi Michael,

I have to admit, I see it also, in my FPS Convection simulations.
It appears in all simulations, ERA -Interim evaluation runs, and MPI - ESM -LR, hist and RCP8.5 10-years time slices.
And in the direct neighborhood of a grid-point with high positive U_10m values there are points with large negative values.
I did not look at V_10m yet.
My runs are two nest simulations, this means, I further downscaled already existing CCLM data to the final resolution of 0.0275 deg (=3km).
Thus, I will have look into the results of the first nests.
I looked into the soiltype data in that area. In my data the code there is 5 (loam).
Can steepness of orography be a problem?
Perhaps, it might be worth to activate filtering of orography and, in a second step, valley filling.
But both settings have to be done already in INT2LM.

Best
Hans-Juergen

View in channel
<p> Hi Michael, </p> <p> to my opinion, the problem is independent of the CCLM5 sub-version. <br/> I see it also in the results of some of my 1-year (1999) test runs that I carried out in order to find a suitable model setup for the <span class="caps"> FPS </span> Convection runs. <br/> These tests had been perforemd with CCLM5-0-10. <br/> And I think I identified the responsible Namelist-parameter by checking a variety of the test runs. <br/> It seems to be: <br/> hd_corr_u_in <br/> that I set to the value of 1., since the experiment with this value showed a positive impact on precipitation by reducing the wet bias over mountainous areas. <br/> The value used in <span class="caps"> COSMO </span> _DE and, thus, also im my reference setup of the tests, is 0.1 <br/> The coded default is 0.25. </p> <p> Only those of my experiments that used hd_corr_u_in=1. show the strange U_10M data in the region you mentioned. <br/> I tested also hd_corr_u_in=0.0; no such strange values. </p> <p> I have to admit, while analyzing the results of my tests I focused on <span class="caps"> TOT </span> _PREC and T_2M. I never looked at the wind components. </p> <p> Would it be possbile that you perform a short test by putting the hd_corr_u_in value back to 0.1? (myself, I can’t run jobs presently!!!) <br/> I assume you will see an impact very soon. <br/> I see the U_10M “hotspot” already after the first hour (my storage interval is 1 hour). </p> <p> However, some questions remain: <br/> - why only U and not V? What really “happens” in the code? <br/> - why only in this small area and not also elsewhere? <br/> - would the change of hd_corr_u_in from 1 back to 0.1 also have an impact on other variables, e.g. <span class="caps"> TOT </span> _PREC and T_2M? If yes, how strong? </p> <p> Hans-Juergen </p>

  @hans-jürgenpanitz in #b666805

<p> Hi Michael, </p> <p> to my opinion, the problem is independent of the CCLM5 sub-version. <br/> I see it also in the results of some of my 1-year (1999) test runs that I carried out in order to find a suitable model setup for the <span class="caps"> FPS </span> Convection runs. <br/> These tests had been perforemd with CCLM5-0-10. <br/> And I think I identified the responsible Namelist-parameter by checking a variety of the test runs. <br/> It seems to be: <br/> hd_corr_u_in <br/> that I set to the value of 1., since the experiment with this value showed a positive impact on precipitation by reducing the wet bias over mountainous areas. <br/> The value used in <span class="caps"> COSMO </span> _DE and, thus, also im my reference setup of the tests, is 0.1 <br/> The coded default is 0.25. </p> <p> Only those of my experiments that used hd_corr_u_in=1. show the strange U_10M data in the region you mentioned. <br/> I tested also hd_corr_u_in=0.0; no such strange values. </p> <p> I have to admit, while analyzing the results of my tests I focused on <span class="caps"> TOT </span> _PREC and T_2M. I never looked at the wind components. </p> <p> Would it be possbile that you perform a short test by putting the hd_corr_u_in value back to 0.1? (myself, I can’t run jobs presently!!!) <br/> I assume you will see an impact very soon. <br/> I see the U_10M “hotspot” already after the first hour (my storage interval is 1 hour). </p> <p> However, some questions remain: <br/> - why only U and not V? What really “happens” in the code? <br/> - why only in this small area and not also elsewhere? <br/> - would the change of hd_corr_u_in from 1 back to 0.1 also have an impact on other variables, e.g. <span class="caps"> TOT </span> _PREC and T_2M? If yes, how strong? </p> <p> Hans-Juergen </p>
HP replied

Hi Michael,

to my opinion, the problem is independent of the CCLM5 sub-version.
I see it also in the results of some of my 1-year (1999) test runs that I carried out in order to find a suitable model setup for the FPS Convection runs.
These tests had been perforemd with CCLM5-0-10.
And I think I identified the responsible Namelist-parameter by checking a variety of the test runs.
It seems to be:
hd_corr_u_in
that I set to the value of 1., since the experiment with this value showed a positive impact on precipitation by reducing the wet bias over mountainous areas.
The value used in COSMO _DE and, thus, also im my reference setup of the tests, is 0.1
The coded default is 0.25.

Only those of my experiments that used hd_corr_u_in=1. show the strange U_10M data in the region you mentioned.
I tested also hd_corr_u_in=0.0; no such strange values.

I have to admit, while analyzing the results of my tests I focused on TOT _PREC and T_2M. I never looked at the wind components.

Would it be possbile that you perform a short test by putting the hd_corr_u_in value back to 0.1? (myself, I can’t run jobs presently!!!)
I assume you will see an impact very soon.
I see the U_10M “hotspot” already after the first hour (my storage interval is 1 hour).

However, some questions remain:
- why only U and not V? What really “happens” in the code?
- why only in this small area and not also elsewhere?
- would the change of hd_corr_u_in from 1 back to 0.1 also have an impact on other variables, e.g. TOT _PREC and T_2M? If yes, how strong?

Hans-Juergen

View in channel