docs/depolarization/depolarization.rst

Tue, 05 Apr 2022 12:16:26 +0200

author
Giuseppe D'Amico <giuseppe.damico@imaa.cnr.it>
date
Tue, 05 Apr 2022 12:16:26 +0200
changeset 143
5358586fe387
parent 125
003aa42747f5
child 144
72f0d92af2d1
permissions
-rw-r--r--

Added missing variables in HiRELPP product

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@87 6 .. important::
mike@87 7 If your lidar system is not equipped with any polarization channels **NO** changes are required. In this case, the SCC v4.0 should work using the same input files and the same database configurations you have used with the SCC v3.11. Anyway as in the SCC v4.0 several bugs have been fixed, it is recommended to re-run all the measurement IDs you have submitted. For doing that you just need to reprocess all your data without the need to submit raw data files already uploaded on the server.
mike@87 8
mike@68 9 1.1 Background
ulalume3@67 10 --------------
ulalume3@67 11
mike@68 12 The calculation of the volume linear depolarization ratio profile (*VLDR*) and particle linear depolarization ratio profile (*PLDR*) needs two different steps:
ulalume3@67 13
mike@68 14 #. the calibration of the polarization sensitive lidar channels;
mike@68 15 #. the calculation of the *VLDR* or *PLDR* itself.
mike@68 16
mike@87 17 The SCC allows the user to make both the above points. In particular the calibration step is made by a completely new module called **ELDEC** (Earlinet Lidar Depolarization Calibrator) which computes the *apparent calibration factor* :math:`\eta^*` 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 18
mike@68 19 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 20
mike@68 21 New signal types have been introduced to take into account special channel configurations used for calibration purposes.
ulalume3@67 22
mike@68 23 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 24
mike@87 25 #. *Linear polarization calibration (factor* :math:`\eta`) *(product_type_id=6);*
mike@68 26 #. *Raman backscatter and linear depolarization ratio
mike@87 27 (product_type_id=7);*
mike@68 28 #. *Elastic backscatter and linear depolarization ratio
mike@87 29 (product_type_id=8).*
ulalume3@67 30
mike@68 31 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 32
mike@70 33 ::
ulalume3@67 34
mike@68 35 double VolumeDepol(Length) ;
mike@68 36 double ErrorVolumeDepol(Length) ;
mike@87 37 ErrorVolumeDepol:long_name = "absolute error of VolumeDepol" ;
mike@68 38 double ParticleDepol(Length) ;
mike@68 39 double ErrorParticleDepol(Length) ;
mike@87 40 ErrorParticleDepol:long_name = "absolute error of ParticleDepol" ;
ulalume3@67 41
mike@68 42 1.2 Polarization calibration
ulalume3@67 43 ----------------------------
ulalume3@67 44
mike@68 45 An important point is the definition of reliable *PLDR* calibration procedures. Within EARLINET the following calibration procedures are currently used:
ulalume3@67 46
mike@68 47 a) Rayleigh calibration;
mike@87 48 b) +45 calibration method, or :math:`\Delta90` calibration method (made by +45 and -45 measurements);
mike@68 49 c) 3 signals (total, cross and parallel).
ulalume3@67 50
mike@68 51 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 52
mike@68 53 For what it concerns the method c) it, basically, requires to solve the equation:
ulalume3@67 54
mike@68 55 .. math::
mike@68 56 \alpha_s P_s + \alpha_p P_p = P
giuseppe@125 57 :label: eq_totsig
ulalume3@67 58
mike@84 59 in two different 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 60
mike@68 61 1.3 SCC procedure to calculate the PLDRP
mike@68 62 ----------------------------------------
mike@68 63
mike@68 64 According to what mentioned before the SCC calculates the *PLDR* through the following steps:
ulalume3@67 65
mike@87 66 #. 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 67
mike@75 68 #. 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 69
mike@75 70 #. 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 71
mike@77 72 .. 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 73 *elPP→elPR*
ulalume3@67 74
mike@68 75 *elCP→elPT*
ulalume3@67 76
mike@68 77 *elPPnr→elPRnr*
ulalume3@67 78
mike@68 79 *elPPfr→ elPRfr*
ulalume3@67 80
mike@68 81 *elCPnr→ elPTnr*
ulalume3@67 82
mike@68 83 *elCPfr→ elPTfr*
mike@68 84
mike@68 85 Please be sure these modifications reflect to your actual lidar setup(cross channels are transmitted and parallel channels are reflected);
ulalume3@67 86
mike@68 87 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@87 88 #. The file at point 4 is pre-processed by **ELPP** module which applies the standard pre-processing procedures applied to “standard” lidar data;
mike@87 89 #. The pre-processed files are then processed by the new modules **ELDEC** which calculates :math:`\eta^*` *the apparent calibration factor* and logs it into the SCC_DB;
mike@87 90 #. 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@87 91 #. The product defined at point 7 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 92 #. The user needs to submit another SCC raw data file containing the “standard” measurements;
mike@87 93 #. 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 94
mike@87 95 #. 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 96
mike@87 97 The *apparent calibration factor* :math:`\eta^*` is calculated by the **ELDEC** 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 98
mike@68 99 In case of +45 calibration method :math:`\eta^*` is calculated by:
ulalume3@67 100
mike@68 101 .. math::
mike@68 102 \eta^* = \frac{I_R}{I_T}(+45)
giuseppe@125 103 :label: eq_eta1
ulalume3@67 104
mike@87 105 While in case of :math:`\Delta90` calibration method:
ulalume3@67 106
mike@68 107 .. math::
mike@68 108 \eta^* = \sqrt{\frac{I_R}{I_T}(+45) \frac{I_R}{I_T}(-45)}
giuseppe@125 109 :label: eq_eta2
ulalume3@67 110
ulalume3@67 111 **ELDA** module calculates the “apparent” *VLDR*:
ulalume3@67 112
mike@68 113 .. math::
mike@68 114 \delta^* = \frac{K}{\eta^*} \cdot \frac{I_R}{I_T}
giuseppe@125 115 :label: eq_delta1
ulalume3@67 116
ulalume3@67 117 the *VLDR*
ulalume3@67 118
mike@68 119 .. math::
mike@68 120 \delta = \frac{\delta^*(G_T + H_T)-(G_R + H_R)}{(G_R - H_R) - \delta^*(G_T - H_T)}
giuseppe@125 121 :label: eq_delta2
ulalume3@67 122
ulalume3@67 123 and the *PLDR*
ulalume3@67 124
mike@68 125 .. math::
mike@68 126 \delta_{\alpha} = \frac{(1 + \delta_m)\delta R - (1 + \delta)\delta_m}{(1 + \delta_m)R - (1 + \delta)}
giuseppe@125 127 :label: eq_pldr
ulalume3@67 128
ulalume3@67 129 where:
ulalume3@67 130
mike@87 131 - :math:`\eta^*` is the *apparent calibration factor* calculated by **ELDEC**
mike@68 132
mike@68 133 - *K* is the *calibration factor correction* defined as polarization product option
ulalume3@67 134
mike@68 135 - :math:`I_T` and :math:`I_R` are the transmitted and the reflected signals in the polarization detection set-up
ulalume3@67 136
mike@87 137 - :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 138
mike@68 139 - :math:`\delta_m` is the molecular linear depolarization ratio calculated by ELPP
mike@68 140
mike@68 141 - *R* is the backscatter ratio
ulalume3@67 142
mike@68 143 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 144
mike@68 145 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 146
mike@68 147 .. math::
damico@117 148 I_{total} \propto \frac{\frac{\eta^*}{K}H_R I_T - H_T I_R}{H_R G_T - H_T G_R}
giuseppe@125 149 :label: eq_Itot
ulalume3@67 150
mike@68 151 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 152
mike@68 153 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 154
mike@68 155 .. math::
mike@68 156 G_T=1 , \qquad H_T=-1, \qquad G_R=1, \qquad H_R=1
mike@68 157
mike@84 158 If, on the other hand, 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 159
mike@68 160 .. math::
mike@84 161 G_T=1 , \qquad H_T=1, \qquad G_R=1, \qquad H_R=-1
ulalume3@67 162
ulalume3@67 163
mike@68 164 **Table 1.1:** Polarization cross-talk correction parameters for ideal systems
ulalume3@67 165
ulalume3@67 166 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 167 | Laser polarization | Detected in lidar channel |
mike@68 168 + +-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 169 | | Transmitted | Reflected |
mike@68 170 + +-----------------------------+-----------------+-----------------+-----------------+
mike@68 171 | | :math:`G_T` | :math:`H_T` | :math:`G_R` | :math:`H_R` |
ulalume3@67 172 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 173 | total | 1 | 0 | 1 | 0 |
ulalume3@67 174 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
giuseppe@111 175 | parallel | 1 | 1 | 1 | 1 |
ulalume3@67 176 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
giuseppe@111 177 | cross | 1 | -1 | 1 | -1 |
ulalume3@67 178 +----------------------+-----------------------------+-----------------+-----------------+-----------------+
ulalume3@67 179
mike@70 180 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 181
mike@68 182 - :code:`Polarization_Channel_Gain_Factor` (*apparent calibration factor* - :math:`\eta^*` )
mike@68 183 - :code:`Polarization_Channel_Gain_Factor_Correction` (*calib. factor corr.* – *K*)
mike@68 184 - :code:`G_T`
mike@68 185 - :code:`H_T`
mike@68 186 - :code:`G_R`
mike@68 187 - :code:`H_R`
ulalume3@67 188
mike@68 189 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 190
mike@68 191 2. Changes of the SCC input format
mike@68 192 ==================================
ulalume3@67 193
ulalume3@67 194 The following minor changes have been applied to raw SCC data format:
ulalume3@67 195
mike@87 196 #. The optional variable *ID_Range* has been **REMOVED**;
mike@87 197 #. The **OPTIONAL** variable :code:`int Signal_Type(channels)` has been added. The possible values are the same available in the SCC_DB:
ulalume3@67 198
mike@68 199 :code:`0` :math:`\rightarrow` :code:`elT`
ulalume3@67 200
mike@68 201 :code:`1` :math:`\rightarrow` :code:`elTnr`
ulalume3@67 202
mike@68 203 :code:`2` :math:`\rightarrow` :code:`elTfr`
ulalume3@67 204
mike@68 205 :code:`3` :math:`\rightarrow` :code:`vrRN2`
ulalume3@67 206
mike@68 207 :code:`4` :math:`\rightarrow` :code:`vrRN2nr`
ulalume3@67 208
mike@68 209 :code:`5` :math:`\rightarrow` :code:`vrRN2fr`
ulalume3@67 210
mike@68 211 :code:`6` :math:`\rightarrow` :code:`elPR`
ulalume3@67 212
mike@68 213 :code:`7` :math:`\rightarrow` :code:`elPT`
ulalume3@67 214
mike@68 215 :code:`8` :math:`\rightarrow` :code:`pRRlow`
ulalume3@67 216
mike@68 217 :code:`9` :math:`\rightarrow` :code:`pRRhigh`
ulalume3@67 218
mike@68 219 :code:`10` :math:`\rightarrow` :code:`elPRnr`
ulalume3@67 220
mike@68 221 :code:`11` :math:`\rightarrow` :code:`elPRfr`
ulalume3@67 222
mike@68 223 :code:`12` :math:`\rightarrow` :code:`elPTnr`
ulalume3@67 224
mike@68 225 :code:`13` :math:`\rightarrow` :code:`elPTfr`
ulalume3@67 226
mike@68 227 :code:`14` :math:`\rightarrow` :code:`vrRH2O`
ulalume3@67 228
mike@68 229 :code:`15` :math:`\rightarrow` :code:`pRRhighnr`
ulalume3@67 230
mike@68 231 :code:`16` :math:`\rightarrow` :code:`pRRhighfr`
ulalume3@67 232
mike@68 233 :code:`17` :math:`\rightarrow` :code:`pRRlownr`
ulalume3@67 234
mike@68 235 :code:`18` :math:`\rightarrow` :code:`pRRlowfr`
ulalume3@67 236
mike@68 237 :code:`19` :math:`\rightarrow` :code:`vrRH2Onr`
ulalume3@67 238
mike@68 239 :code:`20` :math:`\rightarrow` :code:`vrRH2Ofr`
ulalume3@67 240
mike@68 241 :code:`21` :math:`\rightarrow` :code:`elTunr`
ulalume3@67 242
mike@68 243 :code:`22` :math:`\rightarrow` :code:`+45elPT`
ulalume3@67 244
mike@68 245 :code:`23` :math:`\rightarrow` :code:`+45elPR`
ulalume3@67 246
mike@68 247 :code:`24` :math:`\rightarrow` :code:`-45elPT`
ulalume3@67 248
mike@68 249 :code:`25` :math:`\rightarrow` :code:`-45elPR`
ulalume3@67 250
mike@68 251 :code:`26` :math:`\rightarrow` :code:`+45elPTnr`
ulalume3@67 252
mike@68 253 :code:`27` :math:`\rightarrow` :code:`+45elPTfr`
ulalume3@67 254
mike@68 255 :code:`28` :math:`\rightarrow` :code:`+45elPRnr`
mike@68 256
mike@68 257 :code:`29` :math:`\rightarrow` :code:`+45elPRfr`
ulalume3@67 258
mike@68 259 :code:`30` :math:`\rightarrow` :code:`-45elPTnr`
ulalume3@67 260
mike@68 261 :code:`31` :math:`\rightarrow` :code:`-45elPTfr`
ulalume3@67 262
mike@68 263 :code:`32` :math:`\rightarrow` :code:`-45elPRnr`
ulalume3@67 264
mike@68 265 :code:`33` :math:`\rightarrow` :code:`-45elPRfr`
ulalume3@67 266
mike@84 267 .. warning:: 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 268
mike@68 269 3. The variables:
ulalume3@67 270
mike@70 271 ::
mike@68 272
mike@87 273 double Pol_Calib_Range_Min(channels)
mike@87 274 double Pol_Calib_Range_Max(channels)
ulalume3@67 275
mike@75 276 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 277
mike@75 278 4. The variable :code:`Depolarization_Factor` has been **REMOVED**.
ulalume3@67 279
mike@68 280 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 281
mike@75 282 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 283
mike@77 284 .. warning:: After this transition period **ONLY** automatic calibration will be allowed!
ulalume3@67 285
mike@75 286 5. The new **OPTIONAL** variable:
ulalume3@67 287
mike@87 288 :code:`string channel_string_ID(channels)`
ulalume3@67 289
mike@68 290 has been introduced.
mike@68 291
mike@68 292 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 293
mike@68 294 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 295
mike@77 296 .. 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 297
mike@70 298 3. Real Example
mike@70 299 ===============
ulalume3@67 300
mike@70 301 This section describes all the practical steps the users need to follow to switch from SCC v3.11 to new SCC v4.0.
mike@70 302
mike@70 303 :IMPORTANT:
mike@75 304 If your lidar system is not equipped with any polarization channels **NO** changes are required. In this case, the SCC v4.0 should work using the same input files and the same database configurations you have used with the SCC v3.11. Anyway as in the SCC v4.0 several bugs have been fixed,it is recommended to re-run all the measurement IDs you have submitted. For doing that you just need to reprocess all your data without the need to submit raw data files already uploaded on the server.
ulalume3@67 305
mike@87 306 The practical example reported below describes the modifications required to use the SCC v4.0 for lidar systems equipped with polarization channels. Lidar systems not equipped with polarization channels do not require any modification to switch to SCC v4.0.
ulalume3@67 307
mike@70 308 3.1 Modification of polarization channel parameters
mike@70 309 ---------------------------------------------------
ulalume3@67 310
mike@70 311 In what it follows it is assumed you already have registered one or more lidar configurations in the SCC database and that such configurations have been already used to produce optical products (aerosol extinction and/or backscatter coefficients) by means of the SCC v3.11.
ulalume3@67 312
mike@70 313 Let's assume your 3+2 system is registered in the SCC database and the settings used by the SCC v3.11 are the ones summarized in table 3.1.
ulalume3@67 314
mike@70 315 :Table 3.1: Example of configuration in SCC v3.11
ulalume3@67 316
ulalume3@67 317 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 318 | Channel Name | Channel ID | Channel Type | nighttime | daytime |
ulalume3@67 319 +----------------+--------------+----------------+-------------+-----------+
mike@70 320 | 355 | 1 | elT | x | x |
ulalume3@67 321 +----------------+--------------+----------------+-------------+-----------+
mike@70 322 | 387 | 2 | vrRN2 | x | |
ulalume3@67 323 +----------------+--------------+----------------+-------------+-----------+
mike@70 324 | 532 cross | 3 | elCP | x | x |
ulalume3@67 325 +----------------+--------------+----------------+-------------+-----------+
mike@70 326 | 532 parallel | 4 | elPP | x | x |
ulalume3@67 327 +----------------+--------------+----------------+-------------+-----------+
mike@70 328 | 607 | 5 | vrRN2 | x | |
ulalume3@67 329 +----------------+--------------+----------------+-------------+-----------+
mike@70 330 | 1064 | 6 | elT | x | x |
ulalume3@67 331 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 332
mike@70 333 We assume there are 2 system configurations called “nighttime” and “daytime”. The nighttime configuration contains all the available lidar channels (in order to calculate, for example, the aerosol extinction at 355 and 532nm and the aerosol backscatter at 355, 532 and 1064nm) while in daytime conditions only elastic channels are used (only elastic backscatter coefficients are generated).
mike@70 334
mike@75 335 To make these settings working with SCC v4.0 it is needed to modify :underline:ONLY` the products properties involving the polarization channels (532 cross and parallel). All the products not involving the polarization channels **DO NOT** need any modification and should work in the SCC v4.0 exactly as they did in SCC v3.11. In the example above the aerosol extinction and backscatter coefficient at 355nm, the extinction at 532nm as well as the backscatter coefficient at 1064nm do not required any
mike@70 336 modification. Let's focus on the modifications needed for the calculation of backscatter at 532nm.
ulalume3@67 337
ulalume3@73 338 .. figure:: media/figure3.1.png
mike@70 339 :height: 369
mike@70 340 :width: 1037
mike@70 341 :scale: 100 %
mike@70 342 :align: center
ulalume3@67 343
mike@70 344 **Figure 3.1**: How to select signal types
ulalume3@67 345
mike@84 346 The first modification concerns the settings of the channel type for the 532 cross and 532 parallel polarization channels. Starting from SCC v4.0 polarization channels are identified as transmitted and reflected polarization channels and not on the base of their polarization state. So if we suppose that the cross polarized channel is transmitted by a polarizer beam splitter cube, and the parallel is reflected, the value reported in table 3.1 should be modified as they appear in table 3.2. So using the SCC web interface, the signal type of the 532 cross channel should be changed from :code:`elCP` to :code:`elPT` and in the same way the 532 parallel channel should be changed from :code:`elPP` to :code:`elPR` (see figure 3.1).
ulalume3@67 347
ulalume3@67 348 **Table 3.2:** The same of table 3.1 but with new channel types
ulalume3@67 349 introduced in SCC v4.0
ulalume3@67 350
ulalume3@67 351 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 352 | Channel Name | Channel ID | Channel Type | nighttime | daytime |
ulalume3@67 353 +----------------+--------------+----------------+-------------+-----------+
mike@70 354 | 355 | 1 | elT | x | x |
ulalume3@67 355 +----------------+--------------+----------------+-------------+-----------+
mike@70 356 | 387 | 2 | vrRN2 | x | |
ulalume3@67 357 +----------------+--------------+----------------+-------------+-----------+
mike@75 358 | 532 cross | 3 | **elPT** | x | x |
ulalume3@67 359 +----------------+--------------+----------------+-------------+-----------+
mike@75 360 | 532 parallel | 4 | **elPR** | x | x |
ulalume3@67 361 +----------------+--------------+----------------+-------------+-----------+
mike@70 362 | 607 | 5 | vrRN2 | x | |
ulalume3@67 363 +----------------+--------------+----------------+-------------+-----------+
mike@70 364 | 1064 | 6 | elT | x | x |
ulalume3@67 365 +----------------+--------------+----------------+-------------+-----------+
ulalume3@67 366
mike@70 367 The other change about the polarization channels required to run the SCC v4.0 is the definition of the polarization crosstalk parameters for all the polarization channels available. Such parameters can be defined for each polarization channel using the SCC web interface (see figure 3.2). In particular among the channel parameters there is a new tab called *Polarization crosstalk parameters* where it is possible to insert the values from for the parameters *G* and *H* and the corresponding statistical and systematic errors if available. In case you have measured *G* and *H* for your polarization channels please insert the corresponding values there. Otherwise you can insert the ideal values as reported in table 1.1.
ulalume3@67 368
ulalume3@74 369 .. figure:: media/figure3.2.png
mike@70 370 :height: 479
mike@70 371 :width: 1890
mike@70 372 :scale: 100 %
mike@70 373 :align: center
ulalume3@67 374
mike@70 375 **Figure 3.2:** Polarization crosstalk parameters tab in channel properties (SCC v4.0).
ulalume3@67 376
mike@70 377 3.2 Definition of new calibration configuration and product
mike@70 378 -----------------------------------------------------------
mike@70 379
mike@78 380 In this section we will see how to set the polarization calibration parameters: the calibration constant (called :math:`\eta^*` in section 1.3) and the correction to calibration constant (called K in section 1.3). In order to provide such parameters you need to define a new system configuration to be used **ONLY** for calibration purposes. Such new configuration should include the polarization channels in the measurement configuration used for the calibration. Let's suppose we want to use the :math:`\Delta90` calibration method.
mike@70 381
mike@87 382 In this case we need to define a new configuration (called for example “depol_calibration”) as reported in the table 3.3. As you can see the configuration “depol_calibration” includes 4 “new” channels. Actually the channels “532 cross +45 degrees” (channel ID=10) and “532 cross -45 degrees” (channel ID=12) refer to the same physical channel “532 cross” reported with channel ID=3 in table 3.2. Anyway we need to define two new channel IDs to identify the “532 cross” channel in the two polarization rotated configurations (+45 and -45 degrees) needed to apply the D90 calibration method. The same is true for the “532 parallel” channel. The polarization rotated channels should be labeled with the corresponding signal type as reported in table 3.3 (see figure
ulalume3@67 383 3.1).
ulalume3@67 384
mike@87 385 **Table 3.3:** Polarization calibration configurations assuming :math:`\Delta90` calibration method
ulalume3@67 386
ulalume3@67 387 +----------------------------+--------------+----------------+----------------------+
mike@70 388 | Channel Name | Channel ID | Channel Type | depol_calibration |
ulalume3@67 389 +----------------------------+--------------+----------------+----------------------+
mike@70 390 | 532 cross +45 degrees | 10 | +45elPT | x |
ulalume3@67 391 +----------------------------+--------------+----------------+----------------------+
mike@70 392 | 532 parallel +45 degrees | 11 | +45elPR | x |
ulalume3@67 393 +----------------------------+--------------+----------------+----------------------+
mike@70 394 | 532 cross -45 degrees | 12 | -45elPT | x |
ulalume3@67 395 +----------------------------+--------------+----------------+----------------------+
mike@70 396 | 532 parallel -45 degrees | 13 | -45elPR | x |
ulalume3@67 397 +----------------------------+--------------+----------------+----------------------+
ulalume3@67 398
mike@70 399 Finally we should add to the configuration “depol_calibration” a product “*Linear polarization calibration”* to be used for the calibration. According to the example given above and to the usecase document attached we should use an usecase=4 for this example.
ulalume3@67 400
mike@70 401 Other “*Linear polarization calibration”* options to be specified are reported in figure 3.3. The most important factor you should insert here is the *Pol calibration correction factor* (K). The ideal value for this parameter is 1. Anyway if you have measured the parameter K please fill in the measured value and the corresponding measurement errors.
ulalume3@67 402
ulalume3@74 403 .. figure:: media/figure3.3.png
mike@70 404 :height: 495
mike@70 405 :width: 1887
mike@70 406 :scale: 100 %
mike@70 407 :align: center
ulalume3@67 408
mike@70 409 **Figure 3.3:** Options for *Linear polarization calibration product*.
mike@70 410
mike@70 411 As you can see it is possible to fill in only the K correction factor and not the calibration constant :math:`\eta^*`.
mike@70 412
mike@87 413 Actually for a **LIMITED** period of time it will be possible to fill in also the constant :math:`\eta^*` using a temporary option shown in figure 3.4. This has been done to provide the users with the possibility to continue to use the SCC even if an automatic calibration made by the SCC was not submitted yet. Anyway after a transition period it will be **NOT** possible to provide calibration constant using this procedure and the parameter :math:`\eta^*` can be calculated **ONLY** by the SCC as result of the submission of a proper calibration raw input dataset. The format of this input file is the same as the standard SCC input file. The only difference is that is should contain calibration measurements instead of standard measurements. Following our example, such file should contain the measurement performed at +45 and -45 degrees at 532nm. Also the channel IDs in the file should reflect the ones reported in table 3.3.
ulalume3@67 414
ulalume3@67 415 Moreover this raw input file has to contain the variables:
mike@70 416 ::
ulalume3@67 417
mike@70 418 double Pol_Calib_Range_Min(channels)
mike@87 419 double Pol_Calib_Range_Max(channels)
ulalume3@67 420
mike@70 421 where to specify the altitude ranges in meters in which the polarization calibration should be done.
ulalume3@67 422
mike@87 423 .. figure:: media/figure3.4.png
mike@87 424 :height: 806
mike@87 425 :width: 1896
mike@87 426 :scale: 100 %
mike@87 427 :align: center
mike@87 428
mike@87 429 **Figure 3.4:** To provide polarization calibration (:math:`\eta^*`) values manually just use the button “Add polarization calibration” in the upper-right corner. This option will be available only for a limited period of time. After that only SCC calculated calibration constants will be accepted.
mike@87 430
ulalume3@67 431 According to the table 3.3 this file should be something similar to:
mike@70 432 ::
ulalume3@67 433
mike@70 434 dimensions:
mike@70 435 channels = 4 ;
mike@87 436 nb_of_time_scales = 1 ;
mike@70 437 points = 16380 ;
mike@87 438 scan_angles = 1 ;
mike@70 439 time = UNLIMITED ; // (3 currently)
mike@70 440 variables:
mike@87 441 int channel_ID(channels) ;
mike@87 442 double Background_Low(channels) ;
mike@87 443 double Background_High(channels) ;
mike@87 444 int id_timescale(channels) ;
mike@87 445 double Laser_Pointing_Angle(scan_angles) ;
mike@87 446 int Molecular_Calc ;
mike@87 447 int Laser_Pointing_Angle_of_Profiles(time, nb_of_time_scales) ;
mike@87 448 int Raw_Data_Start_Time(time, nb_of_time_scales) ;
mike@87 449 int Raw_Data_Stop_Time(time, nb_of_time_scales) ;
mike@87 450 int Laser_Shots(time, channels) ;
mike@87 451 double Raw_Lidar_Data(time, channels, points) ;
mike@87 452 double Pressure_at_Lidar_Station ;
mike@87 453 double Temperature_at_Lidar_Station ;
mike@87 454 double Pol_Calib_Range_Min(channels) ;
mike@87 455 double Pol_Calib_Range_Max(channels) ;
ulalume3@67 456
mike@70 457 // global attributes:
mike@70 458 :System = "mysystem" ;
mike@87 459 :Longitude_degrees_east = 15.723771 ;
mike@87 460 :RawData_Start_Time_UT = "220000" ;
mike@87 461 :RawData_Start_Date = "20130620" ;
mike@87 462 :Measurement_ID = "20130620po00" ;
mike@87 463 :Altitude_meter_asl = 760. ;
mike@87 464 :RawData_Stop_Time_UT = "230333" ;
mike@87 465 :Latitude_degrees_north = 40.601039 ;
ulalume3@67 466
mike@70 467 data:
mike@87 468 channel_ID = 10, 11, 12, 13 ;
ulalume3@67 469
mike@87 470 Background_Low = 30000, 30000, 30000, 30000 ;
ulalume3@67 471
mike@87 472 Background_High = 50000, 50000, 50000, 50000 ;
ulalume3@67 473
mike@87 474 id_timescale = 0, 0, 0, 0 ;
ulalume3@67 475
mike@87 476 Laser_Pointing_Angle = 0 ;
ulalume3@67 477
mike@87 478 Molecular_Calc = 0 ;
ulalume3@67 479
mike@87 480 Laser_Pointing_Angle_of_Profiles =
mike@70 481 0,
mike@70 482 0,
mike@70 483 0 ;
ulalume3@67 484
mike@87 485 Raw_Data_Start_Time =
mike@70 486 0,
mike@70 487 300,
mike@70 488 600 ;
ulalume3@67 489
mike@87 490 Raw_Data_Stop_Time =
mike@70 491 210,
mike@70 492 510,
mike@70 493 810 ;
ulalume3@67 494
mike@87 495 Laser_Shots =
mike@70 496 1200, 1200, 1200, 1200,
mike@70 497 1200, 1200, 1200, 1200,
mike@70 498 1200, 1200, 1200, 1200 ;
ulalume3@67 499
mike@87 500 Pressure_at_Lidar_Station = 1010 ;
ulalume3@67 501
mike@87 502 Temperature_at_Lidar_Station = 14 ;
ulalume3@67 503
mike@87 504 Pol_Calib_Range_Min = 1000, 1000, 1000, 1000 ;
ulalume3@67 505
mike@87 506 Pol_Calib_Range_Min = 2000, 2000, 2000, 2000 ;
ulalume3@67 507
mike@87 508 Raw_Lidar_Data = …...;
ulalume3@67 509
mike@70 510 The file above assume the following calibration measurements have been done:
ulalume3@67 511
mike@70 512 1. First +45 degrees acquisition followed by a corresponding -45 degrees acquisition
ulalume3@67 513
mike@70 514 a. Measurement at +45 degrees
ulalume3@67 515
mike@70 516 Start Time: 20130620 22:00:00
ulalume3@67 517
mike@70 518 Stop Time: 20130620 22:01:00
ulalume3@67 519
mike@70 520 Shots: 1200
ulalume3@67 521
mike@70 522 b. Measurement at -45 degrees
ulalume3@67 523
mike@70 524 Start Time: 20130620 22:02:30
ulalume3@67 525
mike@70 526 Stop Time: 20130620 22:03:30
ulalume3@67 527
mike@70 528 Shots: 1200
ulalume3@67 529
mike@70 530 2. Second +45 degrees acquisition followed by a corresponding -45 degrees acquisition
ulalume3@67 531
mike@70 532 a. Measurement at +45 degrees
ulalume3@67 533
mike@70 534 Start Time: 20130620 22:05:00
ulalume3@67 535
mike@70 536 Stop Time: 20130620 22:06:00
ulalume3@67 537
mike@70 538 Shots: 1200
ulalume3@67 539
mike@70 540 b. Measurement at -45 degrees
ulalume3@67 541
mike@70 542 Start Time: 20130620 22:07:30
ulalume3@67 543
mike@70 544 Stop Time: 20130620 22:08:30
ulalume3@67 545
mike@70 546 Shots: 1200
ulalume3@67 547
mike@70 548 3. Third +45 degrees acquisition followed by a corresponding -45 degrees acquisition
ulalume3@67 549
mike@70 550 a. Measurement at +45 degrees
ulalume3@67 551
mike@70 552 Start Time: 20130620 22:10:00
ulalume3@67 553
mike@70 554 Stop Time: 20130620 22:11:00
ulalume3@67 555
mike@70 556 Shots: 1200
ulalume3@67 557
mike@70 558 b. Measurement at -45 degrees
ulalume3@67 559
mike@70 560 Start Time: 20130620 22:12:30
ulalume3@67 561
mike@70 562 Stop Time: 20130620 22:13:30
ulalume3@67 563
mike@70 564 Shots: 1200
ulalume3@67 565
mike@70 566 As you can see there are 3 cycles of consecutive measurements at +45 and -45 degrees. That way the dimension :code:`time` is set to 3.
mike@70 567
mike@87 568 The first +/-45 degrees measurement starts at “20130620 22:00:00” (start time of the first +45 measurement) and stops at “20130620 22:03:30” (stop time of the fist -45 measurement). As a consequence, according to the values of the global attributes :code:`RawData_Start_Date` and :code:`RawData_Start_Time_UT` we have to set:
ulalume3@67 569
mike@70 570 :code:`Raw_Data_Start_Time[0]=0` (start of the first +45 measurement in
mike@87 571 seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 572
mike@70 573 :code:`Raw_Data_Stop_Time[0]=210` (stop of the first -45 measurement in
mike@70 574 seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 575
ulalume3@67 576 Following a similar procedure for the other 2 cycles we have:
ulalume3@67 577
mike@70 578 :code:`Raw_Data_Start_Time[1]=300` (start of the second +45 measurement in seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 579
mike@87 580 :code:`Raw_Data_Stop_Time[1]=510` (stop of the second -45 measurement in seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 581
mike@70 582 :code:`Raw_Data_Start_Time[2]=600` (start of the third +45 measurement in seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 583
mike@70 584 :code:`Raw_Data_Stop_Time[2]=810` (stop of the third -45 measurement in seconds since :code:`RawData_Start_Time_UT`)
ulalume3@67 585
mike@70 586 Moreover, according to the order of the channels in the :code:`channel_ID` variable, the :code:`Raw_Lidar_Data` array should be filled as it follows:
ulalume3@67 587
mike@70 588 :code:`Raw_Lidar_Data[0][0][points]` :math:`\rightarrow` 1\ :sup:`st` measured transmitted signal at +45 degrees
ulalume3@67 589
mike@70 590 :code:`Raw_Lidar_Data[0][1][points]` :math:`\rightarrow` 1\ :sup:`st` measured transmitted signal at +45 degrees
ulalume3@67 591
mike@70 592 :code:`Raw_Lidar_Data[0][2][points]` :math:`\rightarrow` 1\ :sup:`st` measured transmitted signal at -45 degrees
ulalume3@67 593
mike@70 594 :code:`Raw_Lidar_Data[0][3][points]` :math:`\rightarrow` 1\ :sup:`st` measured transmitted signal at -45 degrees
ulalume3@67 595
mike@70 596 :code:`Raw_Lidar_Data[1][0][points]` :math:`\rightarrow` 2\ :sup:`nd` measured transmitted signal at +45 degrees
ulalume3@67 597
mike@70 598 :code:`Raw_Lidar_Data[1][1][points]` :math:`\rightarrow` 2\ :sup:`nd` measured transmitted signal at +45 degrees
ulalume3@67 599
mike@70 600 :code:`Raw_Lidar_Data[1][2][points]` :math:`\rightarrow` 2\ :sup:`nd` measured transmitted signal at -45 degrees
ulalume3@67 601
mike@70 602 :code:`Raw_Lidar_Data[1][3][points]` :math:`\rightarrow` 2\ :sup:`nd` measured transmitted signal at -45 degrees
ulalume3@67 603
mike@70 604 :code:`Raw_Lidar_Data[2][0][points]` :math:`\rightarrow` 3\ :sup:`rd` measured transmitted signal at +45 degrees
ulalume3@67 605
mike@70 606 :code:`Raw_Lidar_Data[2][1][points]` :math:`\rightarrow` 3\ :sup:`rd` measured transmitted signal at +45 degrees
ulalume3@67 607
mike@70 608 :code:`Raw_Lidar_Data[2][2][points]` :math:`\rightarrow` 3\ :sup:`rd` measured transmitted signal at -45 degrees
ulalume3@67 609
mike@70 610 :code:`Raw_Lidar_Data[2][3][points]` :math:`\rightarrow` 3\ :sup:`rd` measured transmitted signal at -45 degrees
ulalume3@67 611
mike@87 612 Once this file has been created it needs to be submitted to the SCC and linked to the configuration “depol_calibration”. The result of the SCC analysis on this file will be the calculation of the calibration constant h\ :sup:`\*` that will be logged into the SCC database and can be used to calibrate Raman/Elastic backscatter products (see section 3.3).
mike@70 613
mike@70 614 3.3 Definition of “Raman/Elastic backscatter and linear depolarization ratio”
ulalume3@67 615 -----------------------------------------------------------------------------
ulalume3@67 616
mike@70 617 In order to calculate the *PLDR* we need to modify the polarization related products linked to the “standard” measurement configurations (the configuration called “nighttime” and/or “daytime” in table 3.2).
ulalume3@67 618
mike@70 619 Let's suppose we have defined the following products (defined already in SCC v3.11):
ulalume3@67 620
ulalume3@67 621 **Table 3.4:** Example of products configuration in SCC v3.11
ulalume3@67 622
ulalume3@67 623 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 624 | Product Name | Product ID | Product Type | nighttime | daytime |
ulalume3@67 625 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 626 | Raman backscatter | 1 | Raman backscatter | x | |
ulalume3@67 627 | | | | | |
ulalume3@67 628 | 355nm | | | | |
ulalume3@67 629 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 630 | Extinction | 2 | Extinction | x | |
ulalume3@67 631 | | | | | |
ulalume3@67 632 | 387nm | | | | |
ulalume3@67 633 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 634 | Raman backscatter | 3 | Raman backscatter | x | |
ulalume3@67 635 | | | | | |
ulalume3@67 636 | 532nm | | | | |
ulalume3@67 637 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 638 | Extinction | 4 | Extinction | x | |
ulalume3@67 639 | | | | | |
ulalume3@67 640 | 532nm | | | | |
ulalume3@67 641 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 642 | Elastic backscatter | 5 | Elastic backscatter | | x |
ulalume3@67 643 | | | | | |
ulalume3@67 644 | 355nm | | | | |
ulalume3@67 645 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 646 | Elastic backscatter | 6 | Elastic backscatter | | x |
ulalume3@67 647 | | | | | |
ulalume3@67 648 | 532nm | | | | |
ulalume3@67 649 +-----------------------+--------------+-----------------------+-------------+-----------+
mike@70 650 | Elastic backscatter | 7 | Elastic backscatter | x | x |
ulalume3@67 651 | | | | | |
ulalume3@67 652 | 1064nm | | | | |
ulalume3@67 653 +-----------------------+--------------+-----------------------+-------------+-----------+
ulalume3@67 654
mike@84 655 Product ID=1, 2, 4, 5, 7 do not need any modification as they do not involve polarization channels. The only product that need to be modified are the Product ID=3 and 6. To produce b532 files containing also *PLDR* we need to modify the “nighttime” and “daytime” configurations to include a product of type “Raman backscatter and linear depolarization ratio” or “Elastic bakscatter and linear depolarization ratio” respectively. So the configuration reported in table 3.4 should be
ulalume3@67 656 changed to match what is included in table 3.5.
ulalume3@67 657
mike@70 658 **Table 3.5:** The same of table 3.4 but with new product types introduced in SCC v4.0
ulalume3@67 659
ulalume3@67 660 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 661 | Product Name | Product ID | Product Type | nighttime | daytime |
ulalume3@67 662 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@70 663 | Raman backscatter | 1 | Raman backscatter | x | |
ulalume3@67 664 | | | | | |
ulalume3@67 665 | 355nm | | | | |
ulalume3@67 666 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@70 667 | Extinction | 2 | Extinction | x | |
ulalume3@67 668 | | | | | |
ulalume3@67 669 | 387nm | | | | |
ulalume3@67 670 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@75 671 | Raman backscatter | 10 | **Raman backscatter and linear depolarization ratio** | x | |
ulalume3@67 672 | | | | | |
ulalume3@67 673 | 532nm | | | | |
ulalume3@67 674 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@70 675 | Extinction | 4 | Extinction | x | |
ulalume3@67 676 | | | | | |
ulalume3@67 677 | 532nm | | | | |
ulalume3@67 678 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@70 679 | Elastic backscatter | 5 | Elastic backscatter | | x |
ulalume3@67 680 | | | | | |
ulalume3@67 681 | 355nm | | | | |
ulalume3@67 682 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@75 683 | Elastic backscatter | 11 | **Elastic backscatter and linear depolarization ratio** | | x |
ulalume3@67 684 | | | | | |
ulalume3@67 685 | 532nm | | | | |
ulalume3@67 686 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
mike@70 687 | Elastic backscatter | 7 | Elastic backscatter | x | x |
ulalume3@67 688 | | | | | |
ulalume3@67 689 | 1064nm | | | | |
ulalume3@67 690 +-----------------------+--------------+-----------------------------------------------------------+-------------+-----------+
ulalume3@67 691
mike@70 692 As you can see in table 3.5, the old product IDs=3 and 6 (present in table 3.4) have been replaced with the new product ID=10 and 11 to guarantee the calculation of *PLDR*.
ulalume3@67 693
mike@70 694 It is important to set among the product options of the product ID=10 and 11 which calibration product we want to use for calibration (see section 3.2). This can be done using the SCC web interface setting the appropriate setting in the tab *Polarization calibration products* (see figure 3.4). According to the current example you should set here the calibration product defined in section 3.2.
ulalume3@67 695
mike@87 696 .. figure:: media/figure3.5.png
mike@70 697 :height: 102
mike@70 698 :width: 1895
mike@70 699 :scale: 100 %
mike@70 700 :align: center
ulalume3@67 701
mike@87 702 **Figure 3.5:** How to link a product to calibrate with a calibration product.
mike@70 703
giuseppe@111 704 .. warning:: Please note that also *Raman/Elastic backscatter products* need to be linked to a calibration product because the calibration constant and the corresponding correction factor is needed to calculate the total signal out of the two polarization components even if the *PLDR* is not involved in the product calculation.

mercurial