Mod-C and Mod-L Processing

Mod C and Mod L are the standard science framelists used by HMI to specify the order in which filtergrams are observed. Mod C was the original framelist used since from beginning of regular operations in 2010. Regular use of the HMI mod-L frame list began at 2016.04.13_19:12:55 (fns=104683793). Mod-L requires use of filtergrams from both HMI cameras to compute the Stokes vector products. The framelist is indicated in the keyword CALVER64 in the bits 0xF0000.

Errors in the mod-L processing pipeline were discovered in July and September 2017 that were fixed in September and October 2017. Reprocessing of the data are underway. Details are provided below.

• Check the value of CALVER64 to make sure that you use data with the appropriate processing!

The first bug discovered in Mod-L processing was the more serious because filtergrams were not properly aligned. The difference in p-angle rotation of about 0.08 degrees between the two cameras was not corrected. This resulted in misalignment of about 3 pixels at the limbs and most severely contaminated the polar field and other limb measurements that combine data from the two cameras. Data with this error should only be used with extreme caution.

The second bug resulted in the use of only half of the available 'I+V' and 'I-V' filtergrams to create hmi.S products. In mod-L two complete sets of 'I +/- V' filtergrams are collected each 90s, but the filtergram selection was not correct; only half of the available I+V and I-V filtergrams were used -- the half closest to T_REC were used twice. As a consequence the expected noise in the computed values was lower than the actual noise and the time averaging was not as expected. As a result the 90-s mod-L values that depend on V had the same noise as the original 135-s mod-C. Data processed after 10 October 2017 use all of the filtergrams; values that depend on 'V' have been computed with a filtergram set obtained every 45s rather than 90s for mod-L and 135s for mod C.

How can you tell which data have been processed properly?

Bits 16-19 of CALVER64 in vector products indicate the observing sequence and basic processing applied to create the vector field products in hmi.S and subsequent dependent products. Thus the 4-bit nibble to check is 0xF0000

If (CALVER64 & 0xF0000) >> 16 equals %% {comparison is bitwise, so for IDL use 'AND'}

• 0x0 -> data were collected using mod-C [no known processing issues]

• 0x1 -> not defined

• 0x2 -> mod-L data processed with incorrect alignment of filtergrams from the two cameras and duplicated 'V' filtergrams -- USE WITH CARE

• 0x3 -> partially corrected mod-L processing with proper alignment but still using only half the available 'I +/- V' filtergrams

• 0x4 -> mod-L with proper alignment using all appropriate filtergrams

So if the value of the nibble is 0 or 4 you have the best available data.

Comments:

• The observed filtergrams actually collected with mod-L have been correct from the start.
• All mod-L data were processed incorrectly until 2017.10.10_XX-CONFIRM PRECISE TIME
• The misalignment bug was corrected in all data processed after 1 September 2017 for data with T_REC 2017.08.27_00:00:00 and after
• The filtergram-selection bug was corrected in all data processed after 10 October 2017 for data beginning with T_REC 2017:10:XX-CONFIRM PRECISE TIME
• Earlier mod-L data are being reprocessed to make both corrections; check the value in CALVER64 to determine.

Back to CalibrationVersions