[Met_help] [rt.rap.ucar.edu #65730] History for lag_time

[John Halley Gotway via RT]

----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Just curious what the lag_time parameter does.  Assuming I specify a lag 
of "12", does it add 12 hours to all the bdeck data before pairing them 
with adeck data?

Location isn't touched?
Can you have negative lag?

Thanks!
dave




----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: Re: [rt.rap.ucar.edu #65730] lag_time
From: John Halley Gotway
Time: Wed Mar 05 13:52:54 2014

Hello Dave,

Here's a selection from the METv4.1/data/config/README_TC file:

//
// Specify a comma-separated list of forecast lag times to be used in
HH[MMSS]
// format.  For each ADECK track identified, a lagged track will be
derived
// for each entry listed.
//
// e.g. lag_time = [ "06", "12" ];
//
lag_time = [];

Suppose you have a single ADECK track with a model name "HWRF", and
you have lag_time = [ "06", "12" ] (as shown above).  In the output
you'd see 3 tracks with model names "HWRF", "HWRF_LAG_06", and
"HWRF_LAG_12".  All initialization and valid times for the tracks will
be shifted forward 6 or 12 hours.  This functionality is in MET-TC to
replicate functionality that's in the NHC verification
system.  I talked to a scientist in DTC, and she told me that it's
used when dealing with real-time considerations of running
operationally.  Certain hurricane models are considered "early" or
"late",
meaning they either are or are not available in a certain real-time
time window.  They've used the time lag to shift the times of some
models to switch the between "early" and "late".

Frankly, I don't understand all the details, but its basically a real-
time consideration.  If you're evaluating data in retrospective mode,
it like wouldn't be that helpful.

Can it be negative?  I just tested it and it looks like it works.

Thanks,
John

On 03/05/2014 01:14 PM, David Ahijevych via RT wrote:
>
> Wed Mar 05 13:14:48 2014: Request 65730 was acted upon.
> Transaction: Ticket created by ahijevyc
>         Queue: met_help
>       Subject: lag_time
>         Owner: Nobody
>    Requestors: ahijevyc at ucar.edu
>        Status: new
>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65730 >
>
>
> Just curious what the lag_time parameter does.  Assuming I specify a
lag
> of "12", does it add 12 hours to all the bdeck data before pairing
them
> with adeck data?
>
> Location isn't touched?
> Can you have negative lag?
>
> Thanks!
> dave
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65730] lag_time
From: David Ahijevych
Time: Wed Mar 05 14:47:47 2014

thanks for checking on this. I'm still not sure what it does, but it
sounds like I don't need it when I'm doing a retrospective study.  I
was
just curious if it could "auto-magically" account for temporal errors
somehow, but without understanding it completely, I think I'll stay
away
from it.

Dave



On 3/5/14 1:52 PM, John Halley Gotway via RT wrote:
> Hello Dave,
>
> Here's a selection from the METv4.1/data/config/README_TC file:
>
> //
> // Specify a comma-separated list of forecast lag times to be used
in HH[MMSS]
> // format.  For each ADECK track identified, a lagged track will be
derived
> // for each entry listed.
> //
> // e.g. lag_time = [ "06", "12" ];
> //
> lag_time = [];
>
> Suppose you have a single ADECK track with a model name "HWRF", and
you have lag_time = [ "06", "12" ] (as shown above).  In the output
you'd see 3 tracks with model names "HWRF", "HWRF_LAG_06", and
> "HWRF_LAG_12".  All initialization and valid times for the tracks
will be shifted forward 6 or 12 hours.  This functionality is in MET-
TC to replicate functionality that's in the NHC verification
> system.  I talked to a scientist in DTC, and she told me that it's
used when dealing with real-time considerations of running
operationally.  Certain hurricane models are considered "early" or
"late",
> meaning they either are or are not available in a certain real-time
time window.  They've used the time lag to shift the times of some
models to switch the between "early" and "late".
>
> Frankly, I don't understand all the details, but its basically a
real-time consideration.  If you're evaluating data in retrospective
mode, it like wouldn't be that helpful.
>
> Can it be negative?  I just tested it and it looks like it works.
>
> Thanks,
> John
>
> On 03/05/2014 01:14 PM, David Ahijevych via RT wrote:
>> Wed Mar 05 13:14:48 2014: Request 65730 was acted upon.
>> Transaction: Ticket created by ahijevyc
>>          Queue: met_help
>>        Subject: lag_time
>>          Owner: Nobody
>>     Requestors: ahijevyc at ucar.edu
>>         Status: new
>>    Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65730 >
>>
>>
>> Just curious what the lag_time parameter does.  Assuming I specify
a lag
>> of "12", does it add 12 hours to all the bdeck data before pairing
them
>> with adeck data?
>>
>> Location isn't touched?
>> Can you have negative lag?
>>
>> Thanks!
>> dave
>>
>>


------------------------------------------------