binietoglou@23: Frequently asked questions binietoglou@23: ========================== binietoglou@23: ioannis@39: ioannis@39: Using an ancillary file ioannis@39: ~~~~~~~~~~~~~~~~~~~~~~~ ioannis@39: binietoglou@83: Q: I use the "Quick upload" to submit a measurement file together with an ancillary ioannis@40: file. Will this ancillary file be used in the processing of my measurement. ioannis@39: ioannis@39: A: No. Which ancillary file is used when processing a measurement is defined in the ioannis@39: measurement netcdf file. If your new ancillary file is not mentioned in the measurement ioannis@39: file, it will not be used. ioannis@39: ioannis@39: ioannis@39: Reusing an ancillary file ioannis@39: ~~~~~~~~~~~~~~~~~~~~~~~~~ ioannis@39: ioannis@39: Q: I want to use one ancillary file (ex. an overlap file) in the processing of multiple ioannis@39: measurements. Do I need to submit it multiple times? ioannis@39: ioannis@39: A: No. You just need to define the file name of the file to use in the measurements ioannis@39: netcdf file. ioannis@39: ioannis@39: ioannis@39: Deleting an ancillary file ioannis@39: ~~~~~~~~~~~~~~~~~~~~~~~~~~ ioannis@39: ioannis@39: Q: I want to delete an uploaded ancillary file but in the "Admin" interface I can't ioannis@39: find a "Delete" button. ioannis@39: ioannis@39: A: Probably the ancillary file you are trying to delete is needed by some uploaded ioannis@39: measurement, and for this reason you are not allowed to delete it. You will need ioannis@39: to delete the corresponding measurements first, before deleting the ancillary file. ioannis@39: ioannis@39: ioannis@39: binietoglou@24: Clouds in the data binietoglou@24: ~~~~~~~~~~~~~~~~~~ binietoglou@23: binietoglou@29: Q: Is it necessary to provide only measurement periods with cloud free conditions and binietoglou@29: homogeneous atmosphere or is this part of ELDA or the pre-processing of the data? binietoglou@24: For example in cases with scattered low cumulus clouds. binietoglou@24: binietoglou@24: A: At moment you should provide cloud free data because the automatic cloud screening binietoglou@23: is not yet implemented in the SCC. We are working on this issue and hopefully the new ioannis@39: module will be implemented at the end of ACTRIS project. binietoglou@23: binietoglou@23: ulalume3@79: Minimum number of analog files to submit ulalume3@79: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ulalume3@79: ulalume3@79: Q: Is it possible to submit a single analog profile for processing? ulalume3@79: ulalume3@79: ulalume3@79: A: It depepends on the type of product you ar trying to calculate. ulalume3@79: ulalume3@79: * If the product is a linear polarization calibration, it is possible to submit a timeseries containing ulalume3@80: one single analog profile. This is allowed because some stations are performing depolarization calibration measurements using ulalume3@80: single profiles. If the errors are present they will be taken into account for the calculation of the error on calibration constant. ulalume3@80: If they are not the error on calibration constant is calculate as the standard deviation withing the calibration range. ulalume3@79: ulalume3@79: * 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: least 3 raw profile in order to compute the statistical error ulalume3@79: ulalume3@79: binietoglou@24: High/low range channels binietoglou@24: ~~~~~~~~~~~~~~~~~~~~~~~ binietoglou@24: Q: What is the definition of low range, ultra near range and high range channels? binietoglou@24: Are there any threshold values? binietoglou@24: binietoglou@24: A: There are no threshold values defined for the different range types. This information binietoglou@23: is used only in the gluing procedures just to identify which channel should be taken binietoglou@23: as low range and which one as far range. If no gluing is applied by the SCC the range binietoglou@23: id flags are not taken into account. binietoglou@23: binietoglou@23: binietoglou@24: Extra netcdf parameters binietoglou@24: ~~~~~~~~~~~~~~~~~~~~~~~ binietoglou@24: Q: Is it possible for documentation purposes to put own parameters in the SCC-NetCDF file? binietoglou@24: For example who created the file.... Are there any reasons against this? binietoglou@23: binietoglou@24: A: Technically as long as you use not standard SCC variables for your own parameters there are binietoglou@23: no problems for the SCC. It will just ignore these not standard variables. binietoglou@23: binietoglou@23: binietoglou@24: Netcdf version binietoglou@24: ~~~~~~~~~~~~~~ binietoglou@24: Q: Which NetCDF version is to use? NetCDF3, NetCDF3 Classic, NetCDF4, NetCDF4 Classic? binietoglou@24: binietoglou@24: A: The NetCDF libraries 4.1.3 are used in all the SCC modules. So all the NetCDF formats you binietoglou@23: have indicated should be compatible with the SCC (we have tested NetCDF3 and NetCDF4). binietoglou@23: binietoglou@81: binietoglou@24: Lidar ratio binietoglou@24: ~~~~~~~~~~~ binietoglou@24: Q: What are the values for the lidar ratio used in the SCC_DB? binietoglou@23: binietoglou@24: A: The values of (fixed) lidar ratio used by the SCC in the elastic retrieval can be set by binietoglou@23: the user using the SCC web interface. In particular you can define a lidar ratio value for binietoglou@24: each elastic backscatter product: in the product page there is the section "Elastic Backscatter binietoglou@24: options" in which there is the field "Fixed lr". In case you want to use a lidar ratio profile binietoglou@23: you should set LR_Input accordingly and provide an external LR profile NetCDF file binietoglou@23: (see documentation on SCC file format). binietoglou@23: binietoglou@29: Calculation of Raman and elastic backscatter binietoglou@29: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ binietoglou@24: Q: In cases of measurements where Raman channels are available, the SCC will calculate the Raman binietoglou@24: backscatter profile. If I want to retrieve Klett-retrievals for this channel, too (e.g 532nm) binietoglou@24: is it sufficient to set the value in LR_input(channels) to 1 or 0 plus a LR-profile to get binietoglou@24: both retrievals? binietoglou@23: binietoglou@24: A: No. In general, for each lidar configuration you can define a set of optical products to be calculated binietoglou@23: for that configuration using the SCC web interface. So suppose you have a system with 532nm and 607nm binietoglou@23: channels. In this case you have 2 options: binietoglou@24: binietoglou@24: 1. Raman backscatter and extinction in the e532 file and Raman backscatter (full resolution) in the b532 binietoglou@24: file. In this case you should associate to the configuration a product of type "lidar ratio and will binietoglou@24: produce the e532 file and a product of type "Raman backscatter" which will produce the b532 file binietoglou@24: 2. Raman backscatter and extinction in the e532 file and elastic backscatter in the b532 file. binietoglou@24: In this case you should associate to the configuration a product of type "lidar ratio and extinction" binietoglou@24: which will produce the e532 file and a product of type "elastic backscatter" which will produce the b532 file binietoglou@23: binietoglou@23: Note: you cannot calculate a b532 file containing the Raman and elastic backscatters at the same time. binietoglou@23: The reason is that the 2 products will produce an output file with the same name (according to the EARLINET rules). binietoglou@23: Moreover in general, it makes no sense to calculate the elastic backscatter when you can calculate the Raman binietoglou@23: one which usually is better. binietoglou@23: binietoglou@81: binietoglou@24: Filename conventions binietoglou@24: ~~~~~~~~~~~~~~~~~~~~ ioannis@54: Q: What are the conventions for the filenames for the various files that need to be uploaded? binietoglou@23: ioannis@54: A: The following definitions apply: binietoglou@23: binietoglou@29: SCC raw lidar data file binietoglou@29: ^^^^^^^^^^^^^^^^^^^^^^^ binietoglou@29: ioannis@55: In the current version of the SCC there is not limit in the name of the raw ioannis@55: data file. We suggest, however, that this file is named .nc. ioannis@55: For example, if your measurement had a measurement ID of 20130101cc00 the ioannis@55: corresponding NetCDF file should be named 20130101cc00.nc binietoglou@23: binietoglou@24: Sounding file binietoglou@24: ^^^^^^^^^^^^^ binietoglou@23: binietoglou@23: The file should be named as rs_measID.nc. Considering the above example the sounding file should be named rs_20130101cc00.nc binietoglou@23: binietoglou@29: In this case you should also set the global attribute Sounding_File_Name in the raw lidar data file as:: binietoglou@23: binietoglou@29: Sounding_File_Name=rs_20130101cc00.nc binietoglou@23: binietoglou@24: Lidar ratio file binietoglou@24: ^^^^^^^^^^^^^^^^ binietoglou@23: The file should be named as lr_measID.nc. Considering the above example the sounding file should be named lr_20130101cc00.nc binietoglou@23: binietoglou@29: In this case you should also set the global attribute LR_File_Name in the raw lidar data file as:: binietoglou@23: binietoglou@29: LR_File_Name=lr_20130101cc00.nc binietoglou@23: binietoglou@24: Overlap file binietoglou@24: ^^^^^^^^^^^^ binietoglou@23: The file should be named as ov_measID.nc. Considering the above example the sounding file should be named ov_20130101cc00.nc binietoglou@23: binietoglou@29: In this case you should also set the global attribute Overlap_File_Name in the raw lidar data file as:: binietoglou@29: binietoglou@29: Overlap_File_Name=ov_20130101cc00.nc binietoglou@29: binietoglou@29: binietoglou@29: Photocounting values should be integers binietoglou@29: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ binietoglou@29: Q: In one of my measurements I get an error concerning the photoncounting values:: binietoglou@29: binietoglou@29: Pre processing (177): Found no integer values in photoncounting signal binietoglou@29: binietoglou@29: 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: binietoglou@29: A: Two important considerations: binietoglou@23: binietoglou@29: 1. The Raw_Lidar_Data array should contain your *real* raw data. binietoglou@29: This means that *no corrections/operations* should be made on your signals binietoglou@29: before filling the Raw_Lidar_Data array. This is particularly important because *all* binietoglou@29: the operations and corrections should be applied by the SCC and not by the user before binietoglou@29: the submission. In this way we can keep track of all the operations made on the signals binietoglou@29: (for QA purposes) and moreover we are sure that all the corrections are applied in a binietoglou@29: correct order (this is particularly important for non linear operations, think for example to the dead time correction). binietoglou@29: binietoglou@29: 2. The analog signals should be expressed in mV and the photoncounting signals in raw counts binietoglou@29: binietoglou@29: So if your photoncounting values are not integers they are not expressed in raw counts (which of course should be integers). binietoglou@29: So the point here is not how to convert them in integers but to submit the right quantity in the right units. binietoglou@29: binietoglou@29: 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: binietoglou@29: binietoglou@29: Preprocessing failed but no Exit code is provided binietoglou@29: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ binietoglou@29: Q: The preprocessing of one of my measurements failed (I get a status -127). However, when I check the Exit codes binietoglou@29: to see the description of the problem, I get an empty value (-). What does this mean? binietoglou@29: binietoglou@29: A: This means that the preprocessor crushed unexpectedly! Sorry for that! Report the problem in the forum and it will be fixed binietoglou@29: soon. giuseppe@127: giuseppe@127: giuseppe@127: Force cloud-free conditions giuseppe@127: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ giuseppe@127: Q: The SCC misclassifies dense aerosol layers contents as cloud. What can I do if I'm sure the corresponding measurement is not affected by clouds. giuseppe@127: giuseppe@127: A: It is possible to set as cloud-free any measurement submitted to the SCC. If this is done the automatic cloud mask will be always produced and stored in the corresponding CloudScreen product but it will be in the further SCC data processing. In this case, the corresponding SCC products requiring as input the cloud mask will be labelled as manual cloud-screened. giuseppe@127: There are three equivalent ways to set as cloud-free an already submitted (and processed) measurements: giuseppe@127: giuseppe@127: 1. From "Data processing", click on the measurementID corresponding to the measurement you want to set as cloud-free, then clock on "Edit in Admin" and finally check "Manually Assumed Cloud Free" giuseppe@127: giuseppe@127: 2. From "Admin", click on "Measurements", click on the measurementID corresponding to the measurement you want to set as cloud-free an finally check "Manually Assumed Cloud Free" giuseppe@127: giuseppe@127: 3. From "Admin", click on "Measurements", select one or more measurments you want to set as cloud-free, select "Manually Assumed Cloud Free/Not Cloud Free and Reprocess selected measurements" in the action list located at the page bottom and finally click on "Go". giuseppe@127: giuseppe@127: In all the cases the processing on the corresponding measurementID(s) will be restarted automatically.