EXTPAR source code – in #11: EXTPAR / WebPEP

in #11: EXTPAR / WebPEP

<p> Hello, </p> <p> my domain covers the weddell sea and the Ronne Ice Shelf. The ice shelf is not present in the H_SURF variable from the domainfile produced by WebPEP. <br/> I have an orographic data set (which includes the ice shelfs), that I want to use for H_SURF. <br/> My question concerns the <span class="caps"> SSO </span> parameterization, that would depend on a new orography. <br/> Are the 4 <span class="caps"> SSO </span> parameters computed by <span class="caps"> EXTPAR </span> ? If yes, is the <span class="caps"> EXTPAR </span> source code somewhere available? </p> <p> I also have another related question, but if it doesn´t fit here, I can repost it in the INT2LM forum. <br/> I prepared the external data with WebPEP (Orographic Filtering = No) and after using INT2LM the H_SURF (which was &gt;0m everywhere before) many pixels that are negative (mostly -30m to -20m but some are even below -100m) <br/> First: Is this ok? <br/> Second: Is it ok, that the <span class="caps"> SSO </span> parameters are “made for the original H_SURF” when such differences occur? </p>

  @rolfzentek in #497ff91

<p> Hello, </p> <p> my domain covers the weddell sea and the Ronne Ice Shelf. The ice shelf is not present in the H_SURF variable from the domainfile produced by WebPEP. <br/> I have an orographic data set (which includes the ice shelfs), that I want to use for H_SURF. <br/> My question concerns the <span class="caps"> SSO </span> parameterization, that would depend on a new orography. <br/> Are the 4 <span class="caps"> SSO </span> parameters computed by <span class="caps"> EXTPAR </span> ? If yes, is the <span class="caps"> EXTPAR </span> source code somewhere available? </p> <p> I also have another related question, but if it doesn´t fit here, I can repost it in the INT2LM forum. <br/> I prepared the external data with WebPEP (Orographic Filtering = No) and after using INT2LM the H_SURF (which was &gt;0m everywhere before) many pixels that are negative (mostly -30m to -20m but some are even below -100m) <br/> First: Is this ok? <br/> Second: Is it ok, that the <span class="caps"> SSO </span> parameters are “made for the original H_SURF” when such differences occur? </p>

EXTPAR source code

RZ wrote

Hello,

my domain covers the weddell sea and the Ronne Ice Shelf. The ice shelf is not present in the H_SURF variable from the domainfile produced by WebPEP.
I have an orographic data set (which includes the ice shelfs), that I want to use for H_SURF.
My question concerns the SSO parameterization, that would depend on a new orography.
Are the 4 SSO parameters computed by EXTPAR ? If yes, is the EXTPAR source code somewhere available?

I also have another related question, but if it doesn´t fit here, I can repost it in the INT2LM forum.
I prepared the external data with WebPEP (Orographic Filtering = No) and after using INT2LM the H_SURF (which was >0m everywhere before) many pixels that are negative (mostly -30m to -20m but some are even below -100m)
First: Is this ok?
Second: Is it ok, that the SSO parameters are “made for the original H_SURF” when such differences occur?

View in channel
<p> Dear Rolf </p> <p> Yes, the parameters for the <span class="caps"> SSO </span> parameterization are produced within <br/> EXTPAR. As far as the <span class="caps"> SSO </span> parameters are concerned, they relate to the <br/> slope of the orographie, to subgrid scale variability and the anisotropy <br/> of these fields. <br/> The <span class="caps"> EXTPAR </span> code is available for download when choosing the files tab <br/> if the <span class="caps"> EXTPAR </span> project has been selected. </p> <p> The <span class="caps"> SSO </span> fields over the ice shelf are computed as values for a sea <br/> point, i.e. all values are set to 0. </p> <p> What is the resolution of your grid, and what is the resolution of <br/> your alternative orography data set? For grid resolution finer than <br/> 3km you needn’t care about <span class="caps"> SSO </span> anyway, since the respective processes <br/> are resolved explicitly there. </p> <p> What is probably more relevant is the surface roughness that is also <br/> dependent on the variability of the subgrid scale orography and this <br/> is calculated in <span class="caps"> EXTPAR </span> , too. </p> <p> Regarding the filtering in int2lm, what filter options did you use there? </p> <p> I hope this answer is helpful to you. </p> <p> best regards </p> <p> Daniel Lüthi </p>

  @redc_migration in #90e47fa

