Ruben Borgers in #8: General Questions on June 02 (#48c7638)

in #8: General Questions

<p> Since COSMO-CLM works on a rotated spherical grid, it removes any influence of the spheroidal shape of the earth. However, many datasets are specified in terms of WGS84 geographic coordinates, the internationally used spheroid representation of Earth. If I inspect my INT2LM and COSMO-CLM data with "cdo sinfo", I see the main grid specified both in terms of rotated longitude (rlon) and rotated latitude (rlat), but also longitude (lon) and latitude (lat). I am trying to find out whether the specified longitude and latitude are for the CCLM sphere or actually already converted to WGS84 (or perhaps another reference spheroid). If these are spherical, it implies that when compared to other WGS84 datasets or when data is added to e.g. the initial conditions file, there is a need to first convert between the spheroidal and spherical system. Can someone answer this for me? </p> <p> Thanks in advance! </p> <p> Ruben </p>

  @rubenborgers in #48c7638

<p> Since COSMO-CLM works on a rotated spherical grid, it removes any influence of the spheroidal shape of the earth. However, many datasets are specified in terms of WGS84 geographic coordinates, the internationally used spheroid representation of Earth. If I inspect my INT2LM and COSMO-CLM data with "cdo sinfo", I see the main grid specified both in terms of rotated longitude (rlon) and rotated latitude (rlat), but also longitude (lon) and latitude (lat). I am trying to find out whether the specified longitude and latitude are for the CCLM sphere or actually already converted to WGS84 (or perhaps another reference spheroid). If these are spherical, it implies that when compared to other WGS84 datasets or when data is added to e.g. the initial conditions file, there is a need to first convert between the spheroidal and spherical system. Can someone answer this for me? </p> <p> Thanks in advance! </p> <p> Ruben </p>
RB wrote

Since COSMO-CLM works on a rotated spherical grid, it removes any influence of the spheroidal shape of the earth. However, many datasets are specified in terms of WGS84 geographic coordinates, the internationally used spheroid representation of Earth. If I inspect my INT2LM and COSMO-CLM data with "cdo sinfo", I see the main grid specified both in terms of rotated longitude (rlon) and rotated latitude (rlat), but also longitude (lon) and latitude (lat). I am trying to find out whether the specified longitude and latitude are for the CCLM sphere or actually already converted to WGS84 (or perhaps another reference spheroid). If these are spherical, it implies that when compared to other WGS84 datasets or when data is added to e.g. the initial conditions file, there is a need to first convert between the spheroidal and spherical system. Can someone answer this for me?

Thanks in advance!

Ruben

View in channel
<p> Hey, I am just another user, and this is NOT an expert answer from someone who programmed the code... </p> <p> as far as I know/read, both the rotated coordinates and unrotated coordinates are in spherical systems. </p> <p> for example the rotation formula I saw in some code (don´t remember if cclm, int2lm or extpar) I think was the same as in the R-tools functions geo2rot and rot2geo which to me looks like "just rotating". Also just last week I tested another script that just constructed a 3x3-rotation-matrix with sin&amp;cos and this was used for a simple matrix multiplication, it yielded the same results (the numerical error yielded a difference smaller than 2m between the two scripts...) as the rot2geo function from the R-tools of the clm-community. </p> <p> So I think it is safe to say that WGS84 / spheroidal systems are not used?! </p> <p> But... as CCLM is a regional model this might not even be a problem. If all input data taking was on WGS84 (for example topography, etc.) and the lon/lat values are taken just "as if not on WGS84" (so no conversion takes place) this should give you a region model domain basically on WGS84 - if my thinking is correct... </p> <p> Take some fixed point lat/lon. If you don´t convert but just get the topography value from a WGS84 dataset, and the land-useage value from a WGS84 data set. Than CCLM will have the right values at the lat/lon, in so far as, that if you later want to compare it a observation data (on WGS84) this will all work out in the end. </p> <p> But I don´t know what extpar does... or what data you use for forcing... <br/> If the topography is really converted from WGS84 to a sphere and these values are taken, I guess this could lead to a noticable shift for high resolution simulations. See for example: https://doi.org/10.1175/MWR-D-12-00351.1 </p> <p> If you use WebPEP maybe someone more familiar with EXTPAR can comment on how global data was handled there? </p> <p> Cheer <br/> Rolf </p>

  @rolfzentek in #967e37c

