VH empty polarisation in a single Linux machine

Good afternoon

I have found one of those problems that hate anybody: I have a S1 workflow that works in some machines, and not in a similar machine. Yes, a really funny bug :frowning:

The processed image is S1A_IW_GRDH_1SDV_20170407T192053_20170407T192118_016042_01A791_B715.SAFE, obtained from CreoDIAS, and it is processed using GPT with a standard workflow (attached below), in an up to date Snap installation. Now, the problem: in a machine, the VH polarisation returns all 0, always, while the VV and the angle return some values.

I have tested in Windows (it works), a small Ubuntu 18.04 virtual machine (it works), and a Ubuntu 18.04 dedicated virtual machine with a GPU (it fails).

I guess it is a problem caused by the machine. However, as far as I have read, Snap does not uses the GPU (the main difference between the two Ubuntu machines), and that is the main difference between the Linux machines. My other theory is that it may be caused by network issues, but it does not match with VH always failing and VV always working.

Does anybody have a clue about what can I check?

Thank you in advance!

Luis Herrero

s1_geocode.xml (4.9 KB)

Are both Ubuntu 18.04 VMā€™s fully updated? You donā€™t want to waste time on a bug that has been fixed (or, possibly, a recently introduced bug).

Your workflow has many steps. It would be a big help to anyone investigation the problem to have the simplest possible example. One approach is to break up the workflow into as many separate steps as you can, saving intermediate results. It should then be simple to determine where the failure occurs. You might want to start from a subset of the original image to reduce processing times and disk space, and with a small data set you might be able to modify the original graph save intermediate data after each step.

Hi! Thanks for your quick response.

The VMs were updated not so long ago, but the failing machine has some frozen packages (a specific GPU driver version is required, so it may be the root of the problem. I apologize, this is something usual, which I should have think about before writing, but I did not remembered the frozen packageā€¦ I guess it is that kind of things you realize when you speak with other people.

About the idea of splitting the workflow, I am working on it at the moment. I will let you know id I find something interesting.

Thanks a lot!

Luis

Hi!

It seems that the problematic step is the terrain flattening, which leads to the following node of the GPT script:

<node id="Terrain-Flattening">
  <operator>Terrain-Flattening</operator>
  <sources>
    <sourceProduct refid="Calibration"/>
  </sources>
  <parameters class="com.bc.ceres.binding.dom.XppDomElement">
    <sourceBands/>
    <demName>SRTM 1Sec HGT</demName>
    <demResamplingMethod>BICUBIC_INTERPOLATION</demResamplingMethod>
    <externalDEMFile/>
    <externalDEMNoDataValue>0.0</externalDEMNoDataValue>
    <externalDEMApplyEGM>false</externalDEMApplyEGM>
    <outputSimulatedImage>false</outputSimulatedImage>
    <additionalOverlap>0.1</additionalOverlap>
    <oversamplingMultiple>1.5</oversamplingMultiple>
  </parameters>
</node>

By the way, the image, in the second step, is clipped to

POLYGON((149.917315851 -23.570550519999983, 151.01267004700003 -23.570550519999983, 151.01267004700003 -22.557076721999977, 149.917315851 -22.557076721999977, 149.917315851 -23.570550519999983))

I do not know if being a small area may lead to problems

Thanks!

Luis

Does the problem occur on the other systems if you use the same region? If the size of the region is the problem it should affect all your systems the same way.

Does your problem look like any of the many examples in https://forum.step.esa.int/t/terrain-flattening-black-areas/4231/7?

This is known bug in Terrain Flattening and has been fixed. The fix should be available in the next release

Thank you very much, @jun_lu . If it is a bug, we will use the machines where it works (it will not be beautiful, but it will work)

By the way, and just being curious, what is the bug about exactly? Is there any official ā€œworkaroundā€ to handle until the next release?

Even being a bug, thanks a lot, @gnwiii, for your support. I was checking at the moment the possible causes you sent in a previous message, and I am learning a lot.

Basically the current terrain flattening operator handles one polarization. In case of GRD product, the second polarization is ignored. If you want to get the TF result fo both polarization, currently you have to run the operator twice and select the desired polarization each time

I have tested it running the terrain flattening band by band, and it works properly, so I confirm that the problem is caused by the already known bug in the terrrain flattening.

As a workaround, I have executed terrain flattening twice (as proposed) and then mixed the bands using BandMerge. I have tested it and it seems to work fine.