| Time | Item | Who | Notes |
|---|
| 1 | | - Jan indicated that there is no E-GSE stimuli data for PFM-DELTACAL after the end of May, 2017. Emmanuel and Xavier will check.
|
| 2. cal. table |
| - Bruno says that the current proposition for calibration table is not relevant for LFR (for instance calibration table for SWF and CWF would be the same with this scheme.)
- Xavier proposes to submit a new convention for cal. table naming, which is more adapted with LFR philosophy (i.e., table by sensor and freq). Xavier highlights that the name of the cal. table should be not a big issue, as long as the name of the file is provided in the L1R data.
- Xavier asks to LFR and TDS teams to send a short description (or example) of how they expect to structure their calibration table (e.g., for LFR 11 tables of n x m elements)
|
| 2. L1R content |
| - Teams are OK with the scheme proposed: 1 zVar "CALIBRATION_TABLE_INDEX", 2 gattrs "CALIBRATION_TABLE" and "CALIBRATION_VERSION". LFR team will check that there is no hidden inconsistency with its scheme.
- Erik asks if using "CALIBRATION_TABLE_INDEX" per record is not redundant over the file. Jan answers that it can be relevant from TDS point of view to keep this structure. Especially, since data are saved in daily files, the calibration table to use can change during a day. In this case, the 2 gattrs "CALIBRATION_TABLE" and "CALIBRATION_VERSION" must allows software to provide more than one entry (i.e., one value per calibration table file). Additionaly, in this case, the CALIBRATION_TABLE_INDEX zVars might have 1 dimension to indicate to BIAS/SCM software, which calibration file to use, e.g., CALIBRATION_TABLE_INDEX is a [n, m] elements array where n is the dimension for the n-th file(s) to use (same order than gattr entries).
- Xavier will formalize this in this "RPW Data Products" document in prep.
|
| 3. L2R/L2S |
| - Teams are ok to user ROC infrastructure to centralize the data exchange concerning L2S/L2 non-WF data production (e.g., transfer functions, cal. table, etc.)
- Nevertheless, it appears that what should be exchange exactly it is not clear for all
- Xavier will plan a dedicated discussion (by email and/or telecon) to clarify this point
|
| 4. |
| - There is a priori no big issue concerning the planning proposed by the ROC
- Xavier will send the SCMCAL Software Requirements Specification (SRS) to the Teams as example (see file attached below). First issue of this doc. is expected for 15/12/17.
|
| 5. |
|
|
| 6. |
| - Next telecon is planned on October 17 at 10am
|