<p> Hey, I am just another user, and this is NOT an expert answer from someone who programmed the code... </p> <p> as far as I know/read, both the rotated coordinates and unrotated coordinates are in spherical systems. </p> <p> for example the rotation formula I saw in some code (don´t remember if cclm, int2lm or extpar) I think was the same as in the R-tools functions geo2rot and rot2geo which to me looks like "just rotating". Also just last week I tested another script that just constructed a 3x3-rotation-matrix with sin&amp;cos and this was used for a simple matrix multiplication, it yielded the same results (the numerical error yielded a difference smaller than 2m between the two scripts...) as the rot2geo function from the R-tools of the clm-community. </p> <p> So I think it is safe to say that WGS84 / spheroidal systems are not used?! </p> <p> But... as CCLM is a regional model this might not even be a problem. If all input data taking was on WGS84 (for example topography, etc.) and the lon/lat values are taken just "as if not on WGS84" (so no conversion takes place) this should give you a region model domain basically on WGS84 - if my thinking is correct... </p> <p> Take some fixed point lat/lon. If you don´t convert but just get the topography value from a WGS84 dataset, and the land-useage value from a WGS84 data set. Than CCLM will have the right values at the lat/lon, in so far as, that if you later want to compare it a observation data (on WGS84) this will all work out in the end. </p> <p> But I don´t know what extpar does... or what data you use for forcing... <br/> If the topography is really converted from WGS84 to a sphere and these values are taken, I guess this could lead to a noticable shift for high resolution simulations. See for example: https://doi.org/10.1175/MWR-D-12-00351.1 </p> <p> If you use WebPEP maybe someone more familiar with EXTPAR can comment on how global data was handled there? </p> <p> Cheer <br/> Rolf </p>
RZ replied

Hey, I am just another user, and this is NOT an expert answer from someone who programmed the code...

as far as I know/read, both the rotated coordinates and unrotated coordinates are in spherical systems.

for example the rotation formula I saw in some code (don´t remember if cclm, int2lm or extpar) I think was the same as in the R-tools functions geo2rot and rot2geo which to me looks like "just rotating". Also just last week I tested another script that just constructed a 3x3-rotation-matrix with sin&cos and this was used for a simple matrix multiplication, it yielded the same results (the numerical error yielded a difference smaller than 2m between the two scripts...) as the rot2geo function from the R-tools of the clm-community.

So I think it is safe to say that WGS84 / spheroidal systems are not used?!

But... as CCLM is a regional model this might not even be a problem. If all input data taking was on WGS84 (for example topography, etc.) and the lon/lat values are taken just "as if not on WGS84" (so no conversion takes place) this should give you a region model domain basically on WGS84 - if my thinking is correct...

Take some fixed point lat/lon. If you don´t convert but just get the topography value from a WGS84 dataset, and the land-useage value from a WGS84 data set. Than CCLM will have the right values at the lat/lon, in so far as, that if you later want to compare it a observation data (on WGS84) this will all work out in the end.

But I don´t know what extpar does... or what data you use for forcing...
If the topography is really converted from WGS84 to a sphere and these values are taken, I guess this could lead to a noticable shift for high resolution simulations. See for example: https://doi.org/10.1175/MWR-D-12-00351.1

If you use WebPEP maybe someone more familiar with EXTPAR can comment on how global data was handled there?

Cheer
Rolf

View in channel
<p> Hello Rolf, </p> <p> thanks a lot for your reply. </p> <p> I agree that if all input data (both the external parameter fields ánd the boundary conditions) are specified in WGS84 and the model does not convert any of this to spherical and takes them as is, then all data sources still match and there is not too much to worry about. But for that I would need to get some more information on what happens in EXTPAR and INT2LM. </p> <p> I currently use the CCLM-ready ERA5 data on Levante for my simulations. If it turns out that the data is not converted to spherical, then I can directly compare all my WGS84 data directly to CCLM data, or simply add any WGS84 data field to the initial conditions without any conversions (which we do for our wind farm simulations). </p> <p> I also encountered this publication which indeed highlights this issue. So it's quite important to find out that all data is indeed preprocessed in a consistent way. </p> <p> Can someone shed some light on this? Thanks in advance! </p> <p> Kind regards, <br/> Ruben </p>

  @rubenborgers in #f7348c8

<p> Hello Rolf, </p> <p> thanks a lot for your reply. </p> <p> I agree that if all input data (both the external parameter fields ánd the boundary conditions) are specified in WGS84 and the model does not convert any of this to spherical and takes them as is, then all data sources still match and there is not too much to worry about. But for that I would need to get some more information on what happens in EXTPAR and INT2LM. </p> <p> I currently use the CCLM-ready ERA5 data on Levante for my simulations. If it turns out that the data is not converted to spherical, then I can directly compare all my WGS84 data directly to CCLM data, or simply add any WGS84 data field to the initial conditions without any conversions (which we do for our wind farm simulations). </p> <p> I also encountered this publication which indeed highlights this issue. So it's quite important to find out that all data is indeed preprocessed in a consistent way. </p> <p> Can someone shed some light on this? Thanks in advance! </p> <p> Kind regards, <br/> Ruben </p>
RB replied

Hello Rolf,

thanks a lot for your reply.

I agree that if all input data (both the external parameter fields ánd the boundary conditions) are specified in WGS84 and the model does not convert any of this to spherical and takes them as is, then all data sources still match and there is not too much to worry about. But for that I would need to get some more information on what happens in EXTPAR and INT2LM.

I currently use the CCLM-ready ERA5 data on Levante for my simulations. If it turns out that the data is not converted to spherical, then I can directly compare all my WGS84 data directly to CCLM data, or simply add any WGS84 data field to the initial conditions without any conversions (which we do for our wind farm simulations).

I also encountered this publication which indeed highlights this issue. So it's quite important to find out that all data is indeed preprocessed in a consistent way.

Can someone shed some light on this? Thanks in advance!

Kind regards,
Ruben

View in channel