# Assimilation of SEVIRI-observations

## Where to enter the information

The model Cosmo reads in INPUT_??? files (to be found in the COSMO-directories ./det or ./ens???), in which all important parameters for its run are fixed. These files are generated in BACY by lmrun_sx9_de, which in turn results from the template lmrun_sx9_de_template. Both latter files are found in COSMO.

The file INPUT_OBS_RAD contains the SEVIRI-namelists to pass to Cosmo : TOVS_OBS and TOVS_OBS_CHAN. Side remark: these namelists are read-in in Cosmo by the module organize_satelites, see e.g. /e/uhome/kstephan/COSMO_V5_3/src .

It turns out that inclusion of SEVIRI-data necessitates a recent Cosmo-version to include RTTOV10. In this context, one has to choose a recent version of COSMO . R. Faulwetter suggests /e/uhome/rfaulwet/cosmo/lm_f90/cosmo_svn_new/lmparbin_all . This binary is set in COSMO/lmrun_sx9_de_template as

lm_bin=/e/uhome/rfaulwet/cosmo/lm_f90/cosmo_svn_new/lmparbin_all

It is recommended to recompile this Cosmo-version locally to be independent from further personal developments of the binary. This should be done locally on xce (!), e.g. by login into xceh.

To take into account SEVIRI data, several flags in the namelist in lmrun_sx9_de_template have to be set:

• in INPUT_ORG, &RUNCTL , set luse_rttov=.true.
• in INPUT_SAT, &SATCTL , itype_rttov=10
• in INPUT_SAT, &SATCTL , lobsrad=.TRUE.

The switch to include the cloud type can be found in INPUT_SAT, &SATCTL and should be set to lread_ct=.true. if you want to include it (otherwise = .false.). If lread_ct=.true. then you should provide cloud type information, e.g. from NOWCAST SAF (see work of A. Schomburg).

In addition, make sure that the directory including the SEVIRI data is complete: it should contain

• the data of a certain channel, e.g. WV-73 , in both areas 7 and 8 for the dates needed
• the EPI and PRO files for the dates needed
• the sat_conf_file for the corresponding sateliate, e.g. sat_conf_file.msg3

Each of the working directories of COSMO, i.e. det/ and ens*/ , have to contain the following files (for the recent satelite type MSG3):

• rtcoef_msg_2_seviri.dat
• rtcoef_msg_3_seviri.dat
• sccldcoef_msg_3_seviri.dat

To consider SEVIRI data in LETKF, it is mandatory to tell it to consider the COSMO output files fof_RAD_*. This is done in namelist_letkf_template in &ENKF : ensure to have an entry like

 fof_prefix = 'fof' 'fof_RAD_057_instr21'

In order to provide the link of LETKF and COSMO and so to give LETKF access to the fof_RAD_* files , it is mandatory that the input/ directory of LETKF includes the soft link to the fof_RAD_* files of COSMO. This can be done in the script run_letkf by

   ln -s ${RUN_DIR_COSMO}/det/fof_RAD_057_instr21_${DATE_FG}.nc fof_RAD_057_instr21_${DATE_FG}.nc for the deterministic run and  ln -s${RUN_DIR_COSMO}/ens${Iens}/fof_RAD_057_instr21_${DATE_FG}.nc fof_RAD_057_instr21_${DATE_FG}_ens${Iens}.nc


for the ensemble, where one assumes that the current working directory is input/, \${Iens} is the ensemble number . The COSMO source file src_obs_rad.f90 exhibits (probably) a bug in subroutine input_obs_satpp(). In its section 13, the piece of code in the IF..ELSE..ENDIF conditional structure  IF ( iveri_run_class == rc_ass .OR. iveri_end <= 300) THEN iveri_run_type = vt_firstguess ELSE iveri_run_type = vt_analysis ENDIF should move out of the conditional structure, see the corrected version /hpc/uhome/ahutt/cosmo/version5.2_Robin+Africa/src/src_obs_rad.bugfix1.f90 . The SEVIRI data do not include information on the height of measurements since they are obtained experimentally on top of the atmosphere under study. However, since LETKF needs the plevels, i.e. the vertical coordinates, these have to be computed additionally and inserted into the fof_RAD_* files. This is done by RTTOV by setting the COSMO variable calc_k=.TRUE. . However, the computation is time consuming and it is recommended to perform this computation in the deterministic run only. To thsi end, The new BACY script includes this modification by distinguishing the case DET=TRUE and DET=FALSE in the script run_cosmo in the new call edit_nml_cosmo$DET and correspondingly the sed - call in functions_cosmo.sh . The variable calc_k in lmrun_sx9_de_template is set to a dummy replaced by the sed - call.

Typically, provided SEVIRI data are not that regular in time as other data and some date may be missing. For the COSMO 5.2 (and probably 5.3 as well) this is serious problem if SEVIRI data is not provided at full hours since COSMO assumes the presence of the satelite date. To this end, in a first approximation, temporal data gaps may be filled by interpolated or extrapolated data. However, in a recent version of the libradiance , this problem is solved. Now the corresponding routine (fixed by Robin) detects the missing file, writes out an error message like “file not found” but neglects this error and does not exit immediately. This can be checked easily in the file YURAD that reports on the data files read. (AHFeb162016)

