Dear openDX/netCDF users,

I followed the recent postings to this list.
The problem might probably be caused due to a misinterpretation of what ncdx 
does:

ncdx requires for all netCDF dimensions (used in variables >1D) the respective 
'coordinate variables', (a coordinate variable is a 1D variable of dimension 
a with the same name as dimension a !)
Example:
        dimensions:
                lat = 7;
                ...
        variables:
                float lat(lat);
                        lat:long_name = "latitude";
                        lat:units=''degrees_north";
                        ...
                ...

        data:
        lat = -90.,-60.,-30.,0.,30.,60.,90.;
If a data-field depends on this (and other) coordinates, ncdx will
add the 'positions' attribute, and create the 'positions' data array using 
this (and other) coordinate variables.


I had a look into your netCDF file:
        float tgrid2(tlat, tlon, axis2) ;
uses 'tlat' as first dimension, however the respective coordinate variable 
containing the position values, i.e.,
        float/int tlat(tlat);
                tlat:.....

        data:
                tlat = ....
is missing.
What are the 'tlat' positions you want to have for tgrid2 ? 
(By the way, I wonder about the output of ncdx when you applied it to your 
original netCDF file ...).

A workaround would be to include into the netCDF file a simple dummy-index 
list as coordinate variable 'tlat' (or better the 'real' values)!

Alternatively, ncdx could be improved in order to check for dimensions without
corresponding 'coordinate variables'. The question is, however, how this 
should be interpreted to be as general as possible ...
(Note that the openDX data model is much more complex than what netCDF can 
usually handle WITHOUT ADDITIONAL CONVENTIONS affecting the variable 
attributes ...)
Any suggestions are very much aprreciated!


Hope this helps a little ...

Sincerely,

           Patrick Jöckel


On Wednesday 28 August 2002 23:26, Gregory D Abram wrote:
> I think Lloyd's right.  I tried to import the tgrid2 variable of the
> smaller dataset and hit the positions problem.
> I did a ncdump on the file, and tgrid2 has a positions attribute of
> "tlat_003_003, product; tlon_003_002, product; axis2_003_001, product;" and
> OpenDX is trying to retrieve an object named tlat_003_003 from netcdf,
> using ncvarid(handle, "tlat_003_003").
> Seems like you might want to get the ncdx guy, [EMAIL PROTECTED],
> to look at it; I don't know if he reads the OpenDX forums.
>
> Greg
>
>
>
>
>                       Lloyd A
>                       Treinish/Watson/[EMAIL PROTECTED]            To:      
> [email protected] Sent by:                             cc:
>                       [EMAIL PROTECTED]        Subject:  Re:
> [opendx-users] Importing Large NetCDF files into son.ibm.com               
>            OpenDX
>
>
>                       08/28/2002 05:04 PM
>                       Please respond to
>                       opendx-users
>
>
>
>
>
>
>
>
>
>
> I've not seen that problem with either OpenDX or non-OpenDX compliant
> netCDFs, from a variety of different sources.
>
> I took a very quick look at your netCDFs.  The array sizes are certainly
> not big, so it's not a memory issue (as reported with ncdump -h).  I've
> used much bigger arrays with netCDF files.  I tried reading it with OpenDX
> 4.2.  The importer didn't crash, but complained that it couldn't find a
> positions variable.  That means that one of your fields has a specification
> for positions pointing to another variable in the file, which Import can't
> find.  I did not go through your netCDF metadata to verify that all of the
> references were there.  But I hope this gives you a clue.
>
>
> [EMAIL PROTECTED]@opendx.watson.ibm.com on 08/28/2002 02:15:16 PM
>
> Please respond to [email protected]
>
> Sent by:    [EMAIL PROTECTED]
>
>
> To:    [email protected]
> cc:
> Subject:    [opendx-users] Importing Large NetCDF files into OpenDX
>
>
>
> I've been trying to import two netCDF files that I ran the ncdx utility on
> in
> order to make them OpenDX compliant.  Each time I've run into a
> segmentation
> fault (signal 11) that disconnects the ui from the executive server.  I
> understand this is a memory problem, but I'm not sure exactly of the
> problem's
> characteristics or how to rectify it.
>
> Can anyone help?  I've made these files (originally generated by HOPs, made
> OpenDX compliant by ncdx) available here:
>
> http://web.mit.edu/revprez/Public/netcdf
>
>  I'd appreciate any insight on my problem.  Peace.

-- 
---------------------------------------------------------------
Dr. Patrick Joeckel
Max Planck Institute for Chemistry
Joh.-J. Becher Weg 27         
55128 Mainz                   phone:++49-6131-305452      
Germany                       fax  :++49-6131-305436     
                             e-mail:[EMAIL PROTECTED]
                         http://www.mpch-mainz.mpg.de/~joeckel
---------------------------------------------------------------
Never trust an operating system you don't have sources for.

Reply via email to