Re: New Client Reply - [Support !VFJ-268452]: With level 2 or 3 radar as the time driver, matching other layers with lower frequencies can lead to issues. [2032]

Sent from my iPhone

> On Apr 30, 2015, at 9:28 AM, McIDAS Help Desk <address@hidden> wrote:
> 
> New Client Reply: With level 2 or 3 radar as the time driver, matching other 
> layers with lower frequencies can lead to issues. [2032]
> 
> Hi Yuan -
> 
> I'm not concerned with the 16:00 time being picked for the satellite 
> times, that makes sense to me.
> 
> What doesn't make sense to me is the extra timestep added to the loop 
> after matching the time driver.  If I set a loop of 5 Radar times to be 
> the time driver and then match satellite to those times, I would expect 
> there to still be 5 timesteps in the loop, not 6
Bob,
If you want to keep 5  time steps you can use animation widget to set the 
driver. I don't think this is a  bug and I can explain to you in our next tel 
conf..

Yuan
> 
> I'm going to be out of the office next week.  If this requires more 
> discussion, my email is cc'd that I'll be checking periodically next 
> week, as well as Jon Beavers who is aware of this problem.
> 
> Thanks -
> Bob
> 
> On 4/28/2015 5:59 PM, Unidata IDV Support wrote:
>>> Hello -
>>> 
>>> I found a bug in the IDV and McV where matching satellite times to a radar 
>>> time driver can cause an extra time step to be prepended to the loop that 
>>> only has the satellite data.  I've seen this problem also with matching 
>>> point and gridded data to radar as well.  We have set Jon Beavers as the 
>>> SSEC contact for this inquiry.
>>> 
>>> Thanks -
>>> Bob Carp
>> Bob,
>>      This may or may not consider as a bug. By design, when there is nothing 
>> match the latest one will be selected.  If you don't like this you can use 
>> the animation widget to set the driver and then the satellite image display 
>> probably will not show in the loop.
>> 
>> 
>> Yuan
>>> ----==== Inquiry ====----
>>> 2032
>>> 
>>> ----==== Summary ====----
>>> With level 2 or 3 radar as the time driver, matching other layers with 
>>> lower frequencies can lead to issues.
>>> 
>>> ----==== Request ====----
>>> 2015-04-28 - Bob Carp
>>> Just following up on this one.  I'm having a hard time right now 
>>> replicating the bug in Request 1 with matching point data to radar... but I 
>>> can replicate the problem when matching satellite to the radar data in both 
>>> McV and the IDV.
>>> 
>>> 1. Add the 5 most recent Level 2 radar images from a site (I used KMLB on 
>>> the east coast of Florida).  Select the 'Reflectivity' field, in the Times 
>>> tab choose 'Set As Time Driver' and click Create Display.  Here, there are 
>>> 5 time steps in the Time Animation Widget that all match the radar times:
>>>> 20:26, 20:30, 20:33, 20:36, 20:39
>>> 
>>> 2. In the Satellite>Imagery chooser, select adde.ucar.edu/RTIMAGES/GE-VIS, 
>>> check 'Match Time Driver' and click Add Source.  Display the Brightness 
>>> field.  Here, there at 6 time steps in the Time Animation Widget... the 
>>> radar times and one time with just the satellite data prepended to the loop:
>>>> 20:15, 20:26, 20:30, 20:33, 20:36, 20:39
>>> 
>>> 2015-04-27 - Bob Carp
>>> Set L2 or L3 radar data as the time driver and match a layer with a lower 
>>> temporal frequency (e.g., Satellite, Grid, Point).  This prepends an extra 
>>> step to the loop that only has the matched layer, not the driver layer (the 
>>> radar).  For example:
>>> 
>>> The initial display of 5 most recent L2 radar uses timesteps of:
>>> 16:07, 16:11, 16:15, 16:20, 16:24
>>> 
>>> Add in point to match, and things are off (6 timesteps in the loop)
>>> xx:xx  16:07, 16:11, 16:15, 16:20, 16:24 (Radar)
>>> 16:00, 16:00, 16:00, 16:00, 16:00, 16:00 (Point)
>>> ... the first timestep only has the point data, not any radar.
>>> 
>>> This is also a problem in the IDV.
>>> 
>>> This DOES work if satellite is set as the driver and point is matched:
>>> Satellite:   15:15, 15:45, 16:00, 16:15, 16:30
>>> Match Point: 15:00, 16:00, 16:00, 16:00, xx:xx
>>> ... the last xx:xx is because the 17:00 observations aren't in yet, so 
>>> there is nothing to match with the 16:30 satellite time.  If this behaved 
>>> like the radar example, I would expect an extra 15:00 timestep with only 
>>> the point.
>>> 
>>> 
>>> ################################################################################
>>> 
>>> http://mcidas.ssec.wisc.edu/inquiry-v/index.php?inquiry=2032
>> 
>> Ticket Details
>> ===================
>> Ticket ID: VFJ-268452
>> Department: Support IDV
>> Priority: Normal
>> Status: Closed
> 
> 
> 
> Ticket Details
> ===================
> Ticket ID: VFJ-268452
> Department: Support IDV
> Priority: Normal
> Status: Open
> Link:  
> https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=25538
>