Discussion items


10 OBT digits in filenames.

RC simply clarified that it had been noted that in the cases of one instrument the SOC had noted that some sample LL01 files had been created with only 9 digits in the OBT element of the file name. This just an alert in case anything similar made its way into automated production.
Bulk science, gaps and retrieval strategy

CW explained the point the SOC wished to make as follows:

  • Topic that arose indirectly from SOC ground segment readiness review. It is not strictly LL, but we believe that many of the people working on LL are also working on bulk-science retrievals, and that this issue is better addressed via this forum than via an SOWG.
  • Basically, the topic is that gaps in TM happen, they can cause the need to reprocess (once/if the gap is recovered), and that this reprocessing can cause additional work
  • Within the review, we convinced the reviewer that we had considered this adequately within the SOC. But they asked us to communicate the topic to ITs as well.
  • In detail:
    • Most-likely gaps will occur on in-flight TM.
      • We expect that sometime the gap will subsequently be filled, sometime not.
      • Further we expect that at the time the gap occurs it will not be obvious whether it is recoverable.
    • LL approach (within the overall responsibility of SOC) as detailed in SEGU, is that
      1. "Reprocessing due to gap-filing is considered exceptional". Crudely we don't reprocess (mostly) because the LL of tomorrow will supersede the (gapped) LL of today.
      2. Scheme for managing reprocessing, when essential, is given in section 6.2.6 and Figure 5.
    • SOC LL approach is probably reasonable given that LL prioritizes TIMELINESS more than COMPLETENESS
    • Whereas for bulk-science
      • TM gaps still liable to occur
      • ITs are responsible for organizing the bulk retrievals
      • Completeness is probably more important than timeliness. Especially when the latency on bulk-science means it may have been onboard for multiple weeks.
    • ITs may like to consider their approach to reprocessing

RC asked for confirmation that the representatives present were actually also the appropriate contacts re the science pipelines.

The EUI, SoloHI and MAG representatives confirmed that they were indeed responsible for the science pipelines at least in this regard. Maurizio said that he was not but that he works closely with the corresponding person and will communicate this information.

Isaias mentioned that the MAG team will coincidentally be discussing the topic of gaps this week.

Deadline  - VM Delivery for use during cruise

ADeG reminded the instrument teams - although it was in large part aimed at those not present - of the urgent need for fully working VMs to allow completion of SOC post-processing for use in flight.

As such the SOC has decided that it cannot guarantee the use of any modified VMs provided after the end of November. This applies to the whole payload, but is especially important in relation to in situ instruments, given the crucial role of the LLVMs in allowing the display of LL data during cruise.

ICB wanted to know if this related primarily to any changes affecting the output format of the VMs. ADeG agreed that any changes that did not include modifications to the structure of the outputs would be acceptable. The principal SOC needs are to be able to create/finalise the LLDPDDs for the LL02 products and to prepare the display mechanisms for all product types. So small changes not affecting these needs would not be a problem.

Isaias suggested that commissioning is the validation of the LL VMs. Anik agreed that this is rather true for the |in situ instruments. Some data will be used to try out the pipelines. She also noted that the SOC has been working on the display of the Low Latency data and that a version of this will very likely be shown at the January SOWG.

VM Status - engineering.

See status sheet. Plus:

Metis: MP stated that issues reported by RC at end of July have been fixed, but still working on other minor changes. New VM by end of this month, but it will not be the last. He indicated that he is still waiting for some answers from DW on lightcurve products. ADeG encouraged Maurizio to forward his questions to her in case she could answer. And RC requested that he provide a version fixing the engineering issues even if outstanding improvements to the products; he agreed to do this.

VM product status

EUI: ADeG mentioned that the LL01 products can be post-processed and that the LLDPDD for LL02 has been sent to ROB for review. ROB indicated that they have not yet been able to review it, but that they will  in the coming weeks.

SoloHI: ADeG acknowledged some recent confusion over certain FITS keyword - but Lynn confirmed that things were now clear. Anik mentioned that she is currently writing the LLDPDD for LL02, but for now will only cover time correlation and frame transformation (as per other RS instruments).

LH indicated that she has software to stretch the maps. She will check whether she can share the Python code for this with the SOC.

CW asked a question relating to the SoloHI use of non-(tan/gnomonic) projection. LH indicated that for this it was better to contact Nathan.

ADeG asked MP whether the Metis VM was currently producing Visible, UV and light-curve data. MP said Visible and UV, but not yet light-curve.


The date of 27th November was chosen for the next telecon.

NB This date is very close to the deadline for significant VM updates. We expect to discuss the baseline versions of IS VMs to be used for Cruise Phase (and validation in NECP).

Preparatory Actions

New Actions