Bob Moore
Date: Thu, 17 Jan 2002 20:41:35 +1100
From: Robert Moore <r.moore@BoM.GOV.AU>
To: g.mills@bom.gov.au
Cc: laps_feedback@bom.gov.au
Subject: Re: LAPS Performance

Last nights LAPS "12Z" (9pm, right?) run was predicting up to 4 deg
cooling at 500 hPa over SE NSW at "06Z" today (really 3pm,OK?) and total
totals of over 50. This didnt eventuate, except maybe in the far SE near
Gabo,  and nor did the storms I put on the southern tablelands forecast.

And when will the prog times on the charts be adjusted to the correct
time?
 
 

Terry Hart

Hello all,

I can't comment on the particular issue about LAPS TT forecasts raised
by Bob Moore. However, in answer to the question:

<<
And when will the prog times on the charts be adjusted to the correct
time?
>>

We are in the process of moving to standard hours of 00, 06,12 and 18
UTC for the numerical analyses (and prognoses). So the times on the
charts are "correct" as they are. These will be the central times of the
+/- 3 hour windows in which data for the respective analysis times will
be grouped. We need to change the base times in the models. I have
spoken to Kamal Puri of the Modelling Group in BMRC and we want to make
the change as soon as possible. The main changes are required in the
LAPS suite. The GASP data is already centred about 00 UTC, etc.

These UTC times are consistent with the observation times of our upper
air network which now operates on fixed UTC times rather than local
time. With a launch time of 2315, .. UTC most of the sonde flight is
actually closer to 00, .. UTC.

I realise that this ambiguity in time is not desirable. I hope we can
get the standardisation complete very soon.

Cheers,

Terry

Elly Spark
Hi Terry,

After reading all the emails regarding Bob Moore's  Very Good Question on the
real time of the model output I am still confused.

I think that what you are telling us is that currently:

A GASP  + 6hrs model output field  based on a "00Z" chart is actually at 06Z
A LAPS or  MESOLAPS  + 6hrs model output field based on a "00Z" chart is
actually at 05Z (3pm EST)  in winter and  04Z (2pm EDT) during daylight saving.

As pointed out by Tony Bannister,  a difference of two hours in interpretation
is not an academic question when you are timing fronts (or thunderstorm
commencement time based on the various diagnostics or decision tree) .

Can you please let me know whether the above interpreation is correct, and if
not, what would the correct one be.

keep smiling

Elly Spark
NSW

Jeff Kepert

Elly (and others, since if one is confused no doubt others are also.)

Firstly, remember there are two ingredients in an analysis - the observations,
and the background or first guess. The analysis at each gridpoint is (roughly
speaking) a weighted average of the background, and the nearby observations. One of the
tricky bits is working out what the weights should be.

Consider a (nominally) 23Z analysis. For GASP, the background is a 6 hr
forecast from the nominally 17Z anal. For LAPS, it is "cold-started" from a GASP
forecast valid at (nominally) 23Z.

The data are taken from a 6 hour window from 21Z to 03Z i.e. not centred on the
nominal time. However, observations at 02Z are clearly less representative of
the flow at 23Z, than observations at 01Z. So they receive a lower weight. In the
context of statistical interpolation, this is done by increasing the error
variance assigned to that observation. In our nominally 23Z analysis, the observations
at 23Z receive the highest weight

So when a data assimilator says "this analysis is valid at 23Z" they mean that
(a)
the background was valid at 23Z and (b) the observations at 23Z received the
highest dweight. Note that part (a) of this definition is circular. Note also that this
definition does NOT change with daylight savings time - even though the time of
some (not all) of the observations does (which is accounted for in the analysis by
changing their weights).

Now, this 23Z analysis I've been describing is what NMOC distribute with the
label "00Z". Yep, they lie to you (sorry, Terry). This seems to be because they're
part of the way to changing to a true 00Z base time, which I'm told will come later
this year.

