Differences between revisions 6 and 7
Revision 6 as of 2017-09-02 02:26:08
Size: 2542
Editor: ToddHoeksema
Comment:
Revision 7 as of 2020-04-11 00:45:10
Size: 2664
Editor: PhilScherrer
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:

'''NOTE - This reprocessing was completed long ago, will update this with the completion date later. (PHS Apr 2020)'''

Recalibration of 720s HMI Data Products Obtained with Two Cameras

Bug Discovered in HMI Vector Field Data Processed Since 13 April 2016

On 13 April 2016 HMI permanently changed the vector field observations to use data from two cameras. Despite careful testing, a bug has recently been discovered such that the filtergrams from the two cameras were not properly aligned in the computation of the Stokes parameters in hmi.S_720s. A 0.08 degree offset in image rotation results in a displacement of about three pixels at the solar limb. The offset is most apparent in the Stokes Q and U components relative to Stokes V; Stokes I is a blend.

The misalignment affects all of the data products that depend on the HMI Stokes data product, hmi.S_720s. In particular the vector magnetic field provided in hmi.B_720s and hmi.sharp_720s deteriorate away from disk center. The error was first noticed in measurements of the radial magnetic field component near the poles derived from the vector data. We are currently assessing the impact on the other 720s data products.

The bug has been corrected in data processed after 1 September, 2017 (TBC) and we plan to reprocess the affected data over the next several months. If you are using data products with keyword CAMERA=3 and keyword DATE prior to 1 September 2017 (TBC) you should replace them when they become available.

NOTE - This reprocessing was completed long ago, will update this with the completion date later. (PHS Apr 2020)

Please contact a member of the HMI team if you have questions.

The HMI 45-second data products are not affected.

Details

Data series affected include the following.

  • hmi.S_720s
  • hmi.ME_720s_fd10
  • hmi.ME_720s_fd10_nrt
  • hmi.B_720s
  • hmi.sharp_720s
  • hmi.sharp_720s_nrt
  • hmi.sharp_cea_720s
  • hmi.sharp_cea_720s_nrt
  • hmi.bmap_lowres_latlon_720s
  • hmi.b_synoptic
  • hmi.b_synoptic_small
  • hmi.lookup_ChebyCoef_BNoise (MASKID = 7)

We are debating whether to set a bit (0x080) in the QUALITY keyword for data that are affected by the problem. The bit will be cleared when data reprocessed and the value of the keyword.

Bits 16-19 in the keyword CALVER64 will be set to 0x03000 instead of 0x02000 in reprocessed data.

You can test for old data with code like the following:

  • if (CALVER64 & 0xF0000 == 0x20000) then the old version is present.

All non-nrt data that depend on hmi.S_720s collected after the switch to the Mod-L frame list at 2016.04.13_19:12:55 UT will be reprocessed.

JsocWiki: ModLRecalibration (last edited 2020-04-11 00:45:10 by PhilScherrer)