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
> *************************************************************
> 
> 
>