The question on everybody's lips at this point is probably something like "at
what time is the atmosphere closest to the 23Z analysis". You might call this the
"true" analysis time. In theory, on average, the answer is 23Z. But, suppose for some
reason that there was a lot of data between 21Z and 23Z, and none between 23Z
and 03Z. Then the analysis would probably be closest to the atmosphere at some time
prior to 23Z. Because of this, I contend that there is AN INHERENT UNCERTAINTY
OF AN HOUR OR TWO IN THE "TRUE" TIME OF THE ANALYSIS (and hence the prognoses)
relative to the nominal time. I would also argue strongly that attempts to use the products
to time wind changes etc to a greater accuracy than this uncertainty are perilous.

One way of reducing the problem of asynoptic data (and there's a lot - eg polar
orbitting satellites) is to do more frequent cycles with a narrower data
acceptance window - like 3 hours instead of 6. One problem here is that the error
statistics of the background change - and so far, our experiments with this have had negative
impact. But as the models move to higher spatial resolution, higher time
resolution in the analysis will become necessary.

Hope this makes it all clear.

Terry Hart

Subject: Validity times for NWP systems

Hi Elly and Jeff,

Thanks for your query, Elly, and for the explanation, Jeff.

Jeff has provided a very useful explanation of the time window for
observations around the specific validity time. I think Elly was asking
a more basic question: to what local time does the time given on the
chart refer. Jeff's answer details how a spread of times in the
observations is included in the analysis for a given validity time.

In answer to Elly's question, I meant to say that the time listed on the
chart or in the field is intended to be the validity time, without any
ambiguity or need to adjust for daylight saving time.
i.e an analysis labelled 00 UTC (whether LAPS or GASP, and whether there
is daylight saving or not) means the best estimate of the meteorological
fields at 00 UTC, taking into account all the observations in a time
window (currently +/- 3 hours) in the ways that Jeff Kepert described.

Similarly, the validity times for a forecast are meant to be taken at
face value.

At the moment there is some ambiguity as the model fields are centred at
23 UTC, 05, 11, 17 rather than 00, 06, 12 ,18 UTC. We are trying to
remove that ambiguity. Resolving that requires BMRC to do some testing
and provide some code changes for NMOC to implement. That has been
discussed for some time but it has not yet happened (promises, promises,
Jeff!).

However, those times are also in UTC, so there is no way they could
refer to 04 UTC, etc.

Of course, there will need to be an adjustment from UTC to local time
which will change with daylight saving, etc. However,  our operational
systems have been geared to UTC time for yonks, not local time, so there
is nothing new in that.

I hope that explains it.

Still smiling,

Terry

Terry Hart

Hi Andrew,

Sorry for your mild confusion but you are right to be confused, as there
is indeed some ambiguity at present during this transition period. The
raw model files, as produced by the programs runing on the NEC, still
are labelled as 23, 05, 11,17 UTC so any programs that access these
directly (such as the BMRC 5km LAPS displays operating on the BMRC
server thryp, or Neil Adams display program which operates off the raw
files) will have the label 23, 05, 11,17 UTC.

Those programs which access the real-time database wil read 00, 06,12,18
UTC as the times there have been adjusted from the raw model times in
anticipation that the raw model files will soon be changed to 00, 06, ..
UTC also. This transition period has taken longer than expected and will
be complete soon I hope, but it needs some careful checking as so many
things are linked (GASP boundary files passed to LAPS, data extraction
programs, all the times in name-lists for post-processing programs).

However, when it is all complete (soon, I hope) the model files, the
real-time database and any other associated system will all speak with
one voice - and that will be the hours 00, 06, 12, 18 bas ed on UTC (and
not EST, EDT, GMT,  PST, PMT or anything else).

So I hope that shows the path to having your confusion cleared, even if
it doesn't clear it for the present.

Cheers,

Terry

(P.S. sorry I can't do anything about the raising temperature - it's the
global warming, you know)