[Cosmic_announce] (no subject)

[Sean Healy]

Offiler, Dave wrote:
> Hi Doug,
>> Recently it was found (thanks to Christian Marquardt from EUMETSAT)
>> that the filtering used in our inversion software produces a bias
>> in retrieved bending angles. This bias is seen mainly above 10-20km
>> and its magnitude is of order of 0.1-0.2%. This bias is due to second
>> derivative of the excess phase as a function of time. This bias
>> propagates into the retrieved refractivity and, subsequently, into
>> other retrieved profiles. We will be replacing the filtering which
>> reduces the bias by several decimal orders of magnitude.
>>
>> Concurrently we will be making another change by fixing the transition
>> height between geometric optics and radio holographic processings
>> to ~20 km (currently this height is determined individually for each
>> occultation and can be anywhere between ~10 and ~20 km). The purpose
>> of this change is to aid studies of the structure of tropopause by
>> providing the vertical resolution of about ~0.1 km below 20 km for
>> all occultations.
>>
>> Both these changes are not yet included in our real time processing.
>> The data, BUFR files for November-December 2008, processed with
>> these changes are available at:
>>
>> http://www.cosmic.ucar.edu/~dhunt/BUFR_with_new_filtering/
>>
>> for testing in data assimilation systems. We would appreciate your
>> feedback. We would like to include these changes in our real time
>> processing in about 2 weeks. Later, we will re-process all our data
>> for all missions.
> 
> As it's not possible to add old (latency >5days) data into our
> operational database - which is the sole interface to our
> monitoring/assimilation systems - it will be non-trivial for us to do
> anything with this data set within the next couple of weeks. 
> 
> Instead, we're checking whether it's possible to have a non-operational
> area set up which can be populated with old data. Such a parallel area
> is commonly set up only as needed and is used to hold a short, rolling
> (or static) n-day (n=5 typically) period of recent (<5days old) or NRT
> data on-line, e.g. data processed differently from the operational data,
> as is the case here.
> 
> In case the system can't ingest old data, would it be possible for you
> to process some recent data? A short period of say 1 day's data
> processed in batch and available within a day or two would be adequate. 
> 
> What would be ideal and least effort for us (but not necessary for you
> Sean & Lidia!) would be (a) recent data in parallel or batch and (b)
> fixed to be 'different' from the operational data[1]. Then we could just
> add the new processed data to our operational database and monitor it
> just like the operational COSMICs.
> 
> [1] e.g. add 10 to the current Satellite ID range for COSMIC 740-745;
> 750-755 were reserved with an eye on COSMIC-7,8,...12).
> Unknown/undefined satellites are by default blacklisted from operational
> processing/assimilation in our system, and I would expect in other NWP
> centres' too. (Sean/Lidia: would this work for you?)
> 

No, please don't introduce any new SATID's.


> Please don't take any action right now - older data might turn out to be
> less of an issue than we've encountered had previously, and in any case
> there's no point in providing recent data until our system is set up to
> ingest it (if this proves necessary).
> 
> PS. As with Lidia & Sean, it would take rather longer than a couple of
> weeks to do any assimilation trials though, even after getting some data
> into the system.
> 
> PPS. Could you please add Mike Rennie (michael.rennie at metoffce.gov.uk)
> to the cosmic_announce email list? (Mike at at the sharp end looking
> after the monitoring and assimilation of RO data in my team.) Thx.
> 
> regards,
> Dave