AUX_CAL information

[seongsujeong]

Some S1 data from old IPF requires elevation antenna pattern (EAP) phase compensation. The compensation requires information in AUX_CAL data.
We need to think about that would be the best way to contain the EAP information we need for the project.

1. Assign the AUX_CAL in runconfig:
   Currently the runconfig for CSLC workflow does not designate the path to the AUX_CAL file, which makes sense because only small portion of S1 data from old IPF will require EAP correction. Only few old S1 data would actually need that info.

2. Add AUX_CAL files into the repo
   The AUX_CAL files we need are about few megabytes when compressed. The file is in XML format which contains the EAP for all acquisition mode (e.g. IW, SM, EW). That means there are redundancy in keeping all information in AUX_CAL

3. Extract the EAP for IW mode only from AUX_CAL files, and add it into repo
   The only information we need for OPERA is for IW. In other words, we do not need all information in the AUX_CAL file.
   The extracted EAP can be saved into human-readable format (JSON, YAML, etc.) and be loaded whenever necessary.

[yunjunz]

Either the compressed zip file (600 KB) or the uncompressed s1a-aux-cal.xml file (1.6 MB) does not sound big to me. I like this option 2 because it keeps the format consistency with ESA, which I think it is easier to maintain in the long term.

[vbrancat]

I agree, 1.6 MB is not to big of a deal. However, if for some whatever reason ESA decides to change the format of these files, then we have to store their version in the repo which would increase the repo size (we won't be able to erase the old version forever). On the contrary, if we extract those parameters, we might be able to change everything with a PR with the drawback of not abiding to the ESA format. It would be could to provide some logic to download them on the fly. I think ISCE2 allows that. What do you think @yunjunz @hfattahi ?

[yunjunz]

Re-storing the file is also not a problem because 1) git handles XML file change as well so it won't be a total re-store; 2) it won't change frequently I suppose?; 3) the released version (on PyPI or conda-forge) won't have the git history, so it will still be light there.

Downloading on the fly is the same logic as storing the original XML file, except for the no-storing part. I like option 2 because it will have the code/function there to parse/extract the XML file, which is very helpful to understand the XML file and to adapt for potential future format changes as well.

[seongsujeong]

Thanks @yunjunz @vbrancat for your opinion about the AUX_CAL information in the repository. I think I prefer Yunjun's idea, which is to directly put the AUX_CAL data into the repo. because I do not expect frequent changes on the AUX_CAL data published by ESA.
In specific, I prefer to put .zip fie rather than .xml file because:

1. The actual .xml file inside every AUX_CAL .zip file has the same name i.e. s1a-aux-cal.xml (or s1b-aux-cal.xml). We need to rename these when we put the .xml files into the repo. I do not prefer renaming the originally published files for long term maintenance.
2. We need two files in each AUX_CAL .zip : s1a-aux-cal.xml, and manifest.safe. The .xml file is the actual data for the antenna pattern, and the manifest is to determine which version of AUX_CAL to load (by finding the matching instrumentConfigId of the S1 IW SLC data)