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