|
Size: 4227
Comment:
|
Size: 4248
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
| ||4 ||16 ||0xF0000 ||N/A ||If > 0, then observing sequence not 'modC', if 2 then 'modL'. 'modL' was the standard sequence starting spring 2016. || | ||4 ||16 ||0xF0000 ||N/A ||If > 0, then observing sequence not 'modC', if 2 then 'modL'. 'modL' was the standard sequence 2016.04.13_19:12:55.11_UTC, FSN=104683793. || |
Calibration Version keywords
A keyword for calibration version keywords are included in level-1 data (CALVER32) through higher level products (CALVER64) starting in August 2012. This keyword is, at the start, considered to be a set of fields consisting of single hexidecimal digits.
The presently assigned values are from least significant nibble:
Field |
bits |
mask |
name |
Note |
0 |
0-3 |
0x0F |
HFCORRVR |
Height of formation code version used to find disk center. Vers 2 for all data to date. |
1 |
4-7 |
0xF0 |
CROTA2VR |
Version of CROTA2 in the Master pointing table. Vers 0 prior to Transit of Venus, then 1. |
2 |
8-11 |
0xF00 |
N/A |
If > 0, then smooth look-up tables were used to produce observables |
3 |
12-15 |
0xF000 |
N/A |
If > 0, then a correction for non-linearity of the CCDs was applied. If 0x1000, the polynomial coefficients used for this correction are: -8.2799134,0.017660396,-3.7157499e-06,9.0137137e-11 (for the side camera) and -11.081771,0.017383740,-2.7165221e-06,6.9233459e-11 (for the front camera). If 0x2000, the polynomial coefficients used for this correction are: 0.0,0.025409177,-4.0088672e-06,1.0615198e-10 (side camera) and 0.0,0.020677687,-3.1873243e-06,8.7536678e-11 (front camera) |
4 |
16 |
0xF0000 |
N/A |
If > 0, then observing sequence not 'modC', if 2 then 'modL'. 'modL' was the standard sequence 2016.04.13_19:12:55.11_UTC, FSN=104683793. |
5 |
20-23 |
0xF00000 |
N/A |
If > 0 then PSF/scattered light deconvolution has been done, 1==CUDA version, 2== C version |
6 |
24-27 |
0xF000000 |
N/A |
If > 0, then a rotational flat field was used. The code in HMI_observables and HMI_IQUVaveraging checks only on the bit 0x1000000 (originally field 4 was used for this, changed in Nov 2016) |
The default value of CALVER64 is 0 and should never be seen so long as QUALITY >= 0. The concept of a missing value for a CALVERxx field does not make sense since CALVERxx refers to the version of code or source of values vs the decisions made by that code. If for instance the limb fit fails in lev1 processing, HFCORRVR still should contain the code version but the appropriate QUALITY bit should show that that code could not produce a useful value. Higher level products may propagate CALVER64. If a new product record is made from multiple input records then that code must decide the range of input CALVER that are acceptable and if different versions are OK for the output product, which value to forward. A good choice would be to send forward the lowest level from the input records to indicate that older versions were used in the output product. This could be used later to decide which products should be updated when the input series itself is updated.
NOTE: Data products above hmi.lev1 do not have CALVER64 set for records with no usable data. So if QUALITY < 0 you should expect CALVER64 to be 0. Also due to a bug my program that updated existing records, for data made prior to 5 Sept 2012 the HFCORRVR values was not set, so values of 0 and 2 in that field should be taken to mean 2. I.e. since to date, only one version of the height of formation code was in use, HFCORRVR of 0 and 2 both mean the same thing. After a lot of discussion we agreed to not update the older ~10M records at this time. They will be corrected when the next calibration update is applied. (PHS 1 Oct 2012).
JSD entries for CALVER32 and CALVER64:
Keyword:CALVER32, int, variable, record, 0, "0x%08X", "none", "Calibration Version lev1"
Keyword:CALVER64, longlong, variable, record, 0, "0x%016llX", "none", "Calibration Version"
Prior to Aug 2012 hmi.lev1 had a keyword named HFCORRVR which can be taken as correct for fields 0 and 1 except that a 0 in the first nibble (field 0) should be changed to 2 to match the other records made with same code.
In the process of adding CALVER64 and CALVER32 for existing records these keywords should be set to 0x12 when updated with the post-Transit-of-Venus CROTA2 values. The plan for doing the August 2012 update is described at Crota2UpdatePlan.
Starting 1 Oct 2012 fields 2 and 3 are populated. The older data has not been updated (as of 15 Jan 2013).