Lindsay at UMN provided an idlsav file that showed a number of issues:
- time is stored in strings, which could be detected and parsed
- byte order for real numbers appears to be incorrect
- GUI doesn't provide access to tags within structures. I was able to figure out how to get to COUNTS.RATE1 and COUNTS.TIME, but I had to use completions.
See sftp:jfaden.net:/home/jbf/ct/autoplot/u/2021/lindsay/20210929/orbit2.sav
See also https://sourceforge.net/p/autoplot/feature-requests/717/
I made a new IDLSav, and it looks like byte order is fine for a simple array. So I'm probably off by some offset.
I found the pile of save files I was testing against, at https://jfaden.net/~jbf/autoplot/data/sav/. I found strings within an struct, which fails, and I've added structOfArrayTypes.sav which shows there are issues with integer and real data one-d arrays within structures. https://jfaden.net/~jbf/autoplot/data/sav/structOfArray.idlsav?ZZA.B shows two-d arrays to be okay.
See https://github.com/autoplot/dev/blob/master/bugs/sf/2394/table.md which runs through all the sav files in https://jfaden.net/~jbf/autoplot/data/sav/.
I've added support for times encoded as ISO8601 strings.
Lindsay's file still doesn't read properly, where COUNTS.RATE4 comes out as the data from COUNTS.RATE3. I think what's going on with Lindsay's file is that I assume the order of tags in the file, assuming they are in the same order.
Cindy has an IDLSav file with a structure containing an array of strings which cannot be read with my Java code. I've been looking at the python idlsav.py, to see if I can convert it to Java code to make a more complete reader. See https://github.com/astrofrog/idlsave, and this is using the Python-to-Java converter I have within Autoplot. I've been improving that code as well in hopes to make porting this code faster.