Some Improvement in aspect processing

[FredSchuller]

Updates in several procedures called to process SAS data, including:

• added a procedure stx_remove_bad_sas_data
• updates in SAS_test to call procedures with name stx_...
• store error codes in data.ERROR (partly addresses issue SAS pipeline: implement a 'quality flag' #129). So far only these codes are implemented:
  • SUN_TOO_FAR (when distance > 0.75 AU)
  • NO_ASPECT_SOL (if for some reason the computation resulted in NaN)
  • SAS_DATA_WRONG_DURATION (for HK data where duration deviates from the expected 64s, e.g. for duplicated entries)

[FredSchuller]

More changes to implement more error codes:

• SUN_TOO_BIG (if solar image radius larger than the range covered in the simulated data)
• SAS_SOL_TOO_FAR (if solution found at more that 1.1 R_sol, i.e. far off the solar limb)

In addition, field sas_ok is now implemented and set to 1 only when no error was found.

[samaloney]

Since we will fix the HK data maybe the SAS_DATA_WRONG_DURATION isn't needed? Also all the status message seem different if I'd suggest either in clue SAS_ in all or remove from all

Current	Sun
SUN_TOO_FAR	SUN_TOO_SMALL / SUN_TOO_FAR
SUN_TOO_BIG	SUN_TOO_BIG / SUN_TOO_CLOSE
SAS_SOL_TOO_FAR	OFFPOINT_TOO_LARGE
NO_ASPECT_SOL	NO_SOLUTION

Also not sure how the plan to encode but a number would be better 0, 1, 2, 3 can be stores as two bits

[FredSchuller]

I'm happy to rename the error messages as you suggest. Still, I would keep the possibility for WRONG_DURATION (we can use a shorter text if you prefer) as long as the issue is not fixed - and it may happen again in the future...

The plan is to include this error message AND a boolean (or short integer) "SAS_OK" in the AUX fits file. The imaging pipeline will only make use of the later, to filter out every SAS measurement that is not OK, for any reason.

[FredSchuller]

@samaloney
I have updated the error messages as per your suggestion. From my point of view, this PR could be merged now.

[samaloney]

Yea looks good to me but I'd like to get @nicHoch input. In particular I'm not sure including both the string and error code/boolean make sense not in the fits file itself anyway. Also needs a rebase to resolved the conflicts with current master.

[nicHoch]

it was planed as String in order to provide the user with a verbose error reason. most of the time the string will be empty. but we could also change it to ENUM and add the verbose messages to the column description

[nicHoch]

the order is important in idl struct definition so it should be exactly like this:

** Structure STX_ASPECT_DTO, 16 tags, length=144, data length=134:
   CHA_DIODE0      DOUBLE           1.3056000
   CHA_DIODE1      DOUBLE           1.0624000
   CHB_DIODE0      DOUBLE          0.99840000
   CHB_DIODE1      DOUBLE           1.0256000
   TIME            STRING    '2022-05-09T23:59:03.379947'
   SCET_TIME_C     LONG64                 705455824
   SCET_TIME_F     LONG64                     31305
   DURATION        DOUBLE           64.000000
   SPICE_DISC_SIZE DOUBLE           1233.2347
   Y_SRF           DOUBLE           0.0000000
   Z_SRF           DOUBLE           0.0000000
   CALIB           DOUBLE           0.0000000
   SAS_OK          INT              0
   ERROR           STRING    ''
   CONTROL_INDEX   LONG64                      1349
   PARENTFITS      LONG                 0