Re: Re: Native Grid projection

Malcolm,

I will attempt to answer at least some of your questions. The
comments are interspersed.
On Nov 11, 2008, at 12:30 PM, malmistry_at_indiatimes.com wrote:

> Dear Mary,
> Many thanks for your prompt reply. I appreciate your detail
> explanation. My remarks are between your comments.
>
>> However, I do see that you have some knowledge of the projection,
>> even
>> thought this didn't appear to be in complete form on your file, so
>> maybe this
>> is not an idealized case? Where did this file come from?
>
> The source of this file is WRF-NMM (E grid). It is not an idealized
> case, but the WRF expert (Wei Huang, Thank you!!) made me do a
> little research and I found this.
>
> (a) Pages (23-30) on http://www.mmm.ucar.edu/wrf/users/tutorial/
> 200807/NMM_Dynamics_jul2008_FINAL.pdf
>
>> Just a couple more things that Dave Brown mentioned after I sent
>> the last message. - MAP_PROJ = 203
>> this looks like it might be coming from a WRF-GRIB file?
>
> I doubt that (but once again, thank you for making me do more
> research on this). I do know that this is a Rotated Lat-Lon (from
> the above PDF link). Also, you will find more info on "MAP_PROJ",
> on the below two links (by just searching for "MAP_PROJ" or
> "Rotated" on these pages).

Actually what I was trying to say is not that the data was coming
from a WRF-GRIB file but simply that the specification of the
MAP_PROJ as 203 is more than
a coincidence: the definition of GRIB GDS grid 203 is "Arakawa semi-
staggered E-grid on rotated latitude/longitude grid-point array (2-
dimensional)" and as
the citation you list above states, the WRF-NMM grid is "The Arakawa
E-grid stagger".

>
> http://www.dtcenter.org/wrf-nmm/users/docs/user_guide/WPS/
> users_guide_nmm_chap5_v1_WPS.htm
> http://www.dtcenter.org/wrf-nmm/users/docs/user_guide/SI/
> users_guide_nmm_chap3_SI.php
>
> IMP!! -------The WRF parent file has a lot of variables. So I did
> 'ncks' on that to extract only 'TH10' variable (and send it in my
> previous mail). However, the parent file actually also contains
> GLAT & GLON (variables) which are not exactly the geographic lat/lon.
>
> I am trying to check how to convert that to geographic lat/long.
> The problem is that it is quite an awkward grid and as you
> correctly said, to plot it as "Native", more precise information
> would be required.
>
>> - If you indeed have a rotated lat/lon grid, you want to set
>> mpCenterLatF and mpCenterLonF (you currently have
>> them commented out), and *not* mpCenterRotF:
>
>> res_at_mpCenterLonF = 6.0 ; center lon
>> res_at_mpCenterLatF = 42.5 ; center lat
>> ; res_at_mpCenterRotF = 6.0
>
> I tried this as follows:
> ---------------------------------------
> ; res_at_mpCenterRotF = 6.0
> ; res_at_mpRelativeCenterLon = True
> res_at_mpCenterLonF = 6.0
> ; res_at_mpRelativeCenterLat = True
> res_at_mpCenterLatF = 42.5
> ----------------------------------------
>
> The plot still looks the same (with the same shift). If I use
> "res_at_mpRelativeCenterLatF = True" & "res_at_mpRelativeCenterLonF =
> True", the plot doesn't look correct. Hence I have commented them
> as I did not quite understand what purpose they serve exactly.
>
>> - You still need to get your map limits correct. Dave and I both
>> think this is where the problem is most likely arising. You
>> may have to do this by trial and error, if you don't have any
>> further information about the correct values.
>
> Absolutely! I too believe that the issue here is to define that
> correctly. At present I have used the info from global attributes
> to do simple math & calculate the corners of the grid domain (which
> may not be precise). But once I figure out the conversion of GLAT/
> GLON (variables) to geogphraphic lat/long (for a flat map), then I
> think I could try using the other method to plot, i.e the normal
> method using "res_at_sfXArray = glon , res_at_sfYArray = glat". This is
> also what you suggested in your email (3 Methods to plot).
>
> I have plotted this file in Ferret too and I can see the same
> shift! So I have more reasons to believe that NCL is doing what it
> is being told to do. The problem (as you suggested) is to know more
> about the model projection and coordinates. I will try to plot/
> compare more variables (such as SEA-MASK, which should give a
> better picture of any shift). The variable TH-10 is temperature and
> may actually (could) have a shift.
>
> Lastly, I have 2 QUESTIONS.
>
> (a) res_at_mpProjection = "CylindricalEquidistant". I checked the
> res_at_mpProjection and found other projections...but there's nothing
> like "Rotated Lat-lon". From an earlier query, I found Dennis's
> reply that usually "Cylindrical Equidistant" is the same as
> "Rotated Lat-Lon"

