Page tree
Skip to end of metadata
Go to start of metadata

Attendees

Apologies

  • Koen Stegen (EUI)
  • Emil Kraaikamp (EUI)

Agenda

  • Clarification needed - OBT_BEG / OBT_END format and conversion. As suggested by Emil (EUI). Ref email →AdeG→RC (2020-03-20)
  • VM status - Engineering.
  • VM product status.
  • AOB

Discussion items

ItemNotes
Clarification - OBT_BEG format

From EUI (Emil Kraaikamp): some information that may be useful for all teams using FITS:

The MetadataStandard says that this is a "Mandatory keyword that contains the start time of data acquisition in onboard time units (double-precision, floating-valued)."

The fact it is a double-precision floating-valued number in onboard-time units means that we can have a time like "637551003.4117279", where the sub-seconds part is created from the fine part of the CUC time. And as this is cuc fine is a counter from 0-65535, you get create this OBT_BEG by doing:
cuc_coarse + cuc_fine/65536.

The value 637551003.4117279 translates back to a coarse of 637551003 and a fine of round(0.4117279* 65536) = round(26982.9996544) = 26983. I have tested the conversion from float to coarse + fine and back for many years in the future, and that all works out fine, so rounding errors are not a problem for the fine resolution of the time.

The value you can then feed to the spice time conversion routine is "637551003:26983". Directly passing OBT_BEG of 637551003.4117279 to the spice conversion software does not result in an error, but it treats it as if the fractional part rolls over several seconds, so the 637551003.4117279 becomes 637551003 + 4117279 / 65536 = 637551003 + 62.8246917724609375 = 637551065.8246917724609375. A date 62 and a bit seconds further in the future. I've seen mistakes like this made before.

VM Status - engineering.

Maurizio explained that the problem which provoked the crash when trying to process the FFT data taken at KSC had been understood (the science header had been changed) and the application S/W updated. However the VM did not incorporate this update. This problem should not normally occur with LL as the relevant product is bulk science. He plans to deliver a new pipeline in time for the RSCW.


Paco indicated that EPD have no plans to update their VM. They will do that only when they have new calibration.


Gethyn said the SOC could expect a new SWA VM version next week, and mentioned the initial difficulty of testing because of difficulty accessing the existing VM at the lab. He listed the changes as described to him by Chandra, and which are quoted here from an email:

a) Corrected EAS energy table - this is needed to choose correct energy value for the strahl setting.
b) Updated PAS codes to read both lower and upper case hex number - this prevented reading in PAS SID correctly on 16th April test.
c) Updated PAS codes to use half-precision float to convert PAS moments raw values to real values.
d) Implemented HIS updates with inputs from Keeling (HIS team).


RC indicated to MK for PHI that he had seen no output when trying the latest PHI VM (1.7.0). HOWEVER, in the days after the telecon, this seemed to be a one-off, not fully explained, problem. As was communicated to Martin, later repetitions of the tests worked correctly.


For SoloHI, Lynn explained that she was waiting for some information re certain keywords from Nathan and would then produce a new VM version.

Nathan indicated that he had two difficulties with the header information.

  1. A different frame of reference is needed than the current implementation.
  2. He did not understand well the orientation with respect to the Spice kernels.

Nathan would like a sample image with the transformation already performed.

ADG indicated that the difficulty may be that the SOC doesn't have non-sun-centred images. But NR indicated that that was not necessary. Any image with WCS as per LL02 would do. ADG, AW and RC will organise this. Nathan then mentioned that SoloHI still owes the SOC a document and a new VM version with just header changes.


For MAG, Vincent indicated that there were no VM updates planned yet - just calibration files. When asked by RC, VE said that addition of log rotation was on his agenda, but clarification would be needed re 'should fail' tests. RC and VE will communicate separately on this.

VE asked with regards to signals from heater currents whether it would be possible to feed LCL data into the VM. CW explained that as packets this is very possible. He understood that as paramaters would be easier for MAG, but that was a significant architectural complication. CW was also under the impression that the approach was not to have heater cycling. He will pursue this discussion separately.


For RPW, XB said that they have no plan to redeliver a VM for now as there is no need. They will upgrade for new parameters when needed.

He added that their VM is also running and successfully processing LL data at their site.


In the absence of a representative from Stix, Dave Williams simply mention that there are still some pending modifications to the current 0.7.0 version.


A technical issue meant that no one could hear Terje, although he could hear the others. By email he informed Richard Carr that the SPICE VM is considered to be operating nominally, also in Oslo. One small low-priority bug will mean a new version, probably before the next telecon.

VM product status

Anik commented s follows:

SoloHI LL products were covered earlier, and PHI products look good.

On science products more generally:

DPDDs: several (Science) Data Description Documents still missing, or information missing in the available documents. In particular:

  • PHI: document missing
  • SoloHI: document is available but table of data product types + descriptors is missing

The descriptors for these instruments are needed for the archive development.


DW mentioned that STIX data was now much improved. An issue is that the filenames are now too long. Shane is discussing this with Dave.

Re SPICE Dave also mentioned to Terje (who we could not hear although he could hear us) an ambiguity in a descriptor. DW will pursue this by email.


AW said that he was just waiting for HIS products. Other IS products were quite stable and being ingested in the archive.


GL asked about current data being made available publicly in the archive. AW reassured him that this ingestion was only for test purposes and only data starting from cruise would be made available publicly.

AoB

We decided that the next telecon should be on the 22nd of July.

This telecon ended at 15:55, having started at 15:00 (without RC initially who took some minutes to get Skype for Business to work correctly).

Preparatory Actions

New Actions

None.