24 January 2002:  Monsoon trough / Quikscat question
Ensuing discussion on numerical forecasts of mid-level tropical steering flow

From: Andrew Tupper

Two quickies:

1) Lots of numerical models (they travel in packs) are going for the
westerly winds to the north of the weak monsoon trough in the Arafura Sea
to deepen to 500 hPa or thereabouts over the next few days.  There is some
variation in the strength of the flow to the south; for example GASP
develops roaring southeasterlies in the middle levels south of the trough
(probably overdone as is often the case).

2) Question for the modellers: how is Quikscat data treated at the
moment?  Are the data treated as being 'observations', or regarded as
somewhat more suspect because of the heavy reliance on numerical input when
deriving the winds?

Today's QLD forecast policy has a lovely comment on Quikscat.

Andrew Tupper,
NT Regional Forecasting Centre

Terry Hart

Hi Andrew,

A quick response to the second of your quickies. At the moment none of
the Bureau's operational models use Quikscat data at present. Jeff
Kepert from BMRC is working on how best to assimilate the data. Some
information is used indirectly through the PAOBs as the manual analysts
in NMOC have Quikscat data as part of the display in their analysis.

I am not sure what the status is at the other centres. I know that ECMWF
were testing Quikscat data late last year. I don't know whether they
have included it in their operational system yet.

If they are used they will be treated as other observations are in the
analysis systems with an assigned observational error based on past
experience in analysing such data and they have to pass the data quality
checking procedures (such as gross error checks, consistency with
neighbouring observations and deviation from the first guess). The
assigned observational error determines how much weight is given to the
observation, relative to the first guess field and other observations in
the area.

I would be interested to hear of systematic errors in our models along
the lines of what you suggested about GASP.

Cheers,

Terry

Andrew Tupper

Hi Terry,

Thanks for your response.

Just to amplify my comments: the longest period we forecast for for Darwin
is 4 and a half days (so, our forecast issued today extends to Monday
evening).  As everybody knows, there is not a great deal of variation that
can be forecast usually for Darwin, and the variations that do occur
(monsoon onset, dry season surge, tropical cyclone passage, etc) are rather
hard to pick.  One of the greatest determinants of 'ordinary' weather is
the strength of the middle level 'steering' flow to assess the different
convection types that may occur (squall lines as opposed to 'random'
convection), and to assess dry air transport from further
inland.  Unfortunately, model performance is generally not good.  For
example, here are the current 700 hPa predictions for Darwin from Friday
onwards:

 
     EC GASP TLAPS UK NCEP
12Z Friday   E 20 kt   SE 25 kt      SE 15 kt  ESE 25 kt  E 30 kt 
12Z Saturday    E 10 kt SE 10 kt     E 15 kt    E 15 kt 
12Z Sunday  ESE 10 kt       ESE 15 kt     E 10 kt 
12Z Monday  E 5 kt           ESE 20 kt   E 15 kt 
12Z Tuesday    E 25 kt 

(This is based on what I can get through Kenny, McIDAS and the Antarctic
Numerical Model Display System)

Past experience suggests that GASP and NCEP are usually over-enthusiastic
with the strength of the 700 hPa ridge, and hence the strength of the winds
over Darwin  (Having said that, I'm sure they'll be right this time
:-)).  Anyway, the spread of values, particularly for Friday and Monday,
means that we have very little idea of what the winds will actually be, so
our forecast will have little (if any) skill over persistence.

Jeff Kepert

Andrew,

The phrase that Quickscat data is "more suspect because of the heavy reliance
on numerical input " is putting it a bit strongly.

Scatterometer winds have between two and four "ambiguities", depending on
antenna geometry, position in swath, wind direction, etc. Each has a
probability associated with it as part of the retrieval process, and typically
two of the ambiguities are more likely than the others, and are about 180
degrees apart in direction. This is because the small waves the radar measures
look pretty much the same from the front or back.

If the radar observations were free of error, and our knowledge of the physics
of Bragg scattering off these small waves and of the atmospheric surface layer
were exact, the most probable solution would be the true wind. Although the
other ambiguities would still exist, we could select the most probable, go home
and be happy. Unfortunately, none of these apply in reality.

Usually, some type of "buddy check" is used to help select the ambiguities -
i.e. a spatially smooth field is aimed for. The difficulty is that, just as
adjacent bits of the atmosphere tend to have similar winds, adjacent cells in a
scat swath tend to have similar ambiguities. So if you select the wrong wind in
one cell, the adjacent cells will tend to have similar ambiguities of similar
probability, and you get a large block of winds all in the wrong direction.
(This can often be seen near the centre of tropical cyclones, where the large
gradients in wind direction, along with rain contamination of the data, make
the problem more difficult. The giveaway in this case is that the bad winds are
all across the swath).
Since selecting the first cell wrong can mess up a big patch, it is common to
use NWP analyses to help make this first choice. But the bulk of the selections
are made based on spatial continuity, and solution probability - comparison
with NWP is used sparingly and people are working on eliminating it altogether.

When the data is assimilated into an nwp system, it is subject to the same
quality control as all the other observations - that is, checks against the
first guess, and against other nearby observations (including of other types).
If it disagrees by too much, it gets omitted from the final analysis. But this
happens AFTER the processing that produces the scat winds you download off the
web, or from the Bureau's real-time data base. This quality control may also
consider rain flags, probabilities and other quality indicators from the
retrieval, and may decide to use a different ambiguity to the one initially
selected. At the moment, we are assimilating scat data in test mode in BMRC,
but not in any of the operational products. However, our results are positive
and this should be one of a bunch of improvements to make it into operations in
the not too distant future. I gave a seminar on this last year - a pdf of the
powerpoint was on the internal web but seems to have gone. Anyone who's
interested let me know and I'll email it to you.

Some rules of thumb for helping pick bad data ... (i) heavy rain is bad (ii)
the edge 7 cells on the quickscat swath only have 2 radar measurements instead
of 4 so cannot resolve the ambiguity by themselves even if the measurements
were perfect (iii) the edges and centre of the quickscat swath have less
"azimuthal diversity" of radar beam so are less reliable.

Jeff Kepert
BMRC Data Assimilation Group