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.