Fri, 16 Dec 2016 12:37:57 +0200
Updates usecases (some notation was missing).
Added two more usecases.
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 | |
binietoglou@83 | 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 | |
ulalume3@79 | 50 | Minimum number of analog files to submit |
ulalume3@79 | 51 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
ulalume3@79 | 52 | |
ulalume3@79 | 53 | Q: Is it possible to submit a single analog profile for processing? |
ulalume3@79 | 54 | |
ulalume3@79 | 55 | |
ulalume3@79 | 56 | A: It depepends on the type of product you ar trying to calculate. |
ulalume3@79 | 57 | |
ulalume3@79 | 58 | * If the product is a linear polarization calibration, it is possible to submit a timeseries containing |
ulalume3@80 | 59 | one single analog profile. This is allowed because some stations are performing depolarization calibration measurements using |
ulalume3@80 | 60 | single profiles. If the errors are present they will be taken into account for the calculation of the error on calibration constant. |
ulalume3@80 | 61 | If they are not the error on calibration constant is calculate as the standard deviation withing the calibration range. |
ulalume3@79 | 62 | |
ulalume3@79 | 63 | * If the product to calculate is NOT a linear polarization calibration, if the raw analog error have not been provided we need at |
ulalume3@80 | 64 | least 3 raw profile in order to compute the statistical error |
ulalume3@79 | 65 | |
ulalume3@79 | 66 | |
binietoglou@24 | 67 | High/low range channels |
binietoglou@24 | 68 | ~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 69 | Q: What is the definition of low range, ultra near range and high range channels? |
binietoglou@24 | 70 | Are there any threshold values? |
binietoglou@24 | 71 | |
binietoglou@24 | 72 | A: There are no threshold values defined for the different range types. This information |
binietoglou@23 | 73 | is used only in the gluing procedures just to identify which channel should be taken |
binietoglou@23 | 74 | as low range and which one as far range. If no gluing is applied by the SCC the range |
binietoglou@23 | 75 | id flags are not taken into account. |
binietoglou@23 | 76 | |
binietoglou@23 | 77 | |
binietoglou@24 | 78 | Extra netcdf parameters |
binietoglou@24 | 79 | ~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 80 | Q: Is it possible for documentation purposes to put own parameters in the SCC-NetCDF file? |
binietoglou@24 | 81 | For example who created the file.... Are there any reasons against this? |
binietoglou@23 | 82 | |
binietoglou@24 | 83 | A: Technically as long as you use not standard SCC variables for your own parameters there are |
binietoglou@23 | 84 | no problems for the SCC. It will just ignore these not standard variables. |
binietoglou@23 | 85 | |
binietoglou@23 | 86 | |
binietoglou@24 | 87 | Netcdf version |
binietoglou@24 | 88 | ~~~~~~~~~~~~~~ |
binietoglou@24 | 89 | Q: Which NetCDF version is to use? NetCDF3, NetCDF3 Classic, NetCDF4, NetCDF4 Classic? |
binietoglou@24 | 90 | |
binietoglou@24 | 91 | A: The NetCDF libraries 4.1.3 are used in all the SCC modules. So all the NetCDF formats you |
binietoglou@23 | 92 | have indicated should be compatible with the SCC (we have tested NetCDF3 and NetCDF4). |
binietoglou@23 | 93 | |
binietoglou@81 | 94 | |
binietoglou@24 | 95 | Lidar ratio |
binietoglou@24 | 96 | ~~~~~~~~~~~ |
binietoglou@24 | 97 | Q: What are the values for the lidar ratio used in the SCC_DB? |
binietoglou@23 | 98 | |
binietoglou@24 | 99 | A: The values of (fixed) lidar ratio used by the SCC in the elastic retrieval can be set by |
binietoglou@23 | 100 | the user using the SCC web interface. In particular you can define a lidar ratio value for |
binietoglou@24 | 101 | each elastic backscatter product: in the product page there is the section "Elastic Backscatter |
binietoglou@24 | 102 | options" in which there is the field "Fixed lr". In case you want to use a lidar ratio profile |
binietoglou@23 | 103 | you should set LR_Input accordingly and provide an external LR profile NetCDF file |
binietoglou@23 | 104 | (see documentation on SCC file format). |
binietoglou@23 | 105 | |
binietoglou@29 | 106 | Calculation of Raman and elastic backscatter |
binietoglou@29 | 107 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@24 | 108 | Q: In cases of measurements where Raman channels are available, the SCC will calculate the Raman |
binietoglou@24 | 109 | backscatter profile. If I want to retrieve Klett-retrievals for this channel, too (e.g 532nm) |
binietoglou@24 | 110 | is it sufficient to set the value in LR_input(channels) to 1 or 0 plus a LR-profile to get |
binietoglou@24 | 111 | both retrievals? |
binietoglou@23 | 112 | |
binietoglou@24 | 113 | A: No. In general, for each lidar configuration you can define a set of optical products to be calculated |
binietoglou@23 | 114 | for that configuration using the SCC web interface. So suppose you have a system with 532nm and 607nm |
binietoglou@23 | 115 | channels. In this case you have 2 options: |
binietoglou@24 | 116 | |
binietoglou@24 | 117 | 1. Raman backscatter and extinction in the e532 file and Raman backscatter (full resolution) in the b532 |
binietoglou@24 | 118 | file. In this case you should associate to the configuration a product of type "lidar ratio and will |
binietoglou@24 | 119 | produce the e532 file and a product of type "Raman backscatter" which will produce the b532 file |
binietoglou@24 | 120 | 2. Raman backscatter and extinction in the e532 file and elastic backscatter in the b532 file. |
binietoglou@24 | 121 | In this case you should associate to the configuration a product of type "lidar ratio and extinction" |
binietoglou@24 | 122 | which will produce the e532 file and a product of type "elastic backscatter" which will produce the b532 file |
binietoglou@23 | 123 | |
binietoglou@23 | 124 | Note: you cannot calculate a b532 file containing the Raman and elastic backscatters at the same time. |
binietoglou@23 | 125 | The reason is that the 2 products will produce an output file with the same name (according to the EARLINET rules). |
binietoglou@23 | 126 | Moreover in general, it makes no sense to calculate the elastic backscatter when you can calculate the Raman |
binietoglou@23 | 127 | one which usually is better. |
binietoglou@23 | 128 | |
binietoglou@81 | 129 | |
binietoglou@24 | 130 | Filename conventions |
binietoglou@24 | 131 | ~~~~~~~~~~~~~~~~~~~~ |
ioannis@54 | 132 | Q: What are the conventions for the filenames for the various files that need to be uploaded? |
binietoglou@23 | 133 | |
ioannis@54 | 134 | A: The following definitions apply: |
binietoglou@23 | 135 | |
binietoglou@29 | 136 | SCC raw lidar data file |
binietoglou@29 | 137 | ^^^^^^^^^^^^^^^^^^^^^^^ |
binietoglou@29 | 138 | |
ioannis@55 | 139 | In the current version of the SCC there is not limit in the name of the raw |
ioannis@55 | 140 | data file. We suggest, however, that this file is named <measurement_id>.nc. |
ioannis@55 | 141 | For example, if your measurement had a measurement ID of 20130101cc00 the |
ioannis@55 | 142 | corresponding NetCDF file should be named 20130101cc00.nc |
binietoglou@23 | 143 | |
binietoglou@24 | 144 | Sounding file |
binietoglou@24 | 145 | ^^^^^^^^^^^^^ |
binietoglou@23 | 146 | |
binietoglou@23 | 147 | The file should be named as rs_measID.nc. Considering the above example the sounding file should be named rs_20130101cc00.nc |
binietoglou@23 | 148 | |
binietoglou@29 | 149 | In this case you should also set the global attribute Sounding_File_Name in the raw lidar data file as:: |
binietoglou@23 | 150 | |
binietoglou@29 | 151 | Sounding_File_Name=rs_20130101cc00.nc |
binietoglou@23 | 152 | |
binietoglou@24 | 153 | Lidar ratio file |
binietoglou@24 | 154 | ^^^^^^^^^^^^^^^^ |
binietoglou@23 | 155 | The file should be named as lr_measID.nc. Considering the above example the sounding file should be named lr_20130101cc00.nc |
binietoglou@23 | 156 | |
binietoglou@29 | 157 | In this case you should also set the global attribute LR_File_Name in the raw lidar data file as:: |
binietoglou@23 | 158 | |
binietoglou@29 | 159 | LR_File_Name=lr_20130101cc00.nc |
binietoglou@23 | 160 | |
binietoglou@24 | 161 | Overlap file |
binietoglou@24 | 162 | ^^^^^^^^^^^^ |
binietoglou@23 | 163 | The file should be named as ov_measID.nc. Considering the above example the sounding file should be named ov_20130101cc00.nc |
binietoglou@23 | 164 | |
binietoglou@29 | 165 | In this case you should also set the global attribute Overlap_File_Name in the raw lidar data file as:: |
binietoglou@29 | 166 | |
binietoglou@29 | 167 | Overlap_File_Name=ov_20130101cc00.nc |
binietoglou@29 | 168 | |
binietoglou@29 | 169 | |
binietoglou@29 | 170 | Photocounting values should be integers |
binietoglou@29 | 171 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@29 | 172 | Q: In one of my measurements I get an error concerning the photoncounting values:: |
binietoglou@29 | 173 | |
binietoglou@29 | 174 | Pre processing (177): Found no integer values in photoncounting signal |
binietoglou@29 | 175 | |
binietoglou@29 | 176 | 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 | 177 | |
binietoglou@29 | 178 | A: Two important considerations: |
binietoglou@23 | 179 | |
binietoglou@29 | 180 | 1. The Raw_Lidar_Data array should contain your *real* raw data. |
binietoglou@29 | 181 | This means that *no corrections/operations* should be made on your signals |
binietoglou@29 | 182 | before filling the Raw_Lidar_Data array. This is particularly important because *all* |
binietoglou@29 | 183 | the operations and corrections should be applied by the SCC and not by the user before |
binietoglou@29 | 184 | the submission. In this way we can keep track of all the operations made on the signals |
binietoglou@29 | 185 | (for QA purposes) and moreover we are sure that all the corrections are applied in a |
binietoglou@29 | 186 | correct order (this is particularly important for non linear operations, think for example to the dead time correction). |
binietoglou@29 | 187 | |
binietoglou@29 | 188 | 2. The analog signals should be expressed in mV and the photoncounting signals in raw counts |
binietoglou@29 | 189 | |
binietoglou@29 | 190 | So if your photoncounting values are not integers they are not expressed in raw counts (which of course should be integers). |
binietoglou@29 | 191 | So the point here is not how to convert them in integers but to submit the right quantity in the right units. |
binietoglou@29 | 192 | |
binietoglou@29 | 193 | 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 | 194 | |
binietoglou@29 | 195 | |
binietoglou@29 | 196 | Preprocessing failed but no Exit code is provided |
binietoglou@29 | 197 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
binietoglou@29 | 198 | Q: The preprocessing of one of my measurements failed (I get a status -127). However, when I check the Exit codes |
binietoglou@29 | 199 | to see the description of the problem, I get an empty value (-). What does this mean? |
binietoglou@29 | 200 | |
binietoglou@29 | 201 | A: This means that the preprocessor crushed unexpectedly! Sorry for that! Report the problem in the forum and it will be fixed |
binietoglou@29 | 202 | soon. |