I think the modification of FILLVAL of -1e31 was done to account for when the data are printed as ASCII, in which case the format string results in fill values in the data being -1e31. However, if binary data are read, a search for values of -9.999999796611898e-32 won't work if the values were cast as doubles and a FILLVAL of -1e31 is used.
I know that one can kludge together rules to handle this, but I've encountered issues with this over the years in both Autoplot and Nand's server. It seems like how this should be handled by software should be documented in the ISTP metadata document.
In many cases, Nand's metadata has
CDF_REAL4and aFILLVALof-1e31instead of what is given:-9.999999796611898e-32. What I think is the correct value (-9.999999796611898e-32) also appears in the masters, for example, http://mag.gmu.edu/git-data/cdaweb-hapi-metadata/cache/bw/DE/DE_VS_EICS/DE_VS_EICS-combined.json.According to https://spdf.gsfc.nasa.gov/istp_guide/vattributes.html#FILLVAL, for
CDF_REAL4, it should be-1E31. But-1E31is not a valid 32-bit IEEE 754 value (np.float32(-1e31) == -1e31givesFalse). See also https://www.h-schmidt.net/FloatConverter/IEEE754.html. I think this is the source of the problem.I think the modification of
FILLVALof-1e31was done to account for when the data are printed as ASCII, in which case the format string results in fill values in the data being-1e31. However, if binary data are read, a search for values of-9.999999796611898e-32won't work if the values were cast as doubles and aFILLVALof-1e31is used.I know that one can kludge together rules to handle this, but I've encountered issues with this over the years in both Autoplot and Nand's server. It seems like how this should be handled by software should be documented in the ISTP metadata document.