To set bands to ACTIVE or PASSIVE, one may set the corresponding flag in the namelist TOVS_OBS_CHAN in lmrun_sx9_de_template . The name chan includes the entries instr, chan, flag, var and band. To set the band channel ACTIVE, you should not set the top bit in flag, but set it to render the band PASSIVE. The entry flag is a number of 11 bits and hence setting the channel to PASSIVE, one has to add the value 1024 to the value. For instance, the entry 33 sets the band to ACTIVE and 1057 to PASSIVE. (AHFeb162016) The bits in chan are coded as follows:

# Bit bit label description
0 SEA Sea
1 SEAICE SeaIce
2 LAND Land
3 HIGHLAND Highland
4 MISMATCH Surface Mismatch
5 CLEAR Clear
6 CLOUDIR IRCloudy
7 CLOUD2 CloudFlag2
8 CLOUD3 CloudFlag3
9 CLOUDH High Cloud
10 PASSIVE Passive (exclude obs from analysis)
11 CLOUDDET use channel for IR cloud detection
12 BCOR force to keep the channel, since it is required in biascor
13 MWSURF use also if surftype derived from mw is not selected.
14 SURFINFL use if the influence of the surface is lower than a threshold

This information is taken from DEF_BIT in mo_rad.f90 (AHFeb162016). It is interesting to mention, that the current implementation (February 2016) just considers bit#10 and hence distinguishes the case of ACTIVE channels (bit #10 not set) and PASSIVE channels (bit #10 set). The other bits are foreseen to implement the different cases. (AHFeb262016)

In &TOVS_OBS_CHAN, the channel numbers map to SEVIRI channels as follows:

#channel TOVS_OBS_CHAN channel name #SEVIRI wavelength (micro m) description
1 IR 3.9 4 3.48 - 4.36 Surface, clouds, wind fields
2 WV6.2 5 5.35 - 7.15 Water vapor, high level clouds, atmospheric instability
3 WV7.3 6 6.85 - 7.85 Water vapor, atmospheric instability
4 IR8.7 7 8.3 - 9.1 Surface, clouds, atmospheric instability
5 IR9.7 8 9.38 - 9.94 Ozone
6 IR10.8 9 9.8 - 11.8 Surface, clouds, wind fields, atmospheric instability
7 IR12.0 10 11.0-13.0 Surface, clouds, atmospheric instability
8 IR13.4 11 12.40 - 14.40 Cirrus cloud height, atmospheric instability

(AHFeb222016)

In order to map RTTOV-10 levels to pressure, 3dvar/analysis/mo_rttov.f90 gives you the corresponding table in the vector preslev . (AHMay192016)

In the implementation of Sea Surface Temperature (SST), it is necessary to keep the model variables T_ICE and H_ICE in the laf files. Since these are generated by the LETKF, one has to tell the LETKF to transfer these variables from the lff-files to the laf-files. This transfer should be done even when the LETKF does not assimilate the variables. The LETKF keeps these variables if one sets

 par_fce = 't_ice h_ice '

in namelist_letkf_template . It is important to mention that avoiding the assimilation of SST information makes it necessary to comment out the lines

&model_error
name = 'SST'         ! disturb SST
scales = 1  100 0 24  ! 1K +  100 km length scale pattern, 24 hour

in namelist_letkf_template . (AHMarch0216)

## Insights into output involving SEVIRI data

Taking a closer look at the output fof_RAD_* file, e.g. with ncdump , it turns out that some data points are set to PASSIVE. This can be seen in variable r_state, whose entries '5' code passive data. A closer look on the origin of this setting, e.g. in flags, reveals the cause of this passive status.

In more detail, a report may contain several observations. For instance, a report may include the measurements in a Field of View (FOV) in different channels. Then the bits in r_flags of the report gives the possible reasons of the status set. It is a byte value whose bits are set according to Table 4 in the feedback file description document. For instance, r_flags=17 means that bit #0 and bit #4 are set since 17=2^4+2^0. The decision on the status of the report is taken by going through the list of possible reasons in a certain order (given in Table 4). This decision is written to variable r_check. In the previous example, r_flags = 17 yields r_check=4 meaning location of the observation is not in the valid area. (AHFeb192016, modified AHFeb222016).

If a report is set PASSIVE, the observations in this report are neglected. If the report is set ACTIVE, then the variable state of each observation decides whether an observation is ACTIVE or PASSIVE and so used or not. If an observation is ACTIVE, then it is used. Otherwise, variables flags and check give more details on the reason of rejection. (AHFeb222016)

Cloud types are given in monRTOVP files. One distinguishes three cloud types (cld_index) : Cirrus clouds (cld_index= 6), convective clouds (cld_index=3) and stratiform clouds (cld_index=1), see section 2.4 in routine prepare_rttov_input in src_obs_rad.f90. (AHMarch042016)