MultiMasterInSAR operator bug

Hello,

I am trying to make use of the MultiMasterInSAR feature for SBAS processing, but I am running into issues using this feature. Using S1 SLC TOPS data, using a single swath seems to work fine, but then the merge operator fails when you try and use the MultiMasterInSAR on IW1 and IW2 separately and then use S1-TOPS-MERGE to merge the corresponding output ifg products. If you first deburst both the products and then merge, and then try to use this output in the MutliMasterInSAR this also fails.

This gives some error like

INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Internal GDAL 3.2.1 set to be used by SNAP.
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Internal GDAL 3.2.1 set to be used by SNAP.
INFO: org.hsqldb.persist.Logger: dataFileCache open start
java.lang.NullPointerException
org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:434)
at org.esa.s1tbx.insar.gpf.MultiMasterInSAROp.initialize(MultiMasterInSAROp.java:172)
at org.esa.snap.core.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:528)
at org.esa.snap.core.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:298)
at org.esa.snap.core.gpf.Operator.getTargetProduct(Operator.java:385)
at org.esa.snap.core.gpf.main.CommandLineTool.runOperator(CommandLineTool.java:306)
at org.esa.snap.core.gpf.main.CommandLineTool.runGraphOrOperator(CommandLineTool.java:284)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:188)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:121)
at org.esa.snap.core.gpf.main.GPT.run(GPT.java:59)
at org.esa.snap.core.gpf.main.GPT.main(GPT.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.esa.snap.runtime.Launcher.lambda$run$0(Launcher.java:55)
at org.esa.snap.runtime.Engine.runClientCode(Engine.java:189)
at org.esa.snap.runtime.Launcher.run(Launcher.java:51)
at org.esa.snap.runtime.Launcher.main(Launcher.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:66)
at install4j.org.esa.snap.runtime.Launcher_gpt.main(Unknown Source)
Caused by: java.lang.NullPointerException
at org.esa.s1tbx.insar.gpf.MultiMasterInSAROp.createTargetProduct(MultiMasterInSAROp.java:227)
at org.esa.s1tbx.insar.gpf.MultiMasterInSAROp.initialize(MultiMasterInSAROp.java:169)
… 24 more

It also says the dates are invalid, even though they are clearly included in the product. In the source code for the MultiMasterInSAR operator I am hitting this error it seems, when using a merged S1 product as input.

"// Check if there are invalid pairs (i.e., pairs whose dates are not found in the source product)
if (datesInPairsList.size() > 0) {
throw new OperatorException("Check pairs. Invalid dates found: " + datesInPairsList.toString());
}
"

I try and run it without using the date it outputs to no avail.

Am I running these steps in the wrong order? I would expect to be able to use S1 tops data with this operator and eventually merge it.

Thanks

I have found a work around for using this operator with S1 TOPs data and merging it. The MultiMasterInSAR operator appears to remove IW1, IW2, IW3 as well as VV or VH from the naming convention after being ran and thus the S1 TOPs merge fails, as it expects IW?_V? in the band names. It seems you can just rename all the bands (in the …data and .dim folder/file) using the standard convention when doing S1 swath processing and then the S1 tops merges works as expected.