Versions Compared

Old Version 9

changes.mady.by.user Xavier Bonnin

Saved on

compared with

New Version 10

changes.mady.by.user Xavier Bonnin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ItemNotesAction-items
1.a
  • RPW L1/HK data processing status
    • Bias L1 CURRENT CDFs have been shared (see https://rpw.lesia.obspm.fr/roc/data/private/solo/rpw/data/BIA/)
    • Samples of Bias L1 SWEEP CDFs - Verification with Bias team in progress
    • Automated L1/HK CDF production is on-going
    • Provision of SPICE kernels by the SOC via GFTS is now automated (and regular). See https://rpw.lesia.obspm.fr/roc/data/private/solo/soc/spice/
    • Adding in metadata SPICE kernels used to process L0/L1/HK Epoch times is on-going (for L1/HK CDF they will provide as entries of the "Parents" global attribute)
    • First L1 CDF for SBM mode should be available next week in the ROC Web site
    • To be done: QUALITY_BITMASK/QUALITY_FLAG, SOOP/OBS_ID



  • Older L0/L1/HK CDFs ready to be moved into "former_versions" subdir (done next week)



2
  • RPW L1R/L2 data processing status at LESIA

See 200423_ROC_Telecon21_NQN.pdf

  • Anomaly report
    • SCM SURV-CWF L2 data: problem with SAMPLING_RATE (to be fixed in SCMCAL 0.11.0)
    • Anomaly reported by LFR concerning BP1 L2 skeletons V06 → RCS teams must only commit/push CDF skeleton tables (ASCII) in the "rcs" branch of the DataPool Git repo.
  • Proposal for RCS update at LESIA and L1R/L2 generation cadence ?
    • RCS update every TBD weeks or months ? After each delivery ?
    • It is discussed to not share (even with CoIs) L1/L2 CDFs which are not at least well time-stamped (to be discussed at the next ROB telecon)
    • The "GO" to (re)generate first L2 to be delivered to the CDAG at ESAC will be discussed on next ROB telecon
  • Teams need to be able to look at "failed" L1R/L2 CDF processing. Xavier and Quynh Nhu will put "failed" L1R/L2 CDF in specific directories accessible to the teams (same for log files)
  • Action Quynh Nhu: Implement "failed" L1R/L2 CDF prod. in the ROC pipeline
    Jira
    showSummaryfalse
    serverjira-lesia.obspm.fr JIRA
    serverIdcb08a004-0694-3237-bcb1-3125e3ed9bc0
    keyROCDATPRO-119
  • Action Xavier: Provide to the Teams a first list of the L1/L1R/L2 CDF points of automated checking implemented or to be implemented in the pipeline
    Jira
    showSummaryfalse
    serverjira-lesia.obspm.fr JIRA
    serverIdcb08a004-0694-3237-bcb1-3125e3ed9bc0
    keyROCDATPRO-120
  • Action Xavier: Discuss at the ROB telecon about the data sharing (shared only time-stamped)
    Jira
    showSummaryfalse
    serverjira-lesia.obspm.fr JIRA
    serverIdcb08a004-0694-3237-bcb1-3125e3ed9bc0
    keyROCDATPRO-121
3.
  • Implementation in two steps:
  1. Teams drop their summary plot files in the dedicated 'summary_plots' folder in the SFTP at LESIA. Then ROC team moves the files into the ROC Web site (https://rpw.lesia.obspm.fr/roc/data/private/solo/rpw/data/SummaryPlots/)
  2. ROC will progressively get the programs (from Gitlab as RCS software) to create the summary plots at LESIA.
  • In the ROC Web site, organize summary plots as daily folders as for L1/L2 daily CDF


  • Conventions:
    • File naming : see mail sent on April 18, 2020 at 18:30 by X.Bonnin "[roc.rcs] RPW summary plots -- proposal for file naming convention and delivery to LESIA"
    • Descriptor field can differ from parent CDFs use to generate the plots. The only condition is to be unique and be explicit enough
    • Use PNG as file format for quicklook


  • Summary plots can be implemented as a feature in the RCS software or in separete program. However the RCS teams must ensure that program uses to generate summary plots can be run independently of the L1R/L2 CDF production (in nominal, the ROC plans to generate L1R/L2 CDF first, then run the production of the related summary plots)
  • Action RCS teams: Provide before the next telecon to Xavier the list of summary plots expected to be generated (the list will be add to RPW Data Products)
4.
  • Proposed implementation:
    • For IDL (SCMCAL and TDS_CALBA):- An instance of SPICE/ICY N00066 has been already installed on the roc2-dev.obspm.fr and roc.obspm.fr servers in /usr/local/spice/icy folder. (N.B. feel free to use it on your own for RCS dev/test).- Before each run of the RCS by the ROC pipeline, the variable $IDL_DLM_PATH will be automatically set to point towards the /usr/local/spice/icy/lib path containing the icy.dlm and icy.so files
    • For Python (LFR_CALBUT):- It is highly recommended to the LFR team to use the spiceypy module (https://spiceypy.readthedocs.io/en/master/) for any SPICE computation. Please be sure to apply the version 2.2.0 working with CSPICE N00066.- spiceypy will be installed by the ROC when deploying the LFR_CALBUT virtual environment on the roc servers. As for other Python dependencies, it will be done using the requirements.txt file (for you it means just add the line "spiceypy == 2.2.0" to the config/calbut_requirements.txt file)
    • We have noticed that BICAS (Matlab) and THR_CALBAR (IDL) are not concerned by SPICE implementation for now.
    • Two additional environment variables SPICE_MK_PRED_PATH and SPICE_MK_FLOWN_PATH pointing towards "predictived" and "as-flown" metakernels

5.
  • To be delivered to ROC in "cal" folder in sftp-lesia
  • Should now converge on naming convention → solo_CAL_rpw-*.cdf
  • To be implemented --> calibration catalog files (JSON instead of XML ?)
  • Action RCS Team: To be applied new calibration table file naming convention for the future file delivery
  • Action Xavier: To send before the next RCS telecon an update proposal for the calibration catalog files
6.
  • Next RCS telecon planned on June 4 at 2pm

7.

...