The attribute corresponding to the key "commonburststartsecondaryindex" is not present in the object "<class 'isceobj.TopsProc.TopsProc.TopsProc'>".

[m-elhussieny]

Using default ISCE Path: /mnt/f/Ubuntu/Code/ISCE/install/isce
This is the Open Source version of ISCE.
Some of the workflows depend on a separate licensed package.
To obtain the licensed package, please make a request for ISCE
through the website: https://download.jpl.nasa.gov/ops/request/index.cfm.
Alternatively, if you are a member, or can become a member of WinSAR
you may be able to obtain access to a version of the licensed sofware at
https://winsar.unavco.org/software/isce
2024-07-30 17:46:04,252 - isce.insar - INFO - ISCE VERSION = 2.6.2, RELEASE_SVN_REVISION = ,RELEASE_DATE = 20220117, CURRENT_SVN_REVISION = 
ISCE VERSION = 2.6.2, RELEASE_SVN_REVISION = ,RELEASE_DATE = 20220117, CURRENT_SVN_REVISION = 
Step processing
Error. The attribute corresponding to the key "commonburststartsecondaryindex" is not present in the object "<class 'isceobj.TopsProc.TopsProc.TopsProc'>".
Possible causes are the definition in the xml file of such attribute that is no longer defined 
in the object "<class 'isceobj.TopsProc.TopsProc.TopsProc'>" or a spelling error

[thescardo]

I encountered exactly the same error today and think I've found the source of the bug, this line: https://github.com/isce-framework/isce2/blob/b231d6e80a9f9d40a0ea95a54f00f57b9a11c058/components/isceobj/TopsProc/runComputeBaseline.py#L36

burstOffset contains a numpy.int64 which then is used to construct other variables, including commonBurstStartSecondaryIndex, which ends up becoming a mix of numpy and built-in python types, and this propagates finally to the output computeBaseline.xml:

<property name="commonburststartsecondaryindex">
   <value>[np.int64(0), np.int64(0), -1]</value>
   <doc>Secondary burst start index for common bursts</doc>
</property>

This leads to a failed read when you then run verifyDEM as the next step.

The issue is this function:

https://github.com/isce-framework/isce2/blob/b231d6e80a9f9d40a0ea95a54f00f57b9a11c058/components/isceobj/Sensor/TOPS/TOPSSwathSLCProduct.py#L220

So I changed these lines from:

            if arr[ind] < mdist:
                return ind-mind

To:

            if arr[ind] < mdist:
                return int(ind-mind)

The getBurstOffset functions claims it returns an int, so the above change looks like what the function was intended to do.

I'll submit a pull request.

[thescardo]

Sorry, I'm also a beginner both with this software and SAR processing so I don't think I can answer your question.

Anyway I would strongly recommend you don't clog issues with questions that are unrelated to solving the issue, as it makes issue threads harder to read and understand. Please stick to the discussions board or ask for help on forums like this: https://forum.step.esa.int/.

[EJFielding]

It seems that you are running ISCE VERSION = 2.6.2 which is quite old. The version 2.6.3 was released more than a year ago. This issue is probably already fixed if you update to the newer version.