In fact, there is no "rotated lat-lon" projection in NCL because
rotated lat-lon is simply a cylindrical equidistant projection with
mpCenterLonF and (especially) mpCenterLatF
set to non-zero values. The difficulty is that usually the lat/lon
coordinates of such grids are given in the rotated frame of
reference. It requires some trigonometry to convert
these into un-rotated coordinates, but this is necessary to plot such
grids using NCL. We don't yet have a function to do this calculation,
but it should become a priority
to add one. Also note that coordinates that can be expressed in the
rotated system using a single-dimensioned vector or simply as start,
step size, and number of grid points,
need 2D lat and lon coordinate arrays to be specified in the
unrotated system.

And additionally note that you would only need to convert the grid
corners from rotated to un-rotated in order to do the "native" grid
plot.

>
> (b) WRF-NCL processing scripts are incorporated into the NCL
> Libraries. Do you know of any example that could be closely related
> to my script/netcdf file?
>
> I will soon have another file based on a similar projection for
> regional domain (over western Europe), but "UMO Model, 'B' Grid.
> Hence I was testing my script with this WRF file.

Someone else will need to answer this question.

>
> Before I end my email, I would like to thank you all for doing a
> wonderful job (as support team). Not only your responses are
> prompt, they are also precise and with loads of examples.
>
> Best regards
> Malcolm
> (Barcelona Supercomputing Center)
>
> ----- Original Message ----------------------------
> From: Mary Haley <haley_at_ucar.edu>
> To: malmistry_at_indiatimes.com
> Cc: ncl-talk_at_ucar.edu
> Sent: Mon, 10 Nov 2008 23:05:00 +0530 (IST)
> Subject: Re: Native Grid projection
>
> Malcolm,
>
> Just a couple more things that Dave Brown mentioned after I sent the
> last message.
>
> - MAP_PROJ = 203 --> this looks like it might be coming from a
> WRF-GRIB file?
>
> - If you indeed have a rotated lat/lon grid, you want to set
> mpCenterLatF and mpCenterLonF (you currently have
> them commented out), and *not* mpCenterRotF:
>
> res_at_mpCenterLonF = 6.0 ; center lon
> res_at_mpCenterLatF = 42.5 ; center lat
> ; res_at_mpCenterRotF = 6.0
>
> - You still need to get your map limits correct. Dave and I both
> think this is where the problem is most likely arising. You
> may have to do this by trial and error, if you don't have any
> further information about the correct values.
>
> --Mary
>
>
> On Mon, 10 Nov 2008, Mary Haley wrote:
>
>> On Mon, 10 Nov 2008 malmistry_at_indiatimes.com wrote:
>>
>>> Dear Ncl users,
>>>
>>> I am a bit confused about Native grid projection (and after
>>> looking at
>>> the examples on NCL scripts, even a bit more).
>>>
>>> My doubts are in two parts. Part 1: in general on native proj.
>>> Part 2:
>>> specific to my script
>>
>> Dear Malcolm,
>>
>> I've included a long explanation below, for the benefit of other
>> users
>> who also have confusion with native projections.
>>
>> After reading over your email, looking at your file, and talking to a
>> WRF expert here (Wei Huang), Wei suggested that maybe you have
>> idealized data, which is not meant to be plotted on a map. Your file
>> doesn't appear to contain useful map projection information, *and* it
>> doesn't include any lat/lon values, so there's no way to know
>> where on
>> the map to put the data.
>>
>> However, I do see that you have some knowledge of the projection,
>> even
>> thought this didn't appear to be in complete form on your file, so
>> maybe this
>> is not an idealized case? Where did this file come from?
>>
>> Please read further for more information.
>>
>>> --------------------PART 1-------------------------
>>>
>>> (a) On http://www.ncl.ucar.edu/Applications/list_maps.shtml , there
>>> are a few projections defined and then there is Native projection.
>>
>> Just to be clear, the "native" projection is not a map
>> projection. It
>> just means that your data was defined on some specific map
>> projection,
>> like lambert conformal, and hence is native to that projection.
>>
>>> Suppose I have a model output file based on a certain UNKNOWN
>>> projection, with no coordinate variables eg. variable Temp is
>>> (z,y,x);
>>> where x/y are NOT lon/lat but model x/y grid points from 1 to
>>> 550. Would this be regarded as a Native grid projection?
>>
>> There's not enough information to answer this question.
>>
>> In order to correctly overlay data on a map, you need to have one of
>> these three bits of information:
>>
>> 1. You need to have one-dimensional lat/lon coordinate arrays.
>>
>> 2. You need to have two-dimensional lat/lon arrays that represent
>> the lat/lon locations of your data array.
>>
>> 3. If you don't have #1 or #2, then you need to know the *exact* map
>> projection your data was measured on. This constitutes a native
>> projection.
>>
>> It is possible to have both lat/lon arrays *and* to have a native
>> projection information. This allows you to put your data on a
>> different map projection than your native projection, if desired.
>>
>>> (b) If I define "res_at_tfDoNDCOverlay = True", it effectively means
>>> that my model projection is used without any transformation. Then
>>> do I
>>> still need to specify "res_at_mpProjection =
>>> CylindricalEquidistant/Lambert/..." ? If yes, then wouldn't this
>>> cause
>>> a conflict with "res_at_tfDoNDCOverlay = True"
>>
>> If you set "res_at_tfDoNDCOverlay = True", then you are indicating to
>> NCL
>> that you have data on a native projection. Hence you *must* set
>> mpProjection and other map resources in order to define the exact map
>> projection and location your data was measured on. NCL can not
>> magically figure out from your data what map projection was used.
>>
>>> (c) If my projection is native and "res_at_tfDoNDCOverlay = True", what
>>> purpose does "res_at_mpLimitMode = LatLon/Corner" serve? I understand
>>> that this is just a way to zoom in. But your tutorial says that
>>> if it
>>> is Native projection, then "res_at_mpLimitMode = Corner" (ALWAYS!!).
>>
>> The documentation is misleading here. The mpLimitMode resource
>> doesn't
>> necessarily have to be set to "corners", but this is a common
>> setting.
>>
>> However, again, for a native projection, you must know the projection
>> and the location on the map of your data, so you will need to set
>> "mpProjection" (or use one of the specific map projection functions
>> like gsn_csm_contour_map_ce), *and* you will most likely need to set
>> "mpLimitMode" and associated resources to indicate the location on
>> the
>> globe of your data. In addition, in order to get the right
>> orientation, you might need to set other resources, like mpCenterLonF
>> or mpCenterLatF.
>>
>> This is why it's important that you know the exact map projection
>> that your data was measured on. Usually, this information comes with
>> the data file that your data is on, like global attributes
>> on the file. This is certainly the case for WRF data files.
>>
>> If you look at the global attributes on your WRF file, you'll see
>> values like:
>>
>> MAP_PROJ : 203
>> CEN_LAT : 42.5
>> CEN_LON : 6
>> TRUELAT1 : 1e+20
>> TRUELAT2 : 1e+20
>>
>> These usually indicate map projection parameters, but the
>> MAP_PROJ=203
>> looks wrong to me. Also, TRUELAT1 and TRUELAT2 are missing.
>>
>> I don't know enough about WRF files to know what the values above
>> mean, but I don't think you don't have enough information on this
>> file
>> to determine how to correctly overlay your data on a map.
>>
>>> (d) Is "res_at_gsnAddCyclic = False" absolutely necessary for regional
>>> data files ?
>>
>> It doesn't hurt to set it if you have regional data. It just tells
>> NCL
>> not to try to add a wrap-around point in the longitude direction,
>> which you definitely don't want for regional data. However, NCL can
>> sometimes figure this out on its own. It just depends on the
>> nature of
>> your data. You can try not setting this resource, and if things look
>> really bad or you get a warning that you might need to set it, then
>> go ahead and set it.
>>
>> I don't think this resource is the source of your problem here,
>> though.
>>
>>> --------------------PART 2-------------------------
>>>
>>> Attached is my WRF output (.nc) file. It is Regional data based on
>>> Rotated Lat-Lon (I assume the same as Cylindrical Equidistant
>>> Projection). The center (origin) is shifted to 42 deg N, 6 deg
>>> E. Below is my NCL script defining the Limit window using LatLon
>>> method and also giving a rotation of 6 deg (as the shifted pole
>>> would
>>> be 6.0 deg E)
>>
>> Given that you know all this information, I'm a bit confused
>> by the WRF file you included, as it doesn't have what looks to
>> be complete map information.
>>
>>> Since there are no coordinate variables, I assume it is a Native
>>> Grid
>>> issue. By doing ncdump on the file, I have used the additional
>>> info to
>>> write the script (attached).
>>
>> That's usually a safe assumption, especially given that it's a WRF
>> file. But again, you would then expect to see other information
>> on the file about the map projection used.
>>
>>> I have compared the plot with NCView and I can definitely say
>>> that the
>>> plot shifts a little (this is easily evident by looking at Italy
>>> where
>>> the contour should be within the boundary).
>>>
>>> I have tried different things (such as using different
>>> LimitMode). The
>>> mpMinLatF / mpMinLonF etc are calculated using the grid spacing &
>>> the
>>> center of domain (42.5 deg N, 6.0 deg E) which is the shifted
>>> origin. This should mean that the shifted pole is 6.0 deg E.
>>>
>>
>> I think the problem is that you are close to getting the right
>> map projection, but you to be *exact* on this in order for it to
>> look right.
>> You probably have the mpCenterLatF and mpCenterRotF
>> resources set correctly, but I'm thinking that you may need
>> to check your values for the lat/lon corners.
>>
>> Try tweaking these values, or else try find some more information
>> that would tell you exactly what they need to be.
>>
>>> (e) Is it necessary to know the exact origin / pole etc if this is a
>>> native projection?
>>
>> Yes.
>>
>> --Mary
>>
>>
>>> Am not sure why the plot is still not correct. Hoping to understand
>>> this better....Thanks in advance.
>>>
>>> Malcolm
>>> (Barcelona Supercomputing Center)
>>>
>>>
>>> --
>>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>>> ZigWheels.com
>>> http://www.zigwheels.com/b2cam/newsDetails.action?
>>> name=Emb11_20080731&path=/INDT/News/
>>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=foot
>>> er&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>>>
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
>
>
>
> --
> Hyundai to launch the i20 in India. Catch the exclusive preview on
> ZigWheels.com
> http://www.zigwheels.com/b2cam/newsDetails.action?
> name=Emb11_20080731&path=/INDT/News/
> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer
> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>
>
>
> --
> Hyundai to launch the i20 in India. Catch the exclusive preview on
> ZigWheels.com
> http://www.zigwheels.com/b2cam/newsDetails.action?
> name=Emb11_20080731&path=/INDT/News/
> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer
> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>
>
>
> --
> Hyundai to launch the i20 in India. Catch the exclusive preview on
> ZigWheels.com
> http://www.zigwheels.com/b2cam/newsDetails.action?
> name=Emb11_20080731&path=/INDT/News/
> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer
> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Tue Nov 11 2008 - 14:29:44 MST