[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AURAMS and GEM files in IDV and VERDI.



Hi Todd:

I inverted the y coords, and the file seems to display corectly in CDM stack. 
Im not clear if VERDI uses the CDM stack, but i think it does. can you check if 
it now works? If so, then fixing the converter seems like the right thing to so.

John

On 10/8/2010 12:26 PM, address@hidden wrote:
Let me see if I can summarize the issue...

1) AURAMS and GEM produce files that are natively not in netCDF format
2) A converter program is used to convert the AURAMS and GEM files from their 
native format to netCDF.
3) The resulting file has a grid cell numbering system that is upside down 
compared to CMAQ grids (I'm not sure how other model grids such as those in the 
AQMEII are numbered) so that for example


.
.

4) Because CF doesn't care what order the grids are in, Todd needed to put 
additional code in VERDI to invert the AURAMS/GEM numbering to match the CMAQ 
numbering so the various VERDI features would work. NCView doesn't have this 
adjustment so the AURAMS/GEM files do not plot correctly with that package.

5) The questions now seem to be

a) Is inverting the grid numbering in VERDI the best way to handle this? I am 
wondering if there would be advantages to modifying the code that converts the 
AURAMS/GEM files to netcdf to number the grid so they could be used by VERDI or 
NCView. Would there be advantages to that for intermodel comparisons like 
AQMEII or is CMAQ the odd man out? What grid cell numbering system do the 
Europeans use?

b) Are the lat-lons in the AURAMS/GEM file self-consistent (i.e. the projected 
values for the grid cells matches what is in the file). I think the answer to 
this one is yes with the revised files that Junhua sent out.

c) Apparently longitude in AURAMS/GEM is 0 to 360 rather than -180 to 180. Todd 
has put in a workaround for this. I'm not sure how this affects viewing the 
files in NCview.

6) In the short term, we have a work around for VERDI and can display the 
AURAMS/GEM files. I'm not sure that all of the features (e.g. probing, stats, 
etc are all working correctly for the inverted numbering)

Please let me know if I missed something or mischaracterized something.

Donna

=================================
Donna B. Schwede

Atmospheric Modeling and Analysis Division
National Exposure Research Laboratory
U.S. Environmental Protection Agency
Mail Drop E243-02
Research Triangle Park, NC 27711

Phone: 919-541-3255
Fax: 919-541-1379
e-mail: address@hidden


From:   john caron <address@hidden>
To:     Todd Plessel/RTP/USEPA/US@EPA
Cc:     "Zhang,Junhua [Ontario]" <address@hidden>, Donna Schwede/RTP/USEPA/US@EPA, "Moran,Mike 
[Ontario]" <address@hidden>, "He, Qun" <address@hidden>
Date:   10/08/2010 01:57 PM
Subject:        Re: AURAMS and GEM files in IDV and VERDI.


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---



Hi Todd:

I havent been able to investigate this fully (im not in my office with
source code), but CF and the CDM stack dont care if its bottom up or top
down, however the x,y coordinates must be correctly encoded, and im
guessing thats the problem (it usually is).

Ill try to give you a more definitive answer next week.

John

On 10/8/2010 10:45 AM, address@hidden wrote:
 > Hi John,
 >
 > Nevermind the After_conversion.ncf file that was attached since
 > Junhua as replaced the invalid/inconsistent After_conversion.ncf
 > with a self-consistent version of After_conversion.ncf that works.
 >
 > That is, for a given grid cell, e.g., (column = 1, row = 1)
 > the projected coordinates (xc = 0, yc = 4410000 ) project to and match
 > the stored lon-lats for that cell (lon = 228.4346 - 360 = -131.5654 ,
 > lat = 51.64661 ).
 > The corrected file After_conversion.ncf is displayed correctly, like
 > GEM/AURAMS,
 > only because of the HACK in FastTilePlot that detects this 'upside down'
 > row order
 > invertRows = firstYValue> lastYValue;
 > and then adjusts the row indexing:
 > final int dataRow = ! invertRows ? row : rows - 1 - row;
 >
 > My preference would be to remove that hack so that all gridded data
 > would have a bottom-up/south-to-north row order.
 > This means moving the hack upstream into CF1Convention.java and having
 > it
 > ensure that the data (lats, and other data variables) are in
 > globally-consistent bottom-up row order, reordering it if needed
 > (i.e., if yc(1)> yc(rows)).
 >
 > If you decide to make that change to CF1Convention.java then
 > I can remove the hack in FastTilePlot, otherwise it must remain.
 > (Qun: note probing lon-lat still reports the wrong lat for upside-down
 > grids
 > such as GEM/AURAMS/After_conversion because that code - wherever it is -
 > does not use the invertRows hack. You see why it is better to move that
 > hack
 > upstream than to propagate it further downstream?)
 >
 > Todd



Attachment: flipped.jpg
Description: JPEG image

<?xml version="1.0" encoding="UTF-8"?>
<netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2"; 
location="H:/After_conversion.nc">
  <variable name="yc">
    <attribute name="scale_factor" type="float" value="-1.0" />
    <attribute name="add_offset" type="float" value="1116000.0" />
  </variable>
</netcdf>