docs/depolarization/depolarization.rst

Tue, 25 Oct 2016 12:50:55 +0300

author
Michael Kottas <mike.kottas@gmail.com>
date
Tue, 25 Oct 2016 12:50:55 +0300
changeset 69
380d41368260
parent 68
f697817dad5f
child 70
31295554bf20
permissions
-rw-r--r--

Images required for depolarization.rst.

mike@68 1 1. Particle Linear Depolarization Ratio Implementation
mike@68 2 ======================================================
ulalume3@67 3
mike@68 4 The most important improvement included in the SCC v4.0 is the implementation of a new optical product which is the particle linear depolarization ratio.
ulalume3@67 5
mike@68 6 1.1 Background
ulalume3@67 7 --------------
ulalume3@67 8
mike@68 9 The calculation of the volume linear depolarization ratio profile (*VLDR*) and particle linear depolarization ratio profile (*PLDR*) needs two different steps:
ulalume3@67 10
mike@68 11 #. the calibration of the polarization sensitive lidar channels;
mike@68 12 #. the calculation of the *VLDR* or *PLDR* itself.
mike@68 13
mike@68 14 The SCC allows the user to make both the above points. In particular the calibration step is made by a completely new module called **scc\_calibrator** which computes the *apparent calibration factor* :math:`\beta^*` out of the pre-processed data provided by the standard **ELPP** (Earlinet Lidar Pre-Processor) module and it records it in the SCC database (SCC\_DB). Once logged into the SCC\_DB this factor can be used whenever it is necessary.
mike@68 15
mike@68 16 The raw lidar calibration measurements should be put in a NetCDF file which has the same structure as the “standard” raw SCC NetCDF input file (for more details see sections 2 and 3.2).
ulalume3@67 17
mike@68 18 New signal types have been introduced to take into account special channel configurations used for calibration purposes.
ulalume3@67 19
mike@68 20 Moreover new product types for both calibration and *PLDR* calculation have been defined. As, in principle, it is possible to calculate the *PLDR* only when the aerosol backscatter coefficient profile is available the following new products have been defined:
ulalume3@67 21
mike@68 22 #. *Linear polarization calibration (factor* h) *(product\_type\_id=6);*
mike@68 23 #. *Raman backscatter and linear depolarization ratio
ulalume3@67 24 (product\_type\_id=7);*
mike@68 25 #. *Elastic backscatter and linear depolarization ratio
ulalume3@67 26 (product\_type\_id=8).*
ulalume3@67 27
mike@68 28 The first product in the above list is used only for calibration while the other two are used for the calculation of *PLDR*. Basically, in most of the cases, the products 2 and 3 are equivalent to the corresponding backscatter product types with the exception that also the following new variables are available:
ulalume3@67 29
mike@68 30 .. code-block:: python
ulalume3@67 31
mike@68 32 double VolumeDepol(Length) ;
mike@68 33 double ErrorVolumeDepol(Length) ;
mike@68 34 ErrorVolumeDepol:long\_name = "absolute error of VolumeDepol" ;
mike@68 35 double ParticleDepol(Length) ;
mike@68 36 double ErrorParticleDepol(Length) ;
mike@68 37 ErrorParticleDepol:long\_name = "absolute error of ParticleDepol" ;
ulalume3@67 38
mike@68 39 1.2 Polarization calibration
ulalume3@67 40 ----------------------------
ulalume3@67 41
mike@68 42 An important point is the definition of reliable *PLDR* calibration procedures. Within EARLINET the following calibration procedures are currently used:
ulalume3@67 43
mike@68 44 a) Rayleigh calibration;
mike@68 45 b) +45 calibration method, or D90 calibration method (made by +45 and -45 measurements);
mike@68 46 c) 3 signals (total, cross and parallel).
ulalume3@67 47
mike@68 48 It is well known that method a) could produce easily large errors on *PLDR* which cannot be controlled. For this reason only the methods b) and c) can be used to provide reliable polarization calibrations and so only those methods will be implemented in the SCC.
ulalume3@67 49
mike@68 50 For what it concerns the method c) it, basically, requires to solve the equation:
ulalume3@67 51
mike@68 52 .. math::
mike@68 53 \alpha_s P_s + \alpha_p P_p = P
ulalume3@67 54
mike@68 55 in two different of atmospheric layers with considerably different *VLDR*. So to calibrate in this way the implementation of automatic layer identification in the SCC is required. As at moment this feature is not yet available within the SCC *ONLY* the method b) is considered.
mike@68 56
mike@68 57 1.3 SCC procedure to calculate the PLDRP
mike@68 58 ----------------------------------------
mike@68 59
mike@68 60 According to what mentioned before the SCC calculates the *PLDR* through the following steps:
ulalume3@67 61
mike@68 62 #. The user needs to create a new system configuration in the SCC\_DB including only lidar channels used for the calibration. One (or more) *Linear polarization calibration (product\_type\_id=6)* product should be associated to this new configuration (see section 3.2 for more details);
mike@68 63
mike@68 64 #. This new system configuration should contain only the polarization channels in the configuration used for the calibration (for example rotated in the polarization plane of +45 degrees). A channel in calibration measurement configuration should have a *DIFFERENT* channel ID from the channel ID corresponding to the same channel in standard measurement configuration. For example, if a system has two polarization channels which in standard measurement configuration correspond to the channel ID=1 and 2 respectively, the same physical channels under calibration measurement configuration should correspond to different channel IDs (let's say ID=3 and 4 for the +45 degrees polarization rotated channels and ID=5 and 6 for the -45 degrees polarization rotated ones in case D90 calibration method is used). Moreover, the polarization channels should be labeled correctly using the new signal types available (*+45elPT, +45elPR, -45elPT, -45elPR, +45elPTnr, +45elPTfr, +45elPRnr, +45elPRfr, -45elPTnr, -45elPTfr, -45elPRnr, -45elPRfr).* For more details see section 3.2;
ulalume3@67 65
mike@68 66 #. In SCC v4.0 the polarization channels are *NOT* labeled on the base of their polarization state (as it was done in the SCC v3.11) but *ALWAYS* as transmitted and reflected channels. So the channels that in SCC v3.11 were labeled as *elCP, elCPnr, elCPfr, elPP, elPPnr elPPfr* will be labeled in SCC v4.0 as *elPR, elPRnr elPRfr elPT, elPTnr elPTfr* where the letter *T* stands from transmitted and the letter *R* for reflected.
ulalume3@67 67
mike@68 68 :WARNING: In switching from the SCC v3.11 to SCC v4.0 the following modifications have been made on *ALL* channels of *ALL* registered configurations:
mike@68 69 *elPP→elPR*
ulalume3@67 70
mike@68 71 *elCP→elPT*
ulalume3@67 72
mike@68 73 *elPPnr→elPRnr*
ulalume3@67 74
mike@68 75 *elPPfr→ elPRfr*
ulalume3@67 76
mike@68 77 *elCPnr→ elPTnr*
ulalume3@67 78
mike@68 79 *elCPfr→ elPTfr*
mike@68 80
mike@68 81 Please be sure these modifications reflect to your actual lidar setup(cross channels are transmitted and parallel channels are reflected);
ulalume3@67 82
mike@68 83 4. The user needs to submit a file (same format as raw SCC input file) containing the raw data for the lidar channels defined at the point 1 (see section 3.2 for more details);
mike@68 84 #. The file at point 2 is pre-processed by **ELPP** module which applies the standard pre-processing procedures applied to “standard” lidar data;
mike@68 85 #. The pre-processed files are then processed by the new modules **scc\_calibrator** which calculates :math:`\eta^*` *the apparent calibration factor* and logs it into the SCC\_DB;
mike@68 86 #. The user needs to create a new system configuration in the SCC\_DB (which should be different from the one used for the calibration) and associate it the new product *Raman backscatter and linear depolarization ratio product\_type\_id=7)* or *Elastic backscatter and linear depolarization ratio (product\_type\_id=8).* Alternatively the calculation of those products can be added to an already existing lidar configuration as long as it is different from the calibration one;
mike@68 87 #. The product defined at point 5 should be linked to the product containing the polarization calibration (defined at point 1) in a way that the *apparent calibration factor* can be selected from the SCC\_DB (see section 3.3 and in particular figure 3.4);
mike@68 88 #. The user needs to submit another SCC raw data file containing the “standard” measurements;
mike@68 89 #. Finally **ELPP** and **ELDA** will produce a b-file containing backscatter coefficient profile and *PLDR*. In particular this calculation is made in two different steps: from the pre-processed lidar polarization signals, and taking into account the *apparent calibration factor* and the *calibration factor correction K* (defined as option of *Linear polarization calibration* product\ *)* written into the SCC\_DB, an “apparent” *VLDR* :math:`\delta^*` is calculated. Even if :math:`\delta^*` is a calibrated quantity it can be still affected by possible systematic errors due to not perfect optics or alignment of the system;
ulalume3@67 90
mike@68 91 #. To take into account these errors a corrected *VLDR* (:math:`\delta`) is calculated using the *polarization cross-talk correction parameters* *G* and *H* calculated on the base of Müller matrix formalism. These cross-talk correction parameters (*G* and *H*) are stored in the SCC\_DB for each lidar channels (see section 3.1 in particular figure 3.2). Finally the *PLDR* is calculated using the backscatter coefficient profile and the molecular LDRP calculated by ELPP considering the center wavelength and bandwidth of the channels interference filter.
mike@68 92
mike@68 93 The *apparent calibration factor* :math:`\eta^*` is calculated by the **scc\_calibrator** module as the geometrical mean of the ratio of the +/-45 degrees reflected to the +/- 45 degrees transmitted signals within an altitude calibration range defined by the users in the raw data input files.
ulalume3@67 94
mike@68 95 In case of +45 calibration method :math:`\eta^*` is calculated by:
ulalume3@67 96
mike@68 97 .. math::
mike@68 98 \eta^* = \frac{I_R}{I_T}(+45)
ulalume3@67 99
ulalume3@67 100 While in case of D90 calibration method:
ulalume3@67 101
mike@68 102 .. math::
mike@68 103 \eta^* = \sqrt{\frac{I_R}{I_T}(+45) \frac{I_R}{I_T}(-45)}
ulalume3@67 104
ulalume3@67 105 **ELDA** module calculates the “apparent” *VLDR*:
ulalume3@67 106
mike@68 107 .. math::
mike@68 108 \delta^* = \frac{K}{\eta^*} \cdot \frac{I_R}{I_T}
ulalume3@67 109
ulalume3@67 110 the *VLDR*
ulalume3@67 111
mike@68 112 .. math::
mike@68 113 \delta = \frac{\delta^*(G_T + H_T)-(G_R + H_R)}{(G_R - H_R) - \delta^*(G_T - H_T)}
ulalume3@67 114
ulalume3@67 115 and the *PLDR*
ulalume3@67 116
mike@68 117 .. math::
mike@68 118 \delta_{\alpha} = \frac{(1 + \delta_m)\delta R - (1 + \delta)\delta_m}{(1 + \delta_m)R - (1 + \delta)}
ulalume3@67 119
ulalume3@67 120 where:
ulalume3@67 121
mike@68 122 - :math:`\eta^*` is the *apparent calibration factor* calculated by **scc\_calibrator**
mike@68 123
mike@68 124 - *K* is the *calibration factor correction* defined as polarization product option
ulalume3@67 125
mike@68 126 - :math:`I_T` and :math:`I_R` are the transmitted and the reflected signals in the polarization detection set-up
ulalume3@67 127
mike@68 128 - :math:`G_{T,R}` and :math:`H_{T,R}` are *polarization cross-talk correction parameters* for the transmitted and reflected signals used to correct for systematic errors. Both these factors are defined in the SCC\_DB for each lidar channel.
ulalume3@67 129
mike@68 130 - :math:`\delta_m` is the molecular linear depolarization ratio calculated by ELPP
mike@68 131
mike@68 132 - *R* is the backscatter ratio
ulalume3@67 133
mike@68 134 Please note once again that the polarization channels are described in terms of transmitted and reflected signals. This means that according to different lidar instrumental configurations, the transmitted or the reflected channel can contain total, perpendicular or parallel polarized signals.
ulalume3@67 135
mike@68 136 In order to retrieve the backscatter profile the total signal must be obtained combining the transmitted and reflected polarized signals. The following formula is used:
ulalume3@67 137
mike@68 138 .. math::
mike@68 139 I_{total} \propto \frac{\eta^*}{K}H_R I_T - H_T I_R
ulalume3@67 140
mike@68 141 The formulas above are general and can be adapted to all possible polarization lidar configurations selecting the right polarization cross-talk correction parameters (see Table 1.1).
ulalume3@67 142
mike@68 143 Let's suppose, for example, we have the perpendicular polarized lidar signal on the transmitted channel and the parallel polarized on reflected channel. For an ideal system (no diattenuation and cross-talk) we have:
ulalume3@67 144
mike@68 145 .. math::
mike@68 146 G_T=1 , \qquad H_T=-1, \qquad G_R=1, \qquad H_R=1
mike@68 147
mike@68 148 If, on the other hands, we have the perpendicular polarized lidar signal on reflected channel and the total polarized on the transmitted for and ideal system we have:
ulalume3@67 149
mike@68 150 .. math::
mike@68 151 G_T=1 , \qquad H_T=0, \qquad G_R=1, \qquad H_R=-1
ulalume3@67 152
ulalume3@67 153
mike@68 154 **Table 1.1:** Polarization cross-talk correction parameters for ideal systems
ulalume3@67 155
ulalume3@67 156 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 157 | Laser polarization | Detected in lidar channel |
mike@68 158 + +-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 159 | | Transmitted | Reflected |
mike@68 160 + +-----------------------------+-----------------+-----------------+-----------------+
mike@68 161 | | :math:`G_T` | :math:`H_T` | :math:`G_R` | :math:`H_R` |
ulalume3@67 162 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 163 | total | 1 | 0 | 1 | 0 |
ulalume3@67 164 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 165 | parallel | 1 | 1 | 1 | 1 |
ulalume3@67 166 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 167 | cross | 1 | -1 | 1 | -1 |
ulalume3@67 168 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 169
mike@68 170 The *apparent calibration factor (:math:`\eta^*`), *the calibration factor correction* (*K*) and the *polarization cross-talk correction parameters* are stored by **ELPP** module in the intermediate NetCDF files using the following variables:
ulalume3@67 171
mike@68 172 testing the inline code :code:`test`
ulalume3@67 173
mike@68 174 - :code:`Polarization_Channel_Gain_Factor` (*apparent calibration factor* - :math:`\eta^*` )
mike@68 175 - :code:`Polarization_Channel_Gain_Factor_Correction` (*calib. factor corr.* – *K*)
mike@68 176 - :code:`G_T`
mike@68 177 - :code:`H_T`
mike@68 178 - :code:`G_R`
mike@68 179 - :code:`H_R`
ulalume3@67 180
mike@68 181 Finally new usecases have been defined to take into account all the possible lidar configurations. The details on that are provided as a separate file.
ulalume3@67 182
mike@68 183 2. Changes of the SCC input format
mike@68 184 ==================================
ulalume3@67 185
ulalume3@67 186 The following minor changes have been applied to raw SCC data format:
ulalume3@67 187
mike@68 188 #. The optional variable *ID\_Range* has been *REMOVED*;
mike@68 189 #. The *OPTIONAL* variable :code:`int Signal\_Type(channels)` has been added. The possible values are the same available in the SCC\_DB:
ulalume3@67 190
mike@68 191 :code:`0` :math:`\rightarrow` :code:`elT`
ulalume3@67 192
mike@68 193 :code:`1` :math:`\rightarrow` :code:`elTnr`
ulalume3@67 194
mike@68 195 :code:`2` :math:`\rightarrow` :code:`elTfr`
ulalume3@67 196
mike@68 197 :code:`3` :math:`\rightarrow` :code:`vrRN2`
ulalume3@67 198
mike@68 199 :code:`4` :math:`\rightarrow` :code:`vrRN2nr`
ulalume3@67 200
mike@68 201 :code:`5` :math:`\rightarrow` :code:`vrRN2fr`
ulalume3@67 202
mike@68 203 :code:`6` :math:`\rightarrow` :code:`elPR`
ulalume3@67 204
mike@68 205 :code:`7` :math:`\rightarrow` :code:`elPT`
ulalume3@67 206
mike@68 207 :code:`8` :math:`\rightarrow` :code:`pRRlow`
ulalume3@67 208
mike@68 209 :code:`9` :math:`\rightarrow` :code:`pRRhigh`
ulalume3@67 210
mike@68 211 :code:`10` :math:`\rightarrow` :code:`elPRnr`
ulalume3@67 212
mike@68 213 :code:`11` :math:`\rightarrow` :code:`elPRfr`
ulalume3@67 214
mike@68 215 :code:`12` :math:`\rightarrow` :code:`elPTnr`
ulalume3@67 216
mike@68 217 :code:`13` :math:`\rightarrow` :code:`elPTfr`
ulalume3@67 218
mike@68 219 :code:`14` :math:`\rightarrow` :code:`vrRH2O`
ulalume3@67 220
mike@68 221 :code:`15` :math:`\rightarrow` :code:`pRRhighnr`
ulalume3@67 222
mike@68 223 :code:`16` :math:`\rightarrow` :code:`pRRhighfr`
ulalume3@67 224
mike@68 225 :code:`17` :math:`\rightarrow` :code:`pRRlownr`
ulalume3@67 226
mike@68 227 :code:`18` :math:`\rightarrow` :code:`pRRlowfr`
ulalume3@67 228
mike@68 229 :code:`19` :math:`\rightarrow` :code:`vrRH2Onr`
ulalume3@67 230
mike@68 231 :code:`20` :math:`\rightarrow` :code:`vrRH2Ofr`
ulalume3@67 232
mike@68 233 :code:`21` :math:`\rightarrow` :code:`elTunr`
ulalume3@67 234
mike@68 235 :code:`22` :math:`\rightarrow` :code:`+45elPT`
ulalume3@67 236
mike@68 237 :code:`23` :math:`\rightarrow` :code:`+45elPR`
ulalume3@67 238
mike@68 239 :code:`24` :math:`\rightarrow` :code:`-45elPT`
ulalume3@67 240
mike@68 241 :code:`25` :math:`\rightarrow` :code:`-45elPR`
ulalume3@67 242
mike@68 243 :code:`26` :math:`\rightarrow` :code:`+45elPTnr`
ulalume3@67 244
mike@68 245 :code:`27` :math:`\rightarrow` :code:`+45elPTfr`
ulalume3@67 246
mike@68 247 :code:`28` :math:`\rightarrow` :code:`+45elPRnr`
mike@68 248
mike@68 249 :code:`29` :math:`\rightarrow` :code:`+45elPRfr`
ulalume3@67 250
mike@68 251 :code:`30` :math:`\rightarrow` :code:`-45elPTnr`
ulalume3@67 252
mike@68 253 :code:`31` :math:`\rightarrow` :code:`-45elPTfr`
ulalume3@67 254
mike@68 255 :code:`32` :math:`\rightarrow` :code:`-45elPRnr`
ulalume3@67 256
mike@68 257 :code:`33` :math:`\rightarrow` :code:`-45elPRfr`
ulalume3@67 258
mike@68 259 :WARNING: It this variable is found in the SCC input file the corresponding settings in the SCC database will be *overwritten*. Unless you don't have any valid reason to overwrite the database value this variable should not be used.
ulalume3@67 260
mike@68 261 3. The variables:
ulalume3@67 262
mike@68 263 .. code-block:: python
mike@68 264
mike@68 265 double Pol\_Calib\_Range\_Min(channels)
mike@68 266 double Pol\_Calib\_Range\_Max(channels)
ulalume3@67 267
mike@68 268 have been added. Both these variable are *MANDATORY* for any calibration raw dataset. These variable should be included only the polarization calibration measurements and should specify the altitude range (meters) in which the polarization calibration should be made. For more details see section 3.3;
mike@68 269
mike@68 270 4. The variable :code:`Depolarization_Factor` has been *REMOVED*.
ulalume3@67 271
mike@68 272 The SCC v3.11 used this variable to get polarization calibration factor for the calculation of the total signal out of cross and parallels ones. As the SCC v4.0 is able to calculate the same parameter by itself, the use of this variable is *NOT* possible anymore. The recommended way to get a valid and quality assured depolarization calibration factor is to submit to the SCC v4.0 a polarization calibration dataset and let the SCC to calculate such factor.
mike@68 273
mike@68 274 To make this change more smooth and to provide the users with the possibility to continue to analyze their data with the SCC v4.0 even if a calibration dataset has not been submitted yet, it will be possible for a *LIMITED* period of time to submit the calibration constant via the SCC web interface. The SCC will keep track of the used calibration method (automatic or manual).
ulalume3@67 275
mike@68 276 :WARNING: After this transition period *ONLY* automatic calibration will be allowed!
ulalume3@67 277
mike@68 278 5. The new *OPTIONAL* variable:
ulalume3@67 279
mike@68 280 :code:`string channel\_string\_ID(channels)`
ulalume3@67 281
mike@68 282 has been introduced.
mike@68 283
mike@68 284 Starting from SCC v4.0 the lidar channel can be identified not only by using integers (as it happened until SCC v3.11) but also by using strings.
ulalume3@67 285
mike@68 286 The procedure implemented in the SCC v4.0 to recognize the lidar channel within the raw lidar data is fully backward compatible (old format files are accepted as they are by SCC v4.0).
ulalume3@67 287
mike@68 288 :WARNING: Please note that the definition of the new string variable requires netCDF-4 format! The type *string* is not supported in netCDF-3 format!
ulalume3@67 289
ulalume3@67 290 Real Example
ulalume3@67 291 ============
ulalume3@67 292
ulalume3@67 293 This section describes all the practical steps the users need to follow
ulalume3@67 294 to switch from SCC v3.11 to new SCC v4.0.
ulalume3@67 295
ulalume3@67 296 **IMPORTANT:**
ulalume3@67 297
ulalume3@67 298 If your lidar system is not equipped with any polarization channels *NO*
ulalume3@67 299 changes are required. In this case, the SCC v4.0 should work using the
ulalume3@67 300 same input files and the same database configurations you have used with
ulalume3@67 301 the SCC v3.11. Anyway as in the SCC v4.0 several bugs have been fixed,
ulalume3@67 302 it is recommended to re-run all the measurement IDs you have submitted.
ulalume3@67 303 For doing that you just need to reprocess all your data without the need
ulalume3@67 304 to submit raw data files already uploaded on the server.
ulalume3@67 305
ulalume3@67 306 The practical example reported below describes the modifications
ulalume3@67 307 required to use the SCC v4.0 for lidar systems equipped with
ulalume3@67 308 polarization channels.
ulalume3@67 309
ulalume3@67 310 Modification of polarization channel parameters
ulalume3@67 311 -----------------------------------------------
ulalume3@67 312
ulalume3@67 313 In what it follows it is assumed you already have registered one or more
ulalume3@67 314 lidar configurations in the SCC database and that such configurations
ulalume3@67 315 have been already used to produce optical products (aerosol extinction
ulalume3@67 316 and/or backscatter coefficients) by means of the SCC v3.11.
ulalume3@67 317
ulalume3@67 318 Let's assume your 3+2 system is registered in the SCC database and the
ulalume3@67 319 settings used by the SCC v3.11 are the ones summarized in table 3.1.
ulalume3@67 320
ulalume3@67 321 **Table 3.1:** Example of configuration in SCC v3.11
ulalume3@67 322
ulalume3@67 323 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 324 | Channel Name | Channel ID | Channel Type | nighttime | daytime |
ulalume3@67 325 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 326 | 355 | 1 | elT |  |  |
ulalume3@67 327 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 328 | 387 | 2 | vrRN2 |  | |
ulalume3@67 329 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 330 | 532 cross | 3 | elCP |  |  |
ulalume3@67 331 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 332 | 532 parallel | 4 | elPP |  |  |
ulalume3@67 333 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 334 | 607 | 5 | vrRN2 |  | |
ulalume3@67 335 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 336 | 1064 | 6 | elT |  |  |
ulalume3@67 337 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 338
ulalume3@67 339 We assume there are 2 system configurations called “nighttime” and
ulalume3@67 340 “daytime”. The nighttime configuration contains all the available lidar
ulalume3@67 341 channels (in order to calculate, for example, the aerosol extinction at
ulalume3@67 342 355 and 532nm and the aerosol backscatter at 355, 532 and 1064nm) while
ulalume3@67 343 in daytime conditions only elastic channels are used (only elastic
ulalume3@67 344 backscatter coefficients are generated).
ulalume3@67 345
ulalume3@67 346 To make these settings working with SCC v4.0 it is needed to modify
ulalume3@67 347 *ONLY* the products properties involving the polarization channels (532
ulalume3@67 348 cross and parallel). All the products not involving the polarization
ulalume3@67 349 channels *DO NOT* need any modification and should work in the SCC v4.0
ulalume3@67 350 exactly as they did in SCC v3.11. In the example above the aerosol
ulalume3@67 351 extinction and backscatter coefficient at 355nm, the extinction at 532nm
ulalume3@67 352 as well as the backscatter coefficient at 1064nm do not required any
ulalume3@67 353 modification. Let's focus on the modifications needed for the
ulalume3@67 354 calculation of backscatter at 532nm.
ulalume3@67 355
ulalume3@67 356 |image0| How to select signal types
ulalume3@67 357
ulalume3@67 358 The first modification concerns the settings of the channel type for the
ulalume3@67 359 532 cross and 532 parallel polarization channels. Starting from SCC v4.0
ulalume3@67 360 polarization channels are identified as transmitted and reflected
ulalume3@67 361 polarization channels and not on the base of their polarization state.
ulalume3@67 362 So suppose if we suppose the cross polarized channel is transmitted by a
ulalume3@67 363 polarizer beam splitter cube and the parallel is reflected the value
ulalume3@67 364 reported in table 3.1 should be modified as they appear in table 3.2. So
ulalume3@67 365 using the SCC web interface, the signal type of the 532 cross channel
ulalume3@67 366 should be changed from elCP to elPT and and in the same way the 532
ulalume3@67 367 parallel channel should be changed from elPP to elPR (see figure 3.1).
ulalume3@67 368
ulalume3@67 369 **Table 3.2:** The same of table 3.1 but with new channel types
ulalume3@67 370 introduced in SCC v4.0
ulalume3@67 371
ulalume3@67 372 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 373 | Channel Name | Channel ID | Channel Type | nighttime | daytime |
ulalume3@67 374 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 375 | 355 | 1 | elT |  |  |
ulalume3@67 376 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 377 | 387 | 2 | vrRN2 |  | |
ulalume3@67 378 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 379 | 532 cross | 3 | **elPT** |  |  |
ulalume3@67 380 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 381 | 532 parallel | 4 | **elPR** |  |  |
ulalume3@67 382 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 383 | 607 | 5 | vrRN2 |  | |
ulalume3@67 384 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 385 | 1064 | 6 | elT |  |  |
ulalume3@67 386 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 387
ulalume3@67 388 The other change about the polarization channels required to run the SCC
ulalume3@67 389 v4.0 is the definition of the polarization crosstalk parameters for all
ulalume3@67 390 the polarization channels available. Such parameters can be defined for
ulalume3@67 391 each polarization channel using the SCC web interface (see figure 3.2).
ulalume3@67 392 In particular among the channel parameters there is a new tab called
ulalume3@67 393 *Polarization crosstalk parameters* where it is possible to insert the
ulalume3@67 394 values from for the parameters *G* and *H* and the corresponding
ulalume3@67 395 statistical and systematic errors if available. In case you have
ulalume3@67 396 measured *G* and *H* for your polarization channels please insert the
ulalume3@67 397 corresponding values there. Otherwise you can insert the ideal values as
ulalume3@67 398 reported in table 1.1.
ulalume3@67 399
ulalume3@67 400 |image1| *Polarization crosstalk parameters* tab in channel properties
ulalume3@67 401 (SCC v4.0).
ulalume3@67 402
ulalume3@67 403 Definition of new calibration configuration and product
ulalume3@67 404 -------------------------------------------------------
ulalume3@67 405
ulalume3@67 406 In this section we will see how to set the polarization calibration
ulalume3@67 407 parameters: the calibration constant (called h\ :sup:`\*` in section
ulalume3@67 408 1.3) and the correction to calibration constant (called K in section
ulalume3@67 409 1.3).
ulalume3@67 410
ulalume3@67 411 In order to provide such parameters you need to define a new system
ulalume3@67 412 configuration to be used *only* for calibration purposes. Such new
ulalume3@67 413 configuration should include the polarization channels in the
ulalume3@67 414 measurement configuration used for the calibration. Let's suppose we
ulalume3@67 415 want to use the D90 calibration method.
ulalume3@67 416
ulalume3@67 417 In this case we need to define a new configuration (called for example
ulalume3@67 418 “depol\_calibration”) as reported in the table 3.3. As you can see the
ulalume3@67 419 configuration “depol\_calibration” includes 4 “new” channels. Actually
ulalume3@67 420 the channels “532 cross +45 degrees” (channel ID=10) and “532 cross -45
ulalume3@67 421 degrees” (channel ID=12) refer to the same physical channel “532 cross”
ulalume3@67 422 reported with channel ID=3 in table 3.2. Anyway we need to define two
ulalume3@67 423 new channel IDs to identify the “532 cross” channel in the two
ulalume3@67 424 polarization rotated configurations (+45 and -45 degrees) needed to
ulalume3@67 425 apply the D90 calibration method. The same is true for the “532
ulalume3@67 426 parallel” channel. The polarization rotated channels should be labeled
ulalume3@67 427 with the corresponding signal type as reported in table 3.3 (see figure
ulalume3@67 428 3.1).
ulalume3@67 429
ulalume3@67 430 **Table 3.3:** Polarization calibration configurations assuming D90
ulalume3@67 431 calibration method
ulalume3@67 432
ulalume3@67 433 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 434 | Channel Name | Channel ID | Channel Type | depol\_calibration |
ulalume3@67 435 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 436 | 532 cross +45 degrees | 10 | +45elPT |  |
ulalume3@67 437 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 438 | 532 parallel +45 degrees | 11 | +45elPR |  |
ulalume3@67 439 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 440 | 532 cross -45 degrees | 12 | -45elPT |  |
ulalume3@67 441 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 442 | 532 parallel -45 degrees | 13 | -45elPR |  |
ulalume3@67 443 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 444
ulalume3@67 445 Finally we should add to the configuration “depol\_calibration” a
ulalume3@67 446 product “\ *Linear polarization calibration”* to be used for the
ulalume3@67 447 calibration. According to the example given above and to the usecase
ulalume3@67 448 document attached we should use an usecase=4 for this example.
ulalume3@67 449
ulalume3@67 450 Other “\ *Linear polarization calibration”* options to be specified are
ulalume3@67 451 reported in figure 3.3. The most important factor you should insert here
ulalume3@67 452 is the *Pol calibration correction factor* (K). The ideal value for this
ulalume3@67 453 parameter is 1. Anyway if you have measured the parameter K please fill
ulalume3@67 454 in the measured value and the corresponding measurement errors.
ulalume3@67 455
ulalume3@67 456 |image2| Options for *Linear polarization calibration product*.
ulalume3@67 457
ulalume3@67 458 As you can see it is possible to fill in only the K correction factor
ulalume3@67 459 and not the calibration constant h\ :sup:`\*`.
ulalume3@67 460
ulalume3@67 461 Actually for a *LIMITED* period of time it will be possible to fill in
ulalume3@67 462 also the constant h\ :sup:`\*` using a temporary tab called
ulalume3@67 463 *Polarization calibration constant*. This has been done to provide the
ulalume3@67 464 users with the possibility to continue to use the SCC even if an
ulalume3@67 465 automatic calibration made by the SCC was not submitted yet. Anyway
ulalume3@67 466 after a transition period it will be *not* possible to provide
ulalume3@67 467 calibration constant using this procedure and the parameter h\ :sup:`\*`
ulalume3@67 468 can be calculated *ONLY* by the SCC as result of the submission of a
ulalume3@67 469 proper calibration raw input dataset. The format of this input file is
ulalume3@67 470 the same as the standard SCC input file. The only difference is that is
ulalume3@67 471 should contain calibration measurements instead of standard
ulalume3@67 472 measurements. Following our example, such file should contain the
ulalume3@67 473 measurement performed at +45 and -45 degrees at 532nm. Also the channel
ulalume3@67 474 IDs in the file should reflect the ones reported in table 3.3.
ulalume3@67 475
ulalume3@67 476 Moreover this raw input file has to contain the variables:
ulalume3@67 477
ulalume3@67 478 *double Pol\_Calib\_Range\_Min(channels)*
ulalume3@67 479
ulalume3@67 480 *double Pol\_Calib\_Range\_Max(channels) *
ulalume3@67 481
ulalume3@67 482 where to specify the altitude ranges in meters in which the polarization
ulalume3@67 483 calibration should be done.
ulalume3@67 484
ulalume3@67 485 According to the table 3.3 this file should be something similar to:
ulalume3@67 486
ulalume3@67 487 dimensions:
ulalume3@67 488
ulalume3@67 489 channels = 4 ;
ulalume3@67 490
ulalume3@67 491 nb\_of\_time\_scales = 1 ;
ulalume3@67 492
ulalume3@67 493 points = 16380 ;
ulalume3@67 494
ulalume3@67 495 scan\_angles = 1 ;
ulalume3@67 496
ulalume3@67 497 time = UNLIMITED ; // (3 currently)
ulalume3@67 498
ulalume3@67 499 variables:
ulalume3@67 500
ulalume3@67 501 int channel\_ID(channels) ;
ulalume3@67 502
ulalume3@67 503 double Background\_Low(channels) ;
ulalume3@67 504
ulalume3@67 505 double Background\_High(channels) ;
ulalume3@67 506
ulalume3@67 507 int id\_timescale(channels) ;
ulalume3@67 508
ulalume3@67 509 double Laser\_Pointing\_Angle(scan\_angles) ;
ulalume3@67 510
ulalume3@67 511 int Molecular\_Calc ;
ulalume3@67 512
ulalume3@67 513 int Laser\_Pointing\_Angle\_of\_Profiles(time, nb\_of\_time\_scales) ;
ulalume3@67 514
ulalume3@67 515 int Raw\_Data\_Start\_Time(time, nb\_of\_time\_scales) ;
ulalume3@67 516
ulalume3@67 517 int Raw\_Data\_Stop\_Time(time, nb\_of\_time\_scales) ;
ulalume3@67 518
ulalume3@67 519 int Laser\_Shots(time, channels) ;
ulalume3@67 520
ulalume3@67 521 double Raw\_Lidar\_Data(time, channels, points) ;
ulalume3@67 522
ulalume3@67 523 double Pressure\_at\_Lidar\_Station ;
ulalume3@67 524
ulalume3@67 525 double Temperature\_at\_Lidar\_Station ;
ulalume3@67 526
ulalume3@67 527 double Pol\_Calib\_Range\_Min(channels) ;
ulalume3@67 528
ulalume3@67 529 double Pol\_Calib\_Range\_Max(channels) ;
ulalume3@67 530
ulalume3@67 531 // global attributes:
ulalume3@67 532
ulalume3@67 533 :System = "mysystem" ;
ulalume3@67 534
ulalume3@67 535 :Longitude\_degrees\_east = 15.723771 ;
ulalume3@67 536
ulalume3@67 537 :RawData\_Start\_Time\_UT = "220000" ;
ulalume3@67 538
ulalume3@67 539 :RawData\_Start\_Date = "20130620" ;
ulalume3@67 540
ulalume3@67 541 :Measurement\_ID = "20130620po00" ;
ulalume3@67 542
ulalume3@67 543 :Altitude\_meter\_asl = 760. ;
ulalume3@67 544
ulalume3@67 545 :RawData\_Stop\_Time\_UT = "230333" ;
ulalume3@67 546
ulalume3@67 547 :Latitude\_degrees\_north = 40.601039 ;
ulalume3@67 548
ulalume3@67 549 data:
ulalume3@67 550
ulalume3@67 551 channel\_ID = 10, 11, 12, 13 ;
ulalume3@67 552
ulalume3@67 553 Background\_Low = 30000, 30000, 30000, 30000 ;
ulalume3@67 554
ulalume3@67 555 Background\_High = 50000, 50000, 50000, 50000 ;
ulalume3@67 556
ulalume3@67 557 id\_timescale = 0, 0, 0, 0 ;
ulalume3@67 558
ulalume3@67 559 Laser\_Pointing\_Angle = 0 ;
ulalume3@67 560
ulalume3@67 561 Molecular\_Calc = 0 ;
ulalume3@67 562
ulalume3@67 563 Laser\_Pointing\_Angle\_of\_Profiles =
ulalume3@67 564
ulalume3@67 565 0,
ulalume3@67 566
ulalume3@67 567 0,
ulalume3@67 568
ulalume3@67 569 0 ;
ulalume3@67 570
ulalume3@67 571 Raw\_Data\_Start\_Time =
ulalume3@67 572
ulalume3@67 573 0,
ulalume3@67 574
ulalume3@67 575 300,
ulalume3@67 576
ulalume3@67 577 600 ;
ulalume3@67 578
ulalume3@67 579 Raw\_Data\_Stop\_Time =
ulalume3@67 580
ulalume3@67 581 210,
ulalume3@67 582
ulalume3@67 583 510,
ulalume3@67 584
ulalume3@67 585 810 ;
ulalume3@67 586
ulalume3@67 587 Laser\_Shots =
ulalume3@67 588
ulalume3@67 589 1200, 1200, 1200, 1200,
ulalume3@67 590
ulalume3@67 591 1200, 1200, 1200, 1200,
ulalume3@67 592
ulalume3@67 593 1200, 1200, 1200, 1200 ;
ulalume3@67 594
ulalume3@67 595 Pressure\_at\_Lidar\_Station = 1010 ;
ulalume3@67 596
ulalume3@67 597 Temperature\_at\_Lidar\_Station = 14 ;
ulalume3@67 598
ulalume3@67 599 Pol\_Calib\_Range\_Min = 1000, 1000, 1000, 1000 ;
ulalume3@67 600
ulalume3@67 601 Pol\_Calib\_Range\_Min = 2000, 2000, 2000, 2000 ;
ulalume3@67 602
ulalume3@67 603 Raw\_Lidar\_Data = …...;
ulalume3@67 604
ulalume3@67 605 The file above assume the following calibration measurements have been
ulalume3@67 606 done:
ulalume3@67 607
ulalume3@67 608 1. First +45 degrees acquisition followed by a corresponding -45 degrees
ulalume3@67 609 acquisition
ulalume3@67 610
ulalume3@67 611 a. Measurement at +45 degrees
ulalume3@67 612
ulalume3@67 613 Start Time: 20130620 22:00:00
ulalume3@67 614
ulalume3@67 615 Stop Time: 20130620 22:01:00
ulalume3@67 616
ulalume3@67 617 Shots: 1200
ulalume3@67 618
ulalume3@67 619 a. Measurement at -45 degrees
ulalume3@67 620
ulalume3@67 621 Start Time: 20130620 22:02:30
ulalume3@67 622
ulalume3@67 623 Stop Time: 20130620 22:03:30
ulalume3@67 624
ulalume3@67 625 Shots: 1200
ulalume3@67 626
ulalume3@67 627 1. Second +45 degrees acquisition followed by a corresponding -45
ulalume3@67 628 degrees acquisition
ulalume3@67 629
ulalume3@67 630 a. Measurement at +45 degrees
ulalume3@67 631
ulalume3@67 632 Start Time: 20130620 22:05:00
ulalume3@67 633
ulalume3@67 634 Stop Time: 20130620 22:06:00
ulalume3@67 635
ulalume3@67 636 Shots: 1200
ulalume3@67 637
ulalume3@67 638 a. Measurement at -45 degrees
ulalume3@67 639
ulalume3@67 640 Start Time: 20130620 22:07:30
ulalume3@67 641
ulalume3@67 642 Stop Time: 20130620 22:08:30
ulalume3@67 643
ulalume3@67 644 Shots: 1200
ulalume3@67 645
ulalume3@67 646 1. Third +45 degrees acquisition followed by a corresponding -45 degrees
ulalume3@67 647 acquisition
ulalume3@67 648
ulalume3@67 649 a. Measurement at +45 degrees
ulalume3@67 650
ulalume3@67 651 Start Time: 20130620 22:10:00
ulalume3@67 652
ulalume3@67 653 Stop Time: 20130620 22:11:00
ulalume3@67 654
ulalume3@67 655 Shots: 1200
ulalume3@67 656
ulalume3@67 657 a. Measurement at -45 degrees
ulalume3@67 658
ulalume3@67 659 Start Time: 20130620 22:12:30
ulalume3@67 660
ulalume3@67 661 Stop Time: 20130620 22:13:30
ulalume3@67 662
ulalume3@67 663 Shots: 1200
ulalume3@67 664
ulalume3@67 665 As you can see there are 3 cycles of consecutive measurements at +45 and
ulalume3@67 666 -45 degrees. That's way the dimension time is set to 3.
ulalume3@67 667
ulalume3@67 668 The first +/-45 degrees measurement starts at “20130620 22:00:00” (start
ulalume3@67 669 time of the first +45 measurement) and stops at “20130620 22:03:30”
ulalume3@67 670 (stop time of the fist -45 measurement). As a consequence, according to
ulalume3@67 671 the values of the global attributes RawData\_Start\_Date and
ulalume3@67 672 RawData\_Start\_Time\_UT we have to set:
ulalume3@67 673
ulalume3@67 674 Raw\_Data\_Start\_Time[0]=0 (start of the first +45 measurement in
ulalume3@67 675 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 676
ulalume3@67 677 Raw\_Data\_Stop\_Time[0]=210 (stop of the first -45 measurement in
ulalume3@67 678 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 679
ulalume3@67 680 Following a similar procedure for the other 2 cycles we have:
ulalume3@67 681
ulalume3@67 682 Raw\_Data\_Start\_Time[1]=300 (start of the second +45 measurement in
ulalume3@67 683 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 684
ulalume3@67 685 Raw\_Data\_Stop\_Time[1]=510 (stop of the second -45 measurement in
ulalume3@67 686 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 687
ulalume3@67 688 Raw\_Data\_Start\_Time[2]=600 (start of the third +45 measurement in
ulalume3@67 689 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 690
ulalume3@67 691 Raw\_Data\_Stop\_Time[2]=810 (stop of the third -45 measurement in
ulalume3@67 692 seconds since RawData\_Start\_Time\_UT)
ulalume3@67 693
ulalume3@67 694 Moreover, according to the order of the channels in the channel\_ID
ulalume3@67 695 variable, the Raw\_Lidar\_Data array should be filled as it follows:
ulalume3@67 696
ulalume3@67 697 Raw\_Lidar\_Data[0][0][points] → 1\ :sup:`st` measured transmitted
ulalume3@67 698 signal at +45 degrees
ulalume3@67 699
ulalume3@67 700 Raw\_Lidar\_Data[0][1][points] → 1\ :sup:`st` measured reflected signal
ulalume3@67 701 at +45 degrees
ulalume3@67 702
ulalume3@67 703 Raw\_Lidar\_Data[0][2][points] → 1\ :sup:`st` measured transmitted
ulalume3@67 704 signal at -45 degrees
ulalume3@67 705
ulalume3@67 706 Raw\_Lidar\_Data[0][3][points] → 1\ :sup:`st` measured reflected signal
ulalume3@67 707 at -45 degrees
ulalume3@67 708
ulalume3@67 709 Raw\_Lidar\_Data[1][0][points] → 2\ :sup:`nd` measured transmitted
ulalume3@67 710 signal at +45 degrees
ulalume3@67 711
ulalume3@67 712 Raw\_Lidar\_Data[1][1][points] → 2\ :sup:`nd` measured reflected signal
ulalume3@67 713 at +45 degrees
ulalume3@67 714
ulalume3@67 715 Raw\_Lidar\_Data[1][2][points] → 2\ :sup:`nd` measured transmitted
ulalume3@67 716 signal at -45 degrees
ulalume3@67 717
ulalume3@67 718 Raw\_Lidar\_Data[1][3][points] → 2\ :sup:`nd` measured reflected signal
ulalume3@67 719 at -45 degrees
ulalume3@67 720
ulalume3@67 721 Raw\_Lidar\_Data[2][0][points] → 3\ :sup:`rd` measured transmitted
ulalume3@67 722 signal at +45 degrees
ulalume3@67 723
ulalume3@67 724 Raw\_Lidar\_Data[2][1][points] → 3\ :sup:`rd` measured reflected signal
ulalume3@67 725 at +45 degrees
ulalume3@67 726
ulalume3@67 727 Raw\_Lidar\_Data[2][2][points] → 3\ :sup:`rd` measured transmitted
ulalume3@67 728 signal at -45 degrees
ulalume3@67 729
ulalume3@67 730 Raw\_Lidar\_Data[2][3][points] → 3\ :sup:`rd` measured reflected signal
ulalume3@67 731 at -45 degrees
ulalume3@67 732
ulalume3@67 733 Once this file has been created it needs to be submitted to the SCC and
ulalume3@67 734 linked to the configuration “depol\_calibration”. The result of the SCC
ulalume3@67 735 analysis on this file will be the calculation of the calibration
ulalume3@67 736 constant h\ :sup:`\*` that will be logged into the SCC database and can
ulalume3@67 737 be used to calibrate Raman/Elastic backscat ter products (see section
ulalume3@67 738 3.3).
ulalume3@67 739
ulalume3@67 740 **Definition of “Raman/Elastic backscatter and linear depolarization ratio”**
ulalume3@67 741 -----------------------------------------------------------------------------
ulalume3@67 742
ulalume3@67 743 In order to calculate the *PLDR* we need to modify the polarization
ulalume3@67 744 related products linked to the “standard” measurement configurations
ulalume3@67 745 (the configuration called “nighttime” and/or “daytime” in table 3.2).
ulalume3@67 746
ulalume3@67 747 Let's suppose we have defined the following products (defined already in
ulalume3@67 748 SCC v3.11):
ulalume3@67 749
ulalume3@67 750 **Table 3.4:** Example of products configuration in SCC v3.11
ulalume3@67 751
ulalume3@67 752 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 753 | Product Name | Product ID | Product Type | nighttime | daytime |
ulalume3@67 754 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 755 | Raman backscatter | 1 | Raman backscatter |  | |
ulalume3@67 756 | | | | | |
ulalume3@67 757 | 355nm | | | | |
ulalume3@67 758 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 759 | Extinction | 2 | Extinction |  | |
ulalume3@67 760 | | | | | |
ulalume3@67 761 | 387nm | | | | |
ulalume3@67 762 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 763 | Raman backscatter | 3 | Raman backscatter |  | |
ulalume3@67 764 | | | | | |
ulalume3@67 765 | 532nm | | | | |
ulalume3@67 766 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 767 | Extinction | 4 | Extinction |  | |
ulalume3@67 768 | | | | | |
ulalume3@67 769 | 532nm | | | | |
ulalume3@67 770 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 771 | Elastic backscatter | 5 | Elastic backscatter | |  |
ulalume3@67 772 | | | | | |
ulalume3@67 773 | 355nm | | | | |
ulalume3@67 774 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 775 | Elastic backscatter | 6 | Elastic backscatter | |  |
ulalume3@67 776 | | | | | |
ulalume3@67 777 | 532nm | | | | |
ulalume3@67 778 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 779 | Elastic backscatter | 7 | Elastic backscatter |  |  |
ulalume3@67 780 | | | | | |
ulalume3@67 781 | 1064nm | | | | |
ulalume3@67 782 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 783
ulalume3@67 784 Product ID=1, 2, 4, 5, 7 do not need any modification as they do not
ulalume3@67 785 involve polarization channels. The only product that need to be modified
ulalume3@67 786 are the Product ID=3 and 6. To produce b532 files containing also *PLDR*
ulalume3@67 787 we need to modify the “nighttime” and “daytime” configurations to
ulalume3@67 788 include a product of type “Raman bakscatter and linear depolarization
ulalume3@67 789 ratio” or “Elastic bakscatter and linear depolarization ratio”
ulalume3@67 790 respectively. So the configuration reported in table 3.4 should be
ulalume3@67 791 changed to match what is included in table 3.5.
ulalume3@67 792
ulalume3@67 793 **Table 3.5:** The same of table 3.4 but with new product types
ulalume3@67 794 introduced in SCC v4.0
ulalume3@67 795
ulalume3@67 796 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 797 | Product Name | Product ID | Product Type | nighttime | daytime |
ulalume3@67 798 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 799 | Raman backscatter | 1 | Raman backscatter |  | |
ulalume3@67 800 | | | | | |
ulalume3@67 801 | 355nm | | | | |
ulalume3@67 802 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 803 | Extinction | 2 | Extinction |  | |
ulalume3@67 804 | | | | | |
ulalume3@67 805 | 387nm | | | | |
ulalume3@67 806 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 807 | Raman backscatter | 10 | **Raman backscatter and linear depolarization ratio** |  | |
ulalume3@67 808 | | | | | |
ulalume3@67 809 | 532nm | | | | |
ulalume3@67 810 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 811 | Extinction | 4 | Extinction |  | |
ulalume3@67 812 | | | | | |
ulalume3@67 813 | 532nm | | | | |
ulalume3@67 814 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 815 | Elastic backscatter | 5 | Elastic backscatter | |  |
ulalume3@67 816 | | | | | |
ulalume3@67 817 | 355nm | | | | |
ulalume3@67 818 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 819 | Elastic backscatter | 11 | **Elastic backscatter and linear depolarization ratio** | |  |
ulalume3@67 820 | | | | | |
ulalume3@67 821 | 532nm | | | | |
ulalume3@67 822 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 823 | Elastic backscatter | 7 | Elastic backscatter |  |  |
ulalume3@67 824 | | | | | |
ulalume3@67 825 | 1064nm | | | | |
ulalume3@67 826 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 827
ulalume3@67 828 As you can see in table 3.5, the old product IDs=3 and 6 (present in
ulalume3@67 829 table 3.4) have been replaced with the new product ID=10 and 11 to
ulalume3@67 830 guarantee the calculation of *PLDR*.
ulalume3@67 831
ulalume3@67 832 It is important to set among the product options of the product ID=10
ulalume3@67 833 and 11 which calibration product we want to use for calibration (see
ulalume3@67 834 section 3.2). This can be done using the SCC web interface setting the
ulalume3@67 835 appropriate setting in the tab *Polarization calibration products* (see
ulalume3@67 836 figure 3.4). According to the current example you should set here the
ulalume3@67 837 calibration product defined in section 3.2.
ulalume3@67 838
ulalume3@67 839 |image3| How to link a product to calibrate with a calibration product.
ulalume3@67 840
ulalume3@67 841 **WARNING:** Please not that also *Raman/Elastic backscatter products*
ulalume3@67 842 need to be linked to a calibration product because the calibration
ulalume3@67 843 constant and the corresponding correction factor is needed to calculate
ulalume3@67 844 the total signal out of the two polarization components even if the
ulalume3@67 845 *PLDR* is not involved in the product calculation.
ulalume3@67 846
ulalume3@67 847 .. |image0| image:: ./media/image1.png
ulalume3@67 848 :width: 6.69514in
ulalume3@67 849 :height: 2.40764in
ulalume3@67 850 .. |image1| image:: ./media/image2.png
ulalume3@67 851 :width: 6.69306in
ulalume3@67 852 :height: 1.71458in
ulalume3@67 853 .. |image2| image:: ./media/image3.png
ulalume3@67 854 :width: 6.69306in
ulalume3@67 855 :height: 1.77431in
ulalume3@67 856 .. |image3| image:: ./media/image4.png
ulalume3@67 857 :width: 6.69306in
ulalume3@67 858 :height: 0.36389in

mercurial