[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[IDV #JSP-708097]: RE: IDV map wrapping issue/scripting query
- Subject: [IDV #JSP-708097]: RE: IDV map wrapping issue/scripting query
- Date: Wed, 15 Jun 2011 14:25:15 -0600
> ACCURACY OF DERIVED OUTPUTS
>
> Hi,
>
> I would like to cut across our previous exchanges with an important
> query:
>
> I have been trialling GrADS for use in out business over the past week.
> So far the support from your side has been brilliant, I am able to
> obtain images of fairly satisfactory quality and my local files are
> readable. However, I am simultaneously looking at other packages from
> other developers as well. I have noted that the outputs obtained from
> IDV are overly simplistic, and I am led to believe that they might not
> be accurate!
>
> Please find a comparison attached: the images with IDV in the naming are
> IDV outputs, while the others are corresponding outputs from another
> tool. The logic is as follows:
>
> 20_850 = 00000020.forecast at 850mb (85000Pa)
> 20_200 = 00000020.forecast at 200mb (20000Pa)
> 28_600 = 00000028.forecast at 600mb (60000Pa)
> 28_100 = 00000028.forecast at 100mb (10000Pa)
>
> and the same for IDV but with _IDV in the nomenclature.
>
> Am I required to select an appropriate range for streamline view? How is
> this done? Currently it is hit and miss, and I am sticking to the range
> auto-specified by the tool?
>
> Do help! The team are hastily deciding to stick with the alternate tool,
> however I would like to get to the bottom of the disparity. Note that
> primary attributes (example contour plots of u-component of wind) are
> quite close between both tools, so it is the derived components that are
> the problematic ones...
>
> Looking forward to your reply,
> Ameen
>
> (I would upload the samples onto the link provided earlier)
>
There are several issues here, first, you were comparing different datasets,
their times are different( the images generated by Grads is June 15 and by IDV
is April 1). Second, if you check the value of u and v in these datasets, they
are in the range of 3000, and the unit is m/s. Either your dataset is
incorrect, or we used the wrong Grib2 table, you may want to do a little more
research on your side first.
Yuan
Ticket Details
===================
Ticket ID: JSP-708097
Department: Support IDV
Priority: Normal
Status: Open