Typically a S-1 TOPS product looks like the image below where the pixels in the yellow part have 0 values:

I think that’s why the noDataValue is set to 0. If we have a NoData mask, that will fix our problem. But to create a such mask, we need to know which 0 is valid and which is not

Someone asked on the forum why NoData isn’t simply a binary mask instead of a value. That could be a fundamental fix?

@Marcus Engdahl In the source product, the band’s noDataValue is defined as zero. Therefore, we cannot distinguish the valid zero from the noDataValue. A fundamental fix should be that the noDataValue is defined as some value that is not within the range of valid pixels.

We can updated the online help to inform users about how to use the "Mask out areas with no elevation" option. Also, I am thinking to make the default value for the "Mask out areas with no elevation" option to false. Currently the default value is true. But I need to discuss this with Luis because it will impact many users

@Jun Lu But why are zeros still treated as invalid pixels? I though this was fixed many years ago already. What is the fundamental fix? Zero should probably never be used as the default NoData-value in SNAP as it causes issuees so frequently.

Also, how will users be informed that "Mask out areas with no elevation" should not be used?

The problem was caused by that the valid zeros in slave I/Q bands are treated as invalid pixels and output as NaN's in Back Geosoing. We have fixed the performInterpolation function to output noDataValue instead of NaN. This is not a fundamental fix and users still need to disable the "Mask out areas with no elevation" option in Back Geocoding in order to avoid the problem mentioned above.