[IDV #FDK-698636]: IDV v. Panoply OPeNDAP access

> First, let me stipulate that I know IDV does many things Panoply doesn't, and 
> I use and proselytize it regularly.  But lately i have run into a couple 
> discrepancies where Panoply can handle data through OPeNDAP that IDV 
> struggles with due to performance reasons.  I wonder if there is anything you 
> can do to catch up...
> 
> Case #1:  MODIS Level 3 data in OPeNDAP, hyrax variety (please do not 
> advertise this URL, though, it is intended primarily for machine use by our 
> Giovanni app):
> 
> http://disc1.gsfc.nasa.gov/opendap/Aqua_MODIS_Level3/MYD08_D3.051/2011/MYD08_D3.A2011001.051.2011005093254.pscs_000500527176.hdf
> 
> This is a very large file with many, many variables.  That said, Panoply 
> takes about 20-25 seconds to inventory the variables in the file, and another 
> 5-10 secs to display one.  IDV takes ~6 minutes to inventory the data file on 
> a MacBook Pro, but then about the same time as Panoply to display one 
> variable. (BTW, this is actually a subset of the original MODIS L3 file, 
> which is even larger!)
> 


I tried this url and it took about 15 seconds, so it really depends on the 
network traffic and loads of the server.


> Case #2 Merged IR in OPeNDAP of the GrADS Data Server (GDS) variety: 
> http://disc2.nascom.nasa.gov:80/dods/MergedIR
> 
> GDS presents the whole dataset as one huge "file".  Panoply can display this 
> after a few minutes of churning; however IDV eventually errors out after 
> several minutes with a message about Java heap space.
> 
> Case #2 would be more useful for us to get fixed--we had a user asking us how 
> to read the Merged IR through IDV.
> 
> Anything you can do?

My IDV has 4G memory, and it has no problem to load the data. So the solution 
for your user is to increase the memory.



Yuan
> --
> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
> 
> 
> 


Ticket Details
===================
Ticket ID: FDK-698636
Department: Support IDV
Priority: Normal
Status: Open