DEM Terrain-Correction error while processing Sentinel-1B products

Microwave Toolbox
#1

Dear developers,

We are facing the error:
WARNING: org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp: 7-Terrain-Correction error: no valid output was produced. Please verify the DEM

while executing gpt with graph files referring to some Sentinel-1B products, for example:

S1B_IW_SLC__1SDV_20170215T172400_20170215T172427_004314_0077D8_D98B
S1B_IW_SLC__1SDV_20170227T172400_20170227T172427_004489_007D03_E01A
S1B_IW_SLC__1SDV_20170311T172400_20170311T172427_004664_008222_5D07
S1B_IW_SLC__1SDV_20161011T010444_20161011T010512_002452_004237_07A6

Attached you can find an example of a graph file used to run gpt, that results in the error above:
graph.xml (3.7 KB)

Note that the regions of the subset operator on the graph file are located on land.
We have the corresponding DEM files.
We’ve been running the same type of processing for Sentinel-1A data without problems.
We are running snap version 5.0. Please see attachment modules.txt with full description of the versions we are using.
modules.txt (20.2 KB)

Do you have any idea of what might be going wrong here?

Thank you,
Joaquim Rosa

Java heap errors when BackGeoCoding certain specific S1B products via GPT
Java heap errors when BackGeoCoding certain specific S1B products via GPT
#2

You get this error when it completes processing but it never got to write anything. For all pixels, some condition said it should skip that pixel. This could be the DEM doesn’t have any values or it’s no data value. Possibly the input raster has no data values. Also, the times in the product and the orbits could cause this. Does the backgeocoding in your graph work? It uses a lot of the same calculations.

#3

Hi Luis,

Thanks for your answer.

I provide here some extra info.

You mentioned “You get this error when it completes processing but it never got to write anything.”
However if I include a write operator such as the following, I obtain the same error, meaning this happens during the processing and is independent of the presence of a write node.

  <node id="9-Write">
    <operator>Write</operator>
    <sources>
      <sourceProduct refid="8-Subset" />
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <formatName>NETCDF-CF</formatName>
      <file>/tmp/result.nc</file>
    </parameters>
  </node>

“Does the backgeocoding in your graph work?”
Yes, it does. We’ve been using these settings for a long time and, as I said, it works for Sentinel-1A data without any problem.
Do you have any suggestion on how to improve the backgeocoding parameters?

In the attached KML you can find 3 products covering approximately the same area, and the region used in the subset operator.
products.kml (4.1 KB)

If I run gpt with the graph file for product S1B_IW_SLC__1SDV_20170311T172400_20170311T172427_004664_008222_5D07 (or any of the other products listed in the previous message) it fails.
However, if I run the same graph file for product S1A_IW_SLC__1SDV_20170317T172447_20170317T172514_015735_019E70_700D it succeeds.

I also tried to run the same test with a S1B product from yesterday S1B_IW_SLC__1SDV_20170323T172400_20170323T172427_004839_00873C_2684 and it succeeds…

Could this be related with the SAR anomaly of Sentinel-1B of the last days? https://sentinels.copernicus.eu/web/sentinel/news/-/asset_publisher/xR9e/content/id/2862411

Thank you!

#4

Do you have a suggestion on how could we check this?
Thank you

#5

Hi @lveci,

I want to ask you once more to have a look into the issue reported above by one of my developers. We appear to have some issues processing S1B data in some particular cases. Additional tests showed that the problem seems to occur when the problematic S1B products act as the master in the BackGeocoding input stack, where we use another S1A product as the slv. Now the interesting thing is that, when we switch both input products, thus using the S1A product as the master and the problematic S1B product as the slave, everything works fine. I am tempted to conclude from this that there is something wrong in the metadata for the S1B product, which is only used in case it acts as master… Do you agree or am I ruling out any other possible explanation?

As you know we have contacted Copernicus support with this issue (you were included in CC), but the response we got was not very promising in finding the root-cause together with them. Would you be so kind to try and locate the exact source of this issue (being it the s1tbx or metadata anomely) and perhaps assist me in communicating the issue to Copernicus support so they take it serious and quickly escalate it?

Many thanks in advance and I remain at your disposal for more info.

Sven.

#6

We have downloaded the following data set
S1B_IW_SLC__1SDV_20170311T172400_20170311T172427_004664_008222_5D07
S1A_IW_SLC__1SDV_20170317T172447_20170317T172514_015735_019E70_700D
and processed it with the graph below

with the S1B product being the master, and we did not encounter the problem that you had.
We ran the graph in the Graph Builder on Windows and we ran it with our current code (not the build that you are using). It could be that the problem has been fixed during the bug fixing since the last release. You can try the new release and see if you still have the problem.