Goals

  • Re-start the discussions concerning the RCS dev. activity
  • Especially, preparing the RPW consortium meeting #19 (discussions will be reported during the meeting, and will carry on if required)

Date

at 10am

Attendees


Agenda

  1. ROC activities for ground calibrations
    1. ROC-SGSE software and L1/HK data products status

    2. RCS software and L2R/L2S data products status

    3. Ground calibrations-related ROC Planning
  2. ROC activities for RPW science data processing during SOLO mission
    1. RODP software and L1/HK data products status

    2. Auxiliary data products

    3. RCS ICD and guidelines

    4. New Planning Proposal
  3. AOB
  4. Next telecon

Discussion items

TimeItemWhoNotes

ROC-SGSE software and L1/HK data products status

  • According to Jan, there might be an issue concerning the time resolution in the Epoch variable of the ROC-SGSE L1 SWF CDF. It should be nanosec, but microsecond found. Xavier will check that and let Teams know (see action-items)

RCS software and L2R/L2S data products statusAll
  • L2R dataset is completey abandoned and replaced by the L1R, including for the ROC-SGSE (for the latter it was not fully acted by the ROC). Some documents need to be updated (see action items)
  • LFR team said that the L1R will concern the WF data, but also the LFR BP1/BP2 datasets
  • As decided during the last meeting on January, the L1R WF datasets must be splitted between E and B data, as for L2 WF datasets
  • Xavier indicates that the ROC is interested to have more information about L1R. The TDS and LFR teams has inputs almost ready to be sent concerning the L1R.

RODP software and L1/HK data products status
  • Xavier has started to update the content of the L1/HK CDF datasets to be compliant with the ESA specification defined in SOL-SGS-TN-0009.
  • It results the creation of a new set of RPW datasets for the SOLO mission, which is distinct from the ROC-SGSE datasets. Xavier highlighted that it was not possible to use a common set for both SOLO/RPW and ROC-SGSE datasets. Nevertheless, most of the changes might concern the metadata and conventions (e.g., file naming).
  • Same work will be done on the L2 CDF datasets. Xavier will update the meta-data, then notify the teams for validation.

Quicklooks and L3/L4 datasetsAll
  • ROC asks the Teams to provide their needs in terms of quicklooks for their sub-system, to be produced by the pipeline. This concerns mainly L1/HK/L2 datasets. The ROC will start to generate a list for the L1/HK quicklooks, this list will have then to be validated and completed by the Teams.
  • First list of quicklooks must be delivered before end of Sept. 2017. 
  • Same work should be started for the L3/L4 data products.
  • ROC has indicated that the L3/L4 data products will be not processed by the ROC pipeline. However it might be interesting to identify if we want to archive and distribute also a part or all of the L3/L4 data at the ROC (e.g., direction-finding THR L3 datasets)

Auxiliary data products
  • ROC will use SPICE kernels provide by the SOC for its pipeline and tools.
  • ROC asks to teams to identify their needs in terms of orbit/attitude data. Especially, ROC needs to know if it has to produce CDF ancillary files, since SOC will do. ROC will send a document to be filled by teams to complete the needs.

RCS ICD and guidelinesAll
  • ROC notices that there is no big issue with the new RCS ICD and guidelines document. ROC let until the end of June for teams to send feedbacks or comments. After this date, the documents will be officialy released.
  • Teams are ok to use Git instead of SVN for RCS software and CDF skeletons deliveries
  • Concerning RCS testing, Xavier indicates that details have to be discussed, but the principle is to validate the RCS ICD compliance (using the RCS Validation tool, which must be updated). And, to perform end-to-end (E2E) tests after pipeline integration. The teams will have to provide inputs CDF and the corresponding expected output CDF. From this set, the ROC will run the RCS and check that the data produced matche the expected outputs. The ROC will be in charge of developping, or re-using (e.g., "cdfcompare" program of the NASA CDF toolkit) the matching program.
  • Xavier precises that both ROC-SGSE and RODP will use the same RCS interface (same RCS ICD) at the end. Moreover, the teams are free to develop 2 RCS (one for the ROC-SGSE and one for the RODP) or only one for both. However, there must be only one descriptor file per instance (i.e., one descriptor for the ROC-SGSE and one for the RODP).

New Planning ProposalAll
  • Teams are ok with the new planning proposal.
  • However, Jean-Yves is worried about the time necessary to prepare L2 data processing, especially with new L1R datasets, against the RCS integration tests planning. Xavier indicated that the RCS L1/L1R/L2 data processing can be not completed for the "demo" release at the end of 2017, but the processing of at least one L2 dataset shall be ready. In addition, the RCS ICD compliance shall be ready for the end of 2017.

AOBAll
  • The ROC will know use Git as a main source code manager. The ROC SVN repository is still accessible and can be used by teams.
  • Xavier indicated the new ROC "Confluence" Wiki, that will replace the old "redmine" site. He has started to transfer and update information concerning RCS working group. A mail will be sent to the teams to give more details about this Wiki
  • Jean-Yves asks what tool teams should use to search for ROC documentation? Does Baghera is still used as a document management system (DMS) ? Xavier precised that Baghera is still the official ROC DMS, but it is not use anymore in practice for publishing documents (not very efficient and "user-friendly"). The LESIA is working on installing a new DMS for lab's projects. It should be the new DMS for the ROC in the future (at least for booking reference and archiving). But for the moment, the documents concerning the ROC activity will be published on Confluence (see ROC Documents).

Action items

Attached items