GLOWS L3 metadata updates

[jtniehof]

This is the list of ISTP metadata that needs to be changed for GLOWS L3.

Bold need GLOWS team input. Others are informational or Menlo can handle directly.

general

• We have no_plot explicitly on a bunch of the support_data. I'm going to not worry about that for now...it's additional noise in my checker but not strictly wrong
• Several things have the UNITS updates from BUG - CoDICE Lo L3a ISTP validation issues - Card 3160 #87, so the current files fail validation but anything new should be fine.

L3a

• spin_angle is RV and of dimensionality 0, which is failing validation--i.e. it is implicitly dimensioned (time,) but of size 81. Either this needs to be RV and have DEPEND_0 on epoch and then dimensionality 1 (time, 81), or it needs to be NRV and dimensionality 1 (81,). Same for spin_angle_delta. Do we expect this to be constant with time?
• Global attribute flight_software_version is INT4; it should be CHAR (even if numerical)

L3b

No changes

L3c

No changes

L3d

• uv_anisotropy has several records with value -1. I'm guessing this is a fill / flag value. Maybe the most straightforward thing is for the wrapping code to replace -1 with the standard fill -1e31 -- EDIT: no change needed, see comments

L3e

• elongation in hi-45 has VALIDMAX and VALIDMIN of 135. Do we expect this to actually change? It's 90 for hi-90. I think it makes the most sense to use 0 as VALIDMIN and 180 as VALIDMAX -- yes Hi-45 is unlikely to not be 135, but maybe we'll discover it's 134 or something. 0-180 is used for elongation_excluded in Ultra. EDIT -- do this
• program_version is a variable. Does it make more sense for this to be a global attribute? -- EDIT: no change
• For Ultra, the surv_prob LABL_PTR_2 is HEALPix_index_label. The actual variable is healpix_index_label (no caps).

[mstrumik]

Regarding L3a:

• spin_angle is not constant in time. It is a grid for spin angle, but containing only unmasked bins. When GLOWS scanning circle is moving in the sky (due to daily repointings) different bins are masked out depending on relative position of the bins with respect to stars. Therefore both the dimension and values in the spin_angle array may change in time.
• My understanding is that flight_software_version is suggested to be a CHAR array not a simple CHAR (1-byte) variable. If so, then I have no objections, provided that the CHAR array capacity makes it possible to store INT4 values.

[IzabelaKL]

L3d:
This file will not have -1 in the future. I've updated the code that generates all ancillary files required by the L3d processing, so they have no fill values at the beginning of the file. It seems that I forgot to update the uv_anisotropy file. We are planning to update some ancillary files before the final data release in June, so I'll make sure to fix that.

[jtniehof]

Regarding L3a:

* My understanding is that flight_software_version is suggested to be a CHAR array not a simple CHAR (1-byte) variable. If so, then I have no objections, provided that the CHAR array capacity makes it possible to store INT4 values.

Correct, it would be a string, unbounded length of characters