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>