Strange wind data in small area over Alps in CCLM5 output
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
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
@hans-jürgenpanitz in #e23d841
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
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
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
@hans-jürgenpanitz in #b666805
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
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
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