<p> Dear Rolf </p> <p> Yes, the parameters for the <span class="caps"> SSO </span> parameterization are produced within <br/> EXTPAR. As far as the <span class="caps"> SSO </span> parameters are concerned, they relate to the <br/> slope of the orographie, to subgrid scale variability and the anisotropy <br/> of these fields. <br/> The <span class="caps"> EXTPAR </span> code is available for download when choosing the files tab <br/> if the <span class="caps"> EXTPAR </span> project has been selected. </p> <p> The <span class="caps"> SSO </span> fields over the ice shelf are computed as values for a sea <br/> point, i.e. all values are set to 0. </p> <p> What is the resolution of your grid, and what is the resolution of <br/> your alternative orography data set? For grid resolution finer than <br/> 3km you needn’t care about <span class="caps"> SSO </span> anyway, since the respective processes <br/> are resolved explicitly there. </p> <p> What is probably more relevant is the surface roughness that is also <br/> dependent on the variability of the subgrid scale orography and this <br/> is calculated in <span class="caps"> EXTPAR </span> , too. </p> <p> Regarding the filtering in int2lm, what filter options did you use there? </p> <p> I hope this answer is helpful to you. </p> <p> best regards </p> <p> Daniel Lüthi </p>
re replied

Dear Rolf

Yes, the parameters for the SSO parameterization are produced within
EXTPAR. As far as the SSO parameters are concerned, they relate to the
slope of the orographie, to subgrid scale variability and the anisotropy
of these fields.
The EXTPAR code is available for download when choosing the files tab
if the EXTPAR project has been selected.

The SSO fields over the ice shelf are computed as values for a sea
point, i.e. all values are set to 0.

What is the resolution of your grid, and what is the resolution of
your alternative orography data set? For grid resolution finer than
3km you needn’t care about SSO anyway, since the respective processes
are resolved explicitly there.

What is probably more relevant is the surface roughness that is also
dependent on the variability of the subgrid scale orography and this
is calculated in EXTPAR , too.

Regarding the filtering in int2lm, what filter options did you use there?

I hope this answer is helpful to you.

best regards

Daniel Lüthi

View in channel
<p> Dear Daniel, </p> <p> thanks for the fast answer. (and yes it was very helpful) </p> <p> The resolutions are 15km and 5km for my grid and the resolution of the orography data set is 30-arc-second. </p> <p> For int2lm (1.20) I just used lfilter_oro=.TRUE. and default settings. </p> <p> regards <br/> Rolf </p>

  @rolfzentek in #09ef8af

<p> Dear Daniel, </p> <p> thanks for the fast answer. (and yes it was very helpful) </p> <p> The resolutions are 15km and 5km for my grid and the resolution of the orography data set is 30-arc-second. </p> <p> For int2lm (1.20) I just used lfilter_oro=.TRUE. and default settings. </p> <p> regards <br/> Rolf </p>
RZ replied

Dear Daniel,

thanks for the fast answer. (and yes it was very helpful)

The resolutions are 15km and 5km for my grid and the resolution of the orography data set is 30-arc-second.

For int2lm (1.20) I just used lfilter_oro=.TRUE. and default settings.

regards
Rolf

View in channel
<p> Dear Daniel, </p> <p> I implemented the algorithims to compute the <span class="caps"> SSO </span> -parameters in a R-script. To verify my code I tried to reproduce the <span class="caps"> SSO </span> data output from WebPEP. <br/> I downloaded the <span class="caps"> GLOBE </span> data for this, but WebPEP uses (according to the manual – page 10) a 3km filtered topography. <br/> Is there a way for me to access this filtered data? <br/> Could you give me some more informations about this scale seperation? (Did you use spherical harmonics and remove everything under 3km wavelength? Do you know how important this filtering is / should I replicate it for my topographic data set?) </p> <p> with regards <br/> Rolf </p>

  @rolfzentek in #c9923ab

<p> Dear Daniel, </p> <p> I implemented the algorithims to compute the <span class="caps"> SSO </span> -parameters in a R-script. To verify my code I tried to reproduce the <span class="caps"> SSO </span> data output from WebPEP. <br/> I downloaded the <span class="caps"> GLOBE </span> data for this, but WebPEP uses (according to the manual – page 10) a 3km filtered topography. <br/> Is there a way for me to access this filtered data? <br/> Could you give me some more informations about this scale seperation? (Did you use spherical harmonics and remove everything under 3km wavelength? Do you know how important this filtering is / should I replicate it for my topographic data set?) </p> <p> with regards <br/> Rolf </p>
RZ replied

Dear Daniel,

I implemented the algorithims to compute the SSO -parameters in a R-script. To verify my code I tried to reproduce the SSO data output from WebPEP.
I downloaded the GLOBE data for this, but WebPEP uses (according to the manual – page 10) a 3km filtered topography.
Is there a way for me to access this filtered data?
Could you give me some more informations about this scale seperation? (Did you use spherical harmonics and remove everything under 3km wavelength? Do you know how important this filtering is / should I replicate it for my topographic data set?)

with regards
Rolf

View in channel