Page History

For context RC first mentioned that recently it became clear that some instrument LLVMs did not react to processing requests because they were filtering for requests which met a naming scheme which was different (in the length of the timestamp string) from that specified in the SEGU, 1.2 section 6.2.4.  However their test requests provided with the VM deliveries also followed this variant naming, so were processed correctly. However the SOC produced requests were not processed.

RC then indicated that he had discovered that that the example request names in the data tree, figure 1 in the Data Tree given in section 6.2.12 in SEGU 1.2 actually followed this incorrect pattern. It seems likely that this is the origin of the problem.

This has been taken note of for any next SEGU version.

AdeG explained that EUI can take data at very high rates. They recently contacted the SOC indicating that the time granularity (coarse OBT) in the LL01 product filenames could be inadequate on occasion.

AdeG indicated that this was clearly something that could not be changed before launch, but could be discussed further with EUI and with the archive group.

KS indicated that EUI did not intend to use subsecond granularity before the 5th of March. This still seemed very soon to CW, who mentioned that there were plenty of other last-minute changes needed...

Anik asked if this was indeed something which would in fact be needed for LL01 - or just in fact for L0 science data. Koen confirmed that the plan was to, in exceptional cases, use such cadence for LL, for small sub-fields.

CW indicated that it would be much better if initially EUI spaced out observations sufficiently so as not to have 2 in a second. Koen indicated that they will try to adapt to fulfil this.

In response to a question CW indicated that any additional granularity in the filename timestamp would be optional. PO indicated a downside to this, but CW insisted that it did not make sense to impose a change on everyone.

Only a small number of comments. Mostly captured in status sheet.

ICB clarified how the MAG VM would behave if presented with a processing request without the calibration files in the auxiliary folder. The processing will fail and that failure is indicated as normal with the presence of a 'failed' directory in the output request dir.

CW described how the SOC had obtained data from the ISFTs which was more or less recently packaged and presented to multiple LLVMs.

For SWA, STIX, SPICE (bulk) and EPD the data came from the EDDS. For SoloHI, Metis (bulk), and RPW data was obtained from Airbus and 'hacked' to look like it came via EDDS. For EUI some data via each of these two routes was used. No MAG or PHI data were found/used.

Gethyn was not aware of any such results relating to SWA. AW pointed him to an email from RC on 2010-12-04.

On the specific instruments products:

• EUI: AdeG indicated that the VM output looked good. The new HRI detector names had been implemented in post-processing - but not yet tested. The fsi file from the cape tests looks good. It is pending SOAR ingestion. The hri file with 'metadata' in the descriptor seems strange. This to be discussed offline.
• SoloHI: AdeG - looks good.
• PHI: currently no useful products from the VM. No one present from instrument.
• EPD: no one present from instrument.
• Metis: DW said he would respond to Maurizio in the week of the telecon. Re the data from the cape there were a couple of small points relating to the metadata. DW asked what the latest version of the LLDPDD was.  MP indicated that yes it was the one from the start of last year; he is waiting for data on the light curves. MP reported that he suspected that the metadata issue and crash corresponding to the cape data may be down to an application software update in October.
• SPICE: DW said thanks for the OBS_MODE changes, and otherwise everything good.
• MAG: Only point was the Isaias mentioned a new version 1.3 of the LLDPDD delivered on the 5th of December.
• STIX: Dw had sent feedback, but perhaps not time to digest yet. Shane was concerned about have WCS keywords in a primary header resulting in non-standard files. Dave suggested they take discussion of this offline. DW asked if there was any more documentation, e.g. drafts, than the current LLDPDD version. Shane said that 'no' was the short answer. Dave was looking for clarification on the flare flag. Shane said that he would get back to him proving this. On WCS Shane said he was open to solutions, and Dave said the SOC would try to come up with ideas. NB SOC ideas collected right after telecon and communicated by DW to STIX.
  

RC and others asked whether these telecons were still useful. GL suggested to at least have a splinter in the next SOWG, and this was agreed. Perhaps after that bilateral SOC - instrument discussions are sufficient.

Anik asked the instruments to let the SOC know if they had produced LL data but had not heard from us.