NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: [idvusers] Isosurface Interpolation

Yep - the 2.3 release fixed the isosurfacing problems we were seeing.

Thanks!!

-kevin.


----- Original Message -----
From: Don Murray <dmurray@xxxxxxxxxxxxxxxx>
Date: Friday, August 17, 2007 2:05 pm
Subject: Re: [idvusers] Isosurface Interpolation
> Hi Kevin-
> 
> Kevin Manross wrote:
> > Thanks for the reply, Don and Stu!
> > 
> > Regarding the "discontinuities", I'll try to get an image for you 
> - I'll 
> > describe them in the meantime.
> 
> That would be good.
> 
> > There are several consistent areas in the vertical where we are 
> seeing a 
> > quasi-stair-step in the isosurface.  Your explanation of 
> normalizing the 
> > radial azimuths may explain this.  I'll install and test the 2.3 
> release 
> > and see if this helps any.
> 
> This sounds like the bug we fixed in the 2.3 release.  Let me know if
> you still see the problem.
> 
> > Is the normalizing of azimuths required, or is it intended for 
> better 
> > efficiency?  The reason I ask ties into my attempt to get the 
> NSSL 
> > netCDF output into the IDV and whether I need to do some of this 
> > normalizing in the netCDF files or whether the IDV will take care 
> of 
> > that for me.
> 
> If you write an netCDF IOSP (which the other support question referred
> to), the IDV will take care of that for you.
> 
> > While on this subject of the NSSL netCDF output, the way we have 
> out 
> > data is Product/ElevationAngle/datafile.netcdf.  So for 
> Reflectivity, it 
> > would look like:
> > 
> > Reflectivity/00.50/20070620-040217.netcdf.gz
> > Reflectivity/01.45/20070620-040255.netcdf.gz
> > Reflectivity/02.40/20070620-040330.netcdf.gz
> > Reflectivity/03.35/20070620-040352.netcdf.gz
> > Reflectivity/04.30/20070620-040412.netcdf.gz
> > Reflectivity/05.25/20070620-040431.netcdf.gz
> > Reflectivity/06.20/20070620-040451.netcdf.gz
> > Reflectivity/07.50/20070620-040511.netcdf.gz
> > Reflectivity/08.70/20070620-040526.netcdf.gz
> > Reflectivity/10.00/20070620-040540.netcdf.gz
> > Reflectivity/12.00/20070620-040554.netcdf.gz
> > Reflectivity/14.00/20070620-040609.netcdf.gz
> > Reflectivity/16.70/20070620-040623.netcdf.gz
> > Reflectivity/19.50/20070620-040637.netcdf.gz
> 
> We'd have to do some work to aggregate these.
> 
> > 
> > With regard to rendering a volume scan, can I give the IDV the 
> top level 
> > directory and have it construct the volume from the subdirectory 
> > structure, or will I need to dump all the elevation angle data 
> into one 
> > file?
> 
> Right now, you would have to dump them in one file, or we'd have
> to figure out how to aggregate them.  The first issue to attack
> is how to get the NSSL format  into the netCDF Radial Data structure
> that the IDV uses.  I'll contact you off the list to discuss that
> further.
> 
> Don
> 
> > Don Murray wrote:
> >> Hi Kevin-
> >>
> >> Kevin L. Manross wrote:
> >>> I have a couple questions regarding isosurfacing in the IDV.  
> We are 
> >>> using it to look at isosurfaces of radar reflectivity and we're 
> >>> noticing several discontinuities in the vertical when viewing 
> Level 
> >>> II data.  Can anyone tell me what type of interpolation is 
> being used 
> >>> for the isosurfacing?  Is this technique something that can be 
> >>> modified via the IDV?  If not, is it possible for a user (me) 
> to 
> >>> write some sort of plugin to change this interpolation?
> >>
> >> When you say discontinuities, what do you mean?  We just fixed a 
> bug>> in the 2.2 release where some of the levels were shifted and 
> it made
> >> for some weird isosurfaces.  Try out the 2.3 release and see if 
> that>> works better for you.
> >>
> >> Since radar sweeps in a volume do not have a standard pattern 
> for the
> >> scans  (e.g. each sweep starts at a different azimuth and the 
> number>> of azimuths may vary by sweep), we normalize the sweeps to 
> a 0-360 set
> >> of azimuths, putting the closest radial to each azimuth in for 
> the data.
> >> This gives us a "rectified" domain which makes the isosurface 
> alogrithm>> work better (but maybe not perfect).  As to the 
> details, it uses the
> >> standard VisAD algorithm, the details of which I'm not sure of.  
> But>> that could be answered by someone on the VisAD list.
> >>
> >>> Also, I've played around a little with the vertical scaling 
> widget 
> >>> and it doesn't seem to have any appreciable effect.  (I changed 
> my 
> >>> vertical scale from 16000m to 20000m.)  When viewing a radar 
> domain, 
> >>> it would be great to have the vertical scale of a storm more 
> >>> proportional to its horizontal scale.
> >>
> >> Stu's response is how I do it - use the Range and Bearing tool to
> >> calculate the width of the box, set the  vertical aspect to 1 and
> >> set the vertical range accordingly.
> >>
> >> Don
> >> *************************************************************
> >> Don Murray                               UCAR Unidata Program
> >> dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
> >> (303) 497-8628                              Boulder, CO 80307
> >> http://www.unidata.ucar.edu/staff/donm
> >> *************************************************************
> >>
> >>
> > 
> 
> -- 
> *************************************************************
> Don Murray                               UCAR Unidata Program
> dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
> (303) 497-8628                              Boulder, CO 80307
> http://www.unidata.ucar.edu/staff/donm
> *************************************************************
> 
> 
> 


  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the idvusers archives: