Mod C and Mod L Processing

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. Errors in the processing 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.

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. 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 and they were used twice. As a consequence the expected noise in the computed values was lower than the actual noise; 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 has 720s 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 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'}

Comments:

Back to