Table of contents
Chapter 1. Non-IFS observation processing (OBSPROC): General overview
Chapter 2. Observations:
Types, variables and error statistics
Chapter 3. CMA creation (MAKEMA)
Chapter 4. The FEEBACK task
Chapter 5. The TOOLS task
Chapter 6. Central-memory
array (CMA) structure/format
Chapter 7. BUFR feedback data structure/format
Chapter 8. SIMULATED-observations data structure/format
Chapter 9. NAMELISTS
Chapter 10. Processing of scatterometer data
REFERENCES
|
|
Next
Section
Previous Section
After invoking the OBSPROC, via program AAOBPPRO, the subroutine CNTOBSPR
is called. As explained in Section 1.5, after finding out that
the FEEDBACK task is requested, the CNTOBSPR branches itself to that section
(Fig. 1.3 ).
If the FEEDBACK task is to be carried out in a parallel mode, subroutine
PREPROC_MPP_BUFDBACK is called first; this routine performs a number of
activities. These activities are mainly concerned with preparing for the
matchup of the ECMA and the CCMA and for later collection of output BUFR
feed-back data. This is achieved by a number of calls to the OBSORT subroutines.
The next step is to call master feed-back routine BUFDBACK (more details
in the next section).
Once the BUFDBACK has finished and handed back the control to the CNTOBSPR
the only thing left to do is some tiding up. In the single-task case this
simply consists of closing the remaining files. However, in the parallel
case subroutine POSTPROC_MPP_BUFDBACK is called. It is via this subroutine,
which in turn calls several OBSORT subroutines, that the gathering of the
BUFR-feed-back data scattered across PEs is done. The aim of collecting
BUFR-feed-back data is to output as many BUFR files as there were in the
input when the assimilation cycle started.
BUFDBACK flow diagram is shown in Figure 4.1. The main purpose of the BUFDBACK
subroutine is threefold:
|
1) to initialize various FEEDBACK-task parameters
and switches, |
|
2) to print out the chosen run setup, and |
|
3) to invoking either the single-task (BFDBASIN)
or the parallel (BFDBAMPP) version of the FEEDBACK task. |
The initialization of parameters and switches consists of defining:
| |
• numerical limits (SULIM); |
| |
• variables' numbers (SUVNMB); |
| |
• level/layers structure (SULEVLAY); |
| |
• CMA observation and code types (SUCMOCTP); |
| |
• BUFR observation types and subtypes (SUBUOCTP); |
| |
• observation events (SUEVENTS); |
| |
• observation flags (SUFLTXT); |
| |
• various observation processing codes
(SUCODES); |
| |
• BUFR data structure and format (SETBUFR); |
| |
• CMA data structure and format (SUCMA); |
| |
• valid satellite ids (SUSATID); |
| |
• satellite retrieval types (SUSATRET); |
| |
• appropriate setting for BUFR software
(BUPRQ). |
Then, the chosen run set-up is printed by calling the PREAMB subroutine.
Finally, either the BFDBAMPP or BFDBASIN subroutine is called.
Figure 4.1 Subroutine BUFDBACK Flow Diagram
The idea in both of these routines is to prepare for the actual scanning
of the ECMA file, during which all relevant information is taken, and then
appended onto the input initial BUFR feed-back (output of the MAKECMA task).
Both subroutines are divided in 5 sections.:
|
2) initialization of input/output files, |
|
3) creation of BUFR feed-back, |
|
4) finishing off input/output file processing,
and |
|
5) returning to the caller. |
BFDBAMPP subroutine flow diagram is shown in Figure 4.2.
Figure 4.2 Subroutine BFDBAMPP Flow Diagram
The preparation section is appreciably different for parallel and single-task
mode. In the single-task case this section is non-existent. However, in
the parallel case the provision a match-up of the ECMA and the CCMA is needed;
this is carried out by calling the OBSORT subroutine LIB_OBSORT. This is
called the MATCHUP sub-task. As explained earlier, the MAKECMA task produces
the ECMA for the IFS screening run. On the other hand, the IFS screening
selects only a subset of data (both in terms of reports and pieces of information)
and passes them as CCMA to the IFS minimization run. The CCMA is about 1/10
of the ECMA. Once the analysis has finished there is a need to update the
original ECMA with all relevant information stored in the CCMA. This update
is carried out by calling the LIB_OBSORT with the match-up options chosen.
In the second step (input/output file initialization) the same subroutines
as in the MAKECMA task are called. Thus, BUFR input/output files are initialized
by the INIIBUFF and INIOBUFF subroutines, the CMA file is opened up (if
at all) by INICMAIO and diagnostic/debugging files are initialized by calling
INIDEBDE, INIDEBEN and INIDEBRE.
Third step is to perform the actual feed-back. In order to do this the control
is handed down to the main data-scanning subroutine SCANCMA (more details
in the next subsection). Upon its completion the control is returned so
that the diagnostics print-out (CAMSTA and BUFRSTA) and the closing of files
can take place.
It is worth explaining here in more detail what is happening with CMA data
at this stage, in relation whether it is a parallel or single-task run.
In the single-task case the CMA file is initialized by calling the INICMAIO
subroutine, which in turn may call the CMALOAD subroutine if the CMA data
are to be memory resident (the NAMCMA namelist switch LICMAMER=.T.). However,
in a parallel run with the MATCHUP option (LMATCHUP=.T.) the CMA files (ECMA
and CCMA) would have already been read by the MATCHUP sub-task and the ECMA
updated. Within the MATCHUP context the updated ECMA could be written out
and/or passed down, as an internal array, for further use. The NAMRUN namelist
switch LFWRICMA controls this option. If the ECMA was written out, its initialization
would be very similar as the one in the single-task case. On the other hand,
if it is passed as an internal array, only the ECMA DDRs are handled explicitly
at this stage. There is another NAMRUN namelist switch LFREACMA, which can
be used to read the updated ECMA rather then to use internally available
one.
The aim of this subroutine, which flow diagram is shown in Figure 4.3 and Figure 4.4, is to loop over the updated ECMA
and the initial BUFR feed-back reports (with one to one correspondence)
and to pass from CMA all data assimilation observation related informations
to BUFR. SCANCMA is divided into 6 logical sections:
|
1) The initial pre-set is carried out. This consists
of a number of steps. For example, it prepares for a possible BUFR
feed-back compression, prints some messages, initializes some local
variables etc.. Finally, a loop over CMA time slots is started. |
|
2) A loop over the CAMA and BUFR reports is started.
A pair of CMA and BUFR reports are then read in. Regardless whether
the ECMA and/or BUFR may be file- or memory-resident, reports are
made available by calling the GETICMAR (to get a CMA report) and GETIBUFR
(to get a BUFR report) subroutines. These reports are then checked
to see if they correspond to each other. |
|
3) After establishing the CMA-BUFR correspondence,
some input BUFR-report information is saved, since they are needed
later for BUFR encoding. |
|
4) Depending which CMA observation type is considered,
SCANCMA branches off to one of the basic feed-back observation-handling
routines. It is in these routines, or in those that they may be calling,
that the actual feed-back is done (more details in the next subsection).
These routines are: |
| |
• HRTOVOUT (high resolution TOVS); |
| |
• TOSAOUT (standard SATEM/TOVS); |
| |
• SCATSOUT (SCATTEROMETER). |
|
There is one routine for each CMA observation
type, as their names imply, (with the exception of SATEMs). |
|
5) After the control is returned from one of
the basic feed-back routines it is checked whether the report is for
BUFR compression. If so, subroutine PREPLCOM is called to add it onto
a temporary storage which, when full, is passed to subroutine ENCPFM
for encoding. ENCPFM is just a cover routine with a further call to
encode the compressed BUFR data. At the present time, BUFR compression
is applied for TOVS, SSMI, ATOVS and SCATTEROMETER data only. A BUFR
report not meant to be compressed is encoded straight away using the
BUFR encoder routine ENCBUFR. The encoded BUFR message is then added
either onto a file or to an array, depending on whether the output
feed-back BUFR is file- or memory-resident. This is done by calling
the subroutine ADDBUFRR. At this stage a few diagnostics parameters/arrays
are updated and, if required, reports printed. |
|
6) Before finishing the processing in SCANCMA,
the temporary storage (for the BUFR feed-back reports that are meant
to be compressed) is checked again and any remaining reports compressed
and encoded. |
BUFR feed-back compression is controlled by a number of switches and parameters.
There are 4 switches and 12 adjustable parameters; 3 for TOVS, 3 for SSMI,
3 for ATOVS and 3 for SCATTEROMETER data. Switches are held in the NAMFDBAC
namelist, whereas parameters are held in the NAMBUFR namelist. These switches
are: LBUFRCOM, LTOVSCOM, LSSMICOM and LSCATCOM. LBUFRCOM is the master compression
switch, whereas the others control compression of TOVS/ATOVS, SSMI and SCATTEROMETER
data. The idea with the adjustable parameters is to be able to adjust them
from time to time. They control: number of elements in the BUFR report,
the number of reports (packet size) to form one BUFR message and the number
of platforms (station id's) to be compressed. The TOVS compression-related
parameters are NPTSELM, NPTSPKT and NPTSPFM, whereas the ATOVS compression-related
parameters are NPATSELM, NPATSPKT and NPATSPFM. The SSMI parameters are:
NPSMELM, NPSMPKT and NPSMPFM and the SCATTEROMETER parameters are NPSCELM,
NPSCPKT and NPSCPFM.
Figure 4.3 Subroutine SCANCMA Flow Diagram
Figure 4.4 Subroutine SCANCMA BUFR Observation Type Branch Off Flow
Diagram
Basic feed-back handling routines, listed in the previous sub-section more
or less have a very similar strategy (see Figure 4.4).
After some initial pre-set, information related to a particular report as
a whole is searched for, and the feed-back appended onto to a BUFR report
by calling the REPEVST subroutine. The report feed-back information comprises:
Whether they are fed back at all is controlled by the master switch LFBREVST
from the NAMFDBAC namelist. Feed-back of reports events no 1, blacklist
events, events no. 2 and status is controlled by further four NAMFDBAC namelist
switches: LFBREVE1, LFBRBLEV, LFBREVE2 and LFBRSTAT, respectively.
However, in the case of TOVS, ATOVS, SCATTEROMETER and SSMI observations
additional subroutines TOVSPRES, ATOVSPRES, PRESCAFB and PRSSMIFB are called
first at this stage. TOVSPRES, ATOVSPRES and PRSSMIFB deal with feeding
back the `pre-SAT'/`pre-SSMI' and 1D VAR related information stored mostly
in the optional part of the TOVS, ATOVS and SSMI CMA-report header. This
is controlled by LPRESAFB, LPREASFB and LPRESSFB switches from the NAMFDBAC
namelist. In the case of SCATTEROMETER data it is a different set of informations
to deal with and switch LPRESCFB is used for that.
The next step is to feed-back analysis variables. Depending on observation
type, a different subroutine may be called. In the case of the conventional
single-level reports FINSINP is called, whereas for the conventional multi-level
reports FINADDM is called. Thus, SYNOPOUT, AIREPOUT, SATOBOUT, DRIBUOUT
and PAOBOUT would be calling FINSINP, whereas TEMPOUT and PILOTOUT would
be calling FINADDM. However, in the case of high resolution TOVS (handling
routine TOSAOUT), ATOVS or standard SATEM/TOVS (handling routine TOSAOUT)
further granulation takes place by calling the TOVSTHPW, ATOVSTHPW and RADIAOUT
subroutines. In the case of SCATTEROMETER and SSMI reports, the feeding
back of the analysis variables is done in-line; hence, SSMISOUT and SCATSOUT
have no further calls.
Finally, in the last step the analysis variables' flags, events, status,
error statistics, departures, etc. are fed back. This is achieved via the
DATESFD subroutine call (see next subsection), after which the control is
handed back to the calling subroutine.
Figure 4.5 Subroutine DATESFD Flow Diagram
This subroutine, for which the flow diagram is shown in Figure 4.5, deals with feeding back several
different types of informations:
|
(a) analysis quality control flags are fed back
by calling the worker DATUMFLG subroutine, |
|
(b) analysis variables' events are fed back by
calling the DATUMEVS subroutine, |
|
(c) analysis variables' status is dealt with
by calling the DATUMSTA subroutine, |
|
(d) analysis variables' quality control constants
are fed back via a call to the QCCON12 subroutine, |
|
(e) analysis variable's error statistics are
dealt with by calling the DATUMEST subroutine, |
|
(f) analysis variables' difference statistics
(departures) are handled by calling a few extra routines |
| |
• first-guess departures are handled by
the FGNSDEV subroutine, |
| |
• depending on whether it is a feed-back
for the incremental or for the standard variational run, the subroutine
INCNSDEV or STDNSDEV may be called, respectively. |
Furthermore, there are a number of switches which control what flags, events
departures etc. are fed back. All these switches are held in the NAMFDBAC
namelist.
The feed-back of analysis quality-control flags is controlled by six switches.
The master switch is LFBDFLAG and it controls whether to feed back the flags
at all. The other five switches control the feed-back of a particular set
of flags. These sets of flags are the first-guess, the analysis, the blacklist,
the departure and the final-check flags. Their corresponding switches are
LFBDFGFL, LFBDANFL, LFBDBLFL, LFBDDEFL and LFBDFIFL.
The feed-back of analysis variables' events and status is controlled by
five switches; these are LFBDEVST, LFBDEVE1, LFBDBLEV, LFBDEVE2, LFBDSTAT.
The master switch is LFBDEVST, whereas the others control the feed-back
of the variables' events no. 1, the blacklist events, the variables' events
no. 2 and the variables' status, respectively.
For the analysis variables' quality-control constants the feed-back is controlled
by LFBDQCCO switch.
When it comes to feeding back the analysis variables' error statistics,
five switches are used. Again, there is a master switch (LFBDERRS) and a
switch for each type of observation-error statistics. Thus, the feed-back
of the final, prescribed, persistence, representativeness and first-guess
errors is controlled by LFBDFIER, LFBDOBER, LFBDPEER and LFBDREER switches,
respectively.
The feed-back of departures is handled by nine switches. However, what departures
may be available depends on whether it is an incremental or a non-incremental
variational analysis. There is only one master switch (LFBDDEPT), regardless
of the variational analysis type. Both types have first-guess and analysis
departures, and they are handled by the LFBDFGDE and LFBDANDE switches,
respectively. Additionally, the incremental variational analysis has four
`update' departures: very initial; initial hi-resolution; initial low-resolution;
and final low-resolution departures, and they are controlled by LFBDUIDE,
LFBDUHDE, LFBDULID, LFBDULFD, respectively. Furthermore, in both the incremental
and the standard cases some additional departures (if present) may be fed
back too. These additional departures are those which may have been saved
at various stages in the minimization process and their feed-back is controlled
by LFBDSIDE switch.
Next Section
Previous Section
|
