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