getGeoPos errors with GPT

[erl542]

Hi All,

I have recently updated my SNAP install (as per instructions) to deal with Sentinel-1 processing issues with post-March’2018 data (as per this link).

I can now process post-March’18 data, but I now get a whole lot of “errors” when processing with GPT:

[…]
getGeoPos: Maximum number of iterations reached for pixel (26684.0, 0.0)
getGeoPos: Maximum number of iterations reached for pixel (26704.0, 0.0)
getGeoPos: Maximum number of iterations reached for pixel (26724.0, 0.0)
x = 26144.0, y = 20.0, lat = -33.56962942107605, lon = 146.9941624206096, iter = 1, x’ = 26144.656455993652, y’ = 19.995193234967033
x = 26164.0, y = 20.0, lat = -33.56909570334282, lon = 146.99204892309245, iter = 1, x’ = 26164.626922607422, y’ = 19.994609368615418
x = 26184.0, y = 20.0, lat = -33.56857201643739, lon = 146.9899748135287, iter = 1, x’ = 26184.444358825684, y’ = 19.99455628985618
[…]

The processing generates literally millions of such lines (all with the same kind of content as above), which is a problem as I am processing the SAR scenes on high-performance computing facilities. This means that the console outputs from GPT get logged to a file for inspection after processing, and generates gigabytes of log data to the file system for each processed scene.

There does not appear to be anything wrong with the processing otherwise, and the SAR data seems to be processed and written to file correctly. The above messages are not giving me any hint either as to where the problem might be.

Can anyone comment on where this issue might come from? And how to fix it?

Thanks in advance for your help!

[erl542]

similar issue also noted here…

Performance Regression with Terrain Flattening Re-Grid

Hi all. I just wanted to note that there seems to be a significant performance regression with the Terrain Flattening routine after version S1TBX v6.0.3 When using the ‘re-grid method = True’ the following performance was noted between versions (times are for entire processing chain for two assembled slices): v6.0.3 = 1h 15m v6.0.5 = 4h 15m ‘regrid = False’ seems to be unaffected. The resulting data of both appear to be similar, but pixel values vary slightly, implying there has been some c…

[lveci]

This has been fixed but not yet released. It may get released next week.

[anthony.scarth]

@lveci Thank you very much for your and your team’s hard work.

I have built the latest snapshot from master. The messages as reported by @erl542 no longer appear. With regard to my issue in the linked thread, performance has improved notably, but is not close to pre-v6.0.5 speed:

v6.0.3 = 1h 15m
v6.0.5 = 4h 15m
v7.0.0-SNAPSHOT (2019-01-16) = 3h 9m

Are there further planned improvements to the new additions in this routine?

I am also seeing a noticeable shift in positioning within the output. However, I understand that this version is unreleased and the issue might not be related to Terrain Flattening. I will test the next stable update to v6 when released.

[s0sh0rt]

Another benchmark:
v6.0.5 apears about 1/2 as fast as v6.0.3 for my S-1 GRDH to ortho product graph processed on 48 core server:
6.0.3 = 10.3 min wall clock, and 73 CPU minutes
6.0.5 = 18.3 min wall clock, and 120 CPU minutes.
Resulting images are ~identical. I have reverted to v6.0.3 because of performance.

The 6.0.5 update today also resulted in the excessive messages: “Maximum number of iterations reached for pixel”