Third Deliverable to NISAR ADT

[dbekaert]

RAiDER is using ISCE as a library.
NISAR ADT flagged a problem of RAiDER having a ISCE3 dependancy.

Wanted to start a discussion:

• Conda distribution that does not include ISCE3 as dependency; e.g. raider-nisar?
  The CI testing and comparison should be for a NISAR workflow e.g. Zenith test?

[dbekaert]

@piyushrpt and @jhkennedy Can you chime in about the request from NISAR ADT?

[jhkennedy]

@dbekaert I don't really understand why the NISAR ADT is asking us to remove our ISCE3 dependency. RAiDER including ISCE3 is a normal and correct thing to do if the ISCE3 README is accurate:

The InSAR Scientific Computing Environment (ISCE) is an open-source library for processing spaceborne and airborne Interferometric Synthetic Aperture Radar (InSAR) data.

This project is a successor to the ISCE2 framework. It is a ground-up redesign focusing on improved modularity, documentation, and test-driven development.

That is, ISCE3 is being developed as a library to provide functions/algorithms for processing NISAR and other SAR satellite and airborne missions and it should therefore be expected for packages to grab and use ISCE3 as a library.

On the RAiDER side, we're using mostly what seem like normal library functions I would expect many packages in the community to use. Primarily geo2rdr, orbits, and getting some constants for inversions.

From what I can gather, there is interest in the NISAR processing workflow including tropospheric corrections via RAiDER, and that workflow is being implemented directly in ISCE3 leading to a circular dependency (ISCE3 would depend on RAiDER, which would depend on ISCE3).

That to me sounds like the NISAR ATD workflow should be separated from the ISCE3 library similar to how OPERA is building on ISCE3 in separate packages, and then it could freely depend on ISCE3 and RAIDER. But since the NISAR ADT and ISCE3 aren't being openly developed, I don't have any insight into the problem from their end.

There are a couple of options going forward.

1. If ISCE3 wants tropospheric correction to be a standard part of the library, RAiDER could be absorbed into ISCE3 and the RAiDER package depreciated, directing users to ISCE3. That's not really viable right now since ISCE3 isn't accepting community contributions and isn't openly developed.
2. We could potentially provide a trimmed-down package of RAiDER that removes the ISCE3 parts of the code and publish a raider-base or raider-nisar package on conda-forge for them to grab. That increases the development/packaging/testing burden on RAiDER and really isn't our burden, unless they are going to provide support for that increased burden directly.
3. They can "fork" raider into their code base and maintain/develop it from there. This is likely the worst option of the three as they loose the RAiDER user/developer community and keeping them in sync is really slow and tedious.

[dbekaert]

Hi @jhkennedy,

Thanks for sharing your thoughts. I agree on the assessment. How it is currently is set up does not allow for using it modular and ISCE3 team should think how they want to engage in future with the community, something which is more likely to happen in future. I have shared this c/feedback with @hfattahi.

I am not sure how feasible the change currently is on the ISCE3 and NISAR workflow side. As you mentioned Option 1 and 3 is not desired or ideal from the RaiDER team perspective. Option 2 could be at interim, but it would be good for the ISCE3 team to consider their request in a broader context.

[jhkennedy]

@dbekaert I've just merged conda-forge/raider-feedstock#10 which creates:

• a raider-base package with no ISCE3 dependency
• a raider meta-package that depends on raider-base and isce3

So the NISAR ADT should be able to install/use raider-base with no circular dependencies, and everyone else should be able to install raider as before with no change in behavior (other than that both the raider and raider-base packages will show up in the conda environment).

Note: this is very similar to how matplotlib handles the pyqt dependency. matplotlib-base does the actual build, and matplotlib adds the pyqt dependency in a metapackage.

[dbekaert]

Thank you Joe! This will go a long way while adt figures out their isce3 repository.

…

On Sun, Feb 19, 2023 at 10:48 AM Joseph H Kennedy ***@***.***> wrote: @dbekaert <https://github.com/dbekaert> I've just merged conda-forge/raider-feedstock#10 <conda-forge/raider-feedstock#10> which creates: - a raider-base package with no ISCE3 dependency - a raider meta-package that depends on raider-base and isce3 So the NISAR ADT should be able to install/use raider-base with no circular dependencies, and everyone else should be able to install raider as before with no change in behavior (other than that both the raider and raider-base packages will show up in the conda environment). Note: this is very similar to how matplotlib handles the pyqt dependency. matplotlib-base does the actual build, and matplotlib adds the pyqt dependency in a metapackage. — Reply to this email directly, view it on GitHub <#463 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AESZPSNU3BF4LFJS6TQ6PBDWYJTI3ANCNFSM6AAAAAATTNCPCE> . You are receiving this because you were mentioned.Message ID: ***@***.***>