Thu, 03 Nov 2016 16:27:26 +0200
depolarization.rst : Typos and G, H parameter corrections.
binietoglou@23 | 1 | Frequently asked questions |
binietoglou@23 | 2 | ========================== |
binietoglou@23 | 3 | |
ioannis@39 | 4 | |
ioannis@39 | 5 | Using an ancillary file |
ioannis@39 | 6 | ~~~~~~~~~~~~~~~~~~~~~~~ |
ioannis@39 | 7 | |
ioannis@39 | 8 | Q: I use the “Quick upload” to submit a measurement file together with an ancillary |
ioannis@40 | 9 | file. Will this ancillary file be used in the processing of my measurement. |
ioannis@39 | 10 | |
ioannis@39 | 11 | A: No. Which ancillary file is used when processing a measurement is defined in the |
ioannis@39 | 12 | measurement netcdf file. If your new ancillary file is not mentioned in the measurement |
ioannis@39 | 13 | file, it will not be used. |
ioannis@39 | 14 | |
ioannis@39 | 15 | |
ioannis@39 | 16 | Reusing an ancillary file |
ioannis@39 | 17 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
ioannis@39 | 18 | |
ioannis@39 | 19 | Q: I want to use one ancillary file (ex. an overlap file) in the processing of multiple |
ioannis@39 | 20 | measurements. Do I need to submit it multiple times? |
ioannis@39 | 21 | |
ioannis@39 | 22 | A: No. You just need to define the file name of the file to use in the measurements |
ioannis@39 | 23 | netcdf file. |
ioannis@39 | 24 | |
ioannis@39 | 25 | |
ioannis@39 | 26 | Deleting an ancillary file |
ioannis@39 | 27 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
ioannis@39 | 28 | |
ioannis@39 | 29 | Q: I want to delete an uploaded ancillary file but in the "Admin" interface I can't |
ioannis@39 | 30 | find a "Delete" button. |
ioannis@39 | 31 | |
ioannis@39 | 32 | A: Probably the ancillary file you are trying to delete is needed by some uploaded |
ioannis@39 | 33 | measurement, and for this reason you are not allowed to delete it. You will need |
ioannis@39 | 34 | to delete the corresponding measurements first, before deleting the ancillary file. |
ioannis@39 | 35 | |
ioannis@39 | 36 | |
ioannis@39 | 37 | |
binietoglou@24 | 38 | Clouds in the data |
binietoglou@24 | 39 | ~~~~~~~~~~~~~~~~~~ |
binietoglou@23 | 40 | |
binietoglou@29 | 41 | Q: Is it necessary to provide only measurement periods with cloud free conditions and |
binietoglou@29 | 42 | homogeneous atmosphere or is this part of ELDA or the pre-processing of the data? |
binietoglou@24 | 43 | For example in cases with scattered low cumulus clouds. |
binietoglou@24 | 44 | |
binietoglou@24 | 45 | A: At moment you should provide cloud free data because the automatic cloud screening |
binietoglou@23 | 46 | is not yet implemented in the SCC. We are working on this issue and hopefully the new |
ioannis@39 | 47 | module will be implemented at the end of ACTRIS project. |
binietoglou@23 | 48 | |
binietoglou@23 | 49 | |
binietoglou@24 | 50 | High/low range channels |
binietoglou@24 | 51 | ~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 52 | Q: What is the definition of low range, ultra near range and high range channels? |
binietoglou@24 | 53 | Are there any threshold values? |
binietoglou@24 | 54 | |
binietoglou@24 | 55 | A: There are no threshold values defined for the different range types. This information |
binietoglou@23 | 56 | is used only in the gluing procedures just to identify which channel should be taken |
binietoglou@23 | 57 | as low range and which one as far range. If no gluing is applied by the SCC the range |
binietoglou@23 | 58 | id flags are not taken into account. |
binietoglou@23 | 59 | |
binietoglou@24 | 60 | Variable depolarization factor |
binietoglou@24 | 61 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 62 | |
binietoglou@29 | 63 | Q: Due to changes in the settings of our lidar system, the depolarization factor can |
binietoglou@24 | 64 | change during the measurement. Is it necessary to provide one SCC-file for each settings |
binietoglou@24 | 65 | or is it possible to set the Depolarization_Factor variable time dependent? |
binietoglou@23 | 66 | |
binietoglou@24 | 67 | A: Unfortunately it is not possible to have time dependence on Depolarization_Factor variable. |
binietoglou@23 | 68 | So if this parameter changes you should provide different SCC files for each setting. |
binietoglou@23 | 69 | |
binietoglou@24 | 70 | Extra netcdf parameters |
binietoglou@24 | 71 | ~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 72 | Q: Is it possible for documentation purposes to put own parameters in the SCC-NetCDF file? |
binietoglou@24 | 73 | For example who created the file.... Are there any reasons against this? |
binietoglou@23 | 74 | |
binietoglou@24 | 75 | A: Technically as long as you use not standard SCC variables for your own parameters there are |
binietoglou@23 | 76 | no problems for the SCC. It will just ignore these not standard variables. |
binietoglou@23 | 77 | |
binietoglou@23 | 78 | |
binietoglou@24 | 79 | Netcdf version |
binietoglou@24 | 80 | ~~~~~~~~~~~~~~ |
binietoglou@24 | 81 | Q: Which NetCDF version is to use? NetCDF3, NetCDF3 Classic, NetCDF4, NetCDF4 Classic? |
binietoglou@24 | 82 | |
binietoglou@24 | 83 | A: The NetCDF libraries 4.1.3 are used in all the SCC modules. So all the NetCDF formats you |
binietoglou@23 | 84 | have indicated should be compatible with the SCC (we have tested NetCDF3 and NetCDF4). |
binietoglou@23 | 85 | |
binietoglou@24 | 86 | Lidar ratio |
binietoglou@24 | 87 | ~~~~~~~~~~~ |
binietoglou@24 | 88 | Q: What are the values for the lidar ratio used in the SCC_DB? |
binietoglou@23 | 89 | |
binietoglou@24 | 90 | A: The values of (fixed) lidar ratio used by the SCC in the elastic retrieval can be set by |
binietoglou@23 | 91 | the user using the SCC web interface. In particular you can define a lidar ratio value for |
binietoglou@24 | 92 | each elastic backscatter product: in the product page there is the section "Elastic Backscatter |
binietoglou@24 | 93 | options" in which there is the field "Fixed lr". In case you want to use a lidar ratio profile |
binietoglou@23 | 94 | you should set LR_Input accordingly and provide an external LR profile NetCDF file |
binietoglou@23 | 95 | (see documentation on SCC file format). |
binietoglou@23 | 96 | |
binietoglou@29 | 97 | Calculation of Raman and elastic backscatter |
binietoglou@29 | 98 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 99 | Q: In cases of measurements where Raman channels are available, the SCC will calculate the Raman |
binietoglou@24 | 100 | backscatter profile. If I want to retrieve Klett-retrievals for this channel, too (e.g 532nm) |
binietoglou@24 | 101 | is it sufficient to set the value in LR_input(channels) to 1 or 0 plus a LR-profile to get |
binietoglou@24 | 102 | both retrievals? |
binietoglou@23 | 103 | |
binietoglou@24 | 104 | A: No. In general, for each lidar configuration you can define a set of optical products to be calculated |
binietoglou@23 | 105 | for that configuration using the SCC web interface. So suppose you have a system with 532nm and 607nm |
binietoglou@23 | 106 | channels. In this case you have 2 options: |
binietoglou@24 | 107 | |
binietoglou@24 | 108 | 1. Raman backscatter and extinction in the e532 file and Raman backscatter (full resolution) in the b532 |
binietoglou@24 | 109 | file. In this case you should associate to the configuration a product of type "lidar ratio and will |
binietoglou@24 | 110 | produce the e532 file and a product of type "Raman backscatter" which will produce the b532 file |
binietoglou@24 | 111 | 2. Raman backscatter and extinction in the e532 file and elastic backscatter in the b532 file. |
binietoglou@24 | 112 | In this case you should associate to the configuration a product of type "lidar ratio and extinction" |
binietoglou@24 | 113 | which will produce the e532 file and a product of type "elastic backscatter" which will produce the b532 file |
binietoglou@23 | 114 | |
binietoglou@23 | 115 | Note: you cannot calculate a b532 file containing the Raman and elastic backscatters at the same time. |
binietoglou@23 | 116 | The reason is that the 2 products will produce an output file with the same name (according to the EARLINET rules). |
binietoglou@23 | 117 | Moreover in general, it makes no sense to calculate the elastic backscatter when you can calculate the Raman |
binietoglou@23 | 118 | one which usually is better. |
binietoglou@23 | 119 | |
binietoglou@24 | 120 | Filename conventions |
binietoglou@24 | 121 | ~~~~~~~~~~~~~~~~~~~~ |
ioannis@54 | 122 | Q: What are the conventions for the filenames for the various files that need to be uploaded? |
binietoglou@23 | 123 | |
ioannis@54 | 124 | A: The following definitions apply: |
binietoglou@23 | 125 | |
binietoglou@29 | 126 | SCC raw lidar data file |
binietoglou@29 | 127 | ^^^^^^^^^^^^^^^^^^^^^^^ |
binietoglou@29 | 128 | |
ioannis@55 | 129 | In the current version of the SCC there is not limit in the name of the raw |
ioannis@55 | 130 | data file. We suggest, however, that this file is named <measurement_id>.nc. |
ioannis@55 | 131 | For example, if your measurement had a measurement ID of 20130101cc00 the |
ioannis@55 | 132 | corresponding NetCDF file should be named 20130101cc00.nc |
binietoglou@23 | 133 | |
binietoglou@24 | 134 | Sounding file |
binietoglou@24 | 135 | ^^^^^^^^^^^^^ |
binietoglou@23 | 136 | |
binietoglou@23 | 137 | The file should be named as rs_measID.nc. Considering the above example the sounding file should be named rs_20130101cc00.nc |
binietoglou@23 | 138 | |
binietoglou@29 | 139 | In this case you should also set the global attribute Sounding_File_Name in the raw lidar data file as:: |
binietoglou@23 | 140 | |
binietoglou@29 | 141 | Sounding_File_Name=rs_20130101cc00.nc |
binietoglou@23 | 142 | |
binietoglou@24 | 143 | Lidar ratio file |
binietoglou@24 | 144 | ^^^^^^^^^^^^^^^^ |
binietoglou@23 | 145 | The file should be named as lr_measID.nc. Considering the above example the sounding file should be named lr_20130101cc00.nc |
binietoglou@23 | 146 | |
binietoglou@29 | 147 | In this case you should also set the global attribute LR_File_Name in the raw lidar data file as:: |
binietoglou@23 | 148 | |
binietoglou@29 | 149 | LR_File_Name=lr_20130101cc00.nc |
binietoglou@23 | 150 | |
binietoglou@24 | 151 | Overlap file |
binietoglou@24 | 152 | ^^^^^^^^^^^^ |
binietoglou@23 | 153 | The file should be named as ov_measID.nc. Considering the above example the sounding file should be named ov_20130101cc00.nc |
binietoglou@23 | 154 | |
binietoglou@29 | 155 | In this case you should also set the global attribute Overlap_File_Name in the raw lidar data file as:: |
binietoglou@29 | 156 | |
binietoglou@29 | 157 | Overlap_File_Name=ov_20130101cc00.nc |
binietoglou@29 | 158 | |
binietoglou@29 | 159 | |
binietoglou@29 | 160 | Photocounting values should be integers |
binietoglou@29 | 161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@29 | 162 | Q: In one of my measurements I get an error concerning the photoncounting values:: |
binietoglou@29 | 163 | |
binietoglou@29 | 164 | Pre processing (177): Found no integer values in photoncounting signal |
binietoglou@29 | 165 | |
binietoglou@29 | 166 | The Raw_Lidar_Data variable in the NetCDF-file is defined as double. So is it necessary for Photoncounting signals to only provide integer values? |
binietoglou@29 | 167 | |
binietoglou@29 | 168 | A: Two important considerations: |
binietoglou@23 | 169 | |
binietoglou@29 | 170 | 1. The Raw_Lidar_Data array should contain your *real* raw data. |
binietoglou@29 | 171 | This means that *no corrections/operations* should be made on your signals |
binietoglou@29 | 172 | before filling the Raw_Lidar_Data array. This is particularly important because *all* |
binietoglou@29 | 173 | the operations and corrections should be applied by the SCC and not by the user before |
binietoglou@29 | 174 | the submission. In this way we can keep track of all the operations made on the signals |
binietoglou@29 | 175 | (for QA purposes) and moreover we are sure that all the corrections are applied in a |
binietoglou@29 | 176 | correct order (this is particularly important for non linear operations, think for example to the dead time correction). |
binietoglou@29 | 177 | |
binietoglou@29 | 178 | 2. The analog signals should be expressed in mV and the photoncounting signals in raw counts |
binietoglou@29 | 179 | |
binietoglou@29 | 180 | So if your photoncounting values are not integers they are not expressed in raw counts (which of course should be integers). |
binietoglou@29 | 181 | So the point here is not how to convert them in integers but to submit the right quantity in the right units. |
binietoglou@29 | 182 | |
binietoglou@29 | 183 | So please check carefully your converter and be sure to really submit raw counts for photoncounting channels and raw mV for the analog ones. |
binietoglou@29 | 184 | |
binietoglou@29 | 185 | |
binietoglou@29 | 186 | Preprocessing failed but no Exit code is provided |
binietoglou@29 | 187 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@29 | 188 | Q: The preprocessing of one of my measurements failed (I get a status -127). However, when I check the Exit codes |
binietoglou@29 | 189 | to see the description of the problem, I get an empty value (-). What does this mean? |
binietoglou@29 | 190 | |
binietoglou@29 | 191 | A: This means that the preprocessor crushed unexpectedly! Sorry for that! Report the problem in the forum and it will be fixed |
binietoglou@29 | 192 | soon. |