Interferogram not generated

Dear colleagues,
I went through the RUS training HAZA03: Land subsidence ( & on my PC and the RUS virtual machine at the same time.
To my surprise, at the VM, no interferogram was generated, or more precisely, the file is generated but the phase band only consists of magenta pixels over the whole layer and intensity and coherence bands are empty.
So when trying to find the reason, I have reduced the graph only to preprocessing and found out that in the generated file, the slave layer is empty (see the screenshot).

I have tried it about 4 times and it’s always the same. While on my PC, with precisely the same files and the same graph, the interferogram is generated as supposed.
What could be the reason that it doesn’t work well on my VM? In the webinar, they have also used a RUS VM.
Thank you very much in advance for any tips.

Have you checked if the extents of both images are the same after the split?

As far as I can see, they have the same extent (same width, height, area shown).

yes, looks alright. This could have been a reason why the slave image is black after coregistration (BackGeocoding).

Can you please repeat the workflow using “SRTM 1Sec (AutoDownload)” in the BackGeocoding step?

Thank you very much, Andreas! With SRTM 1s, it worked well :slight_smile:
Also in the next step (topophase removal -> ML -> GoldsteinPhaseFlt -> write & Snaphu Export) it makes a difference: with SRTM 3s (product 6 on the screenshot), the phase and coherence layer are OK but the topophase is not (min= 0, max = 4.9E-324; very uniform), while with SRTM 1s (product 7), everything seems to be correct (for topophase, min~29, max~62).

I wonder why it did work with SRTM3s on my local PC (and on the VM we have seen in the webinar).
Is using SRTM 1s always a good idea? (I suppose it will take longer to process with 1s, and may sometimes generate some downscaling effects dependent on the resolution of the data we are using?)

access to SRTM 3Sec fails from some devices, so 1Sec gives less problems. It does not necessarily lead to better results, but it does no harm either.

Good to know, thank you!

The max value 4.9E-324 looks suspect, is this a valid float64 value?

Probably yes. Found this on stackoverflow:

import numpy as np
np.nextafter(0, 1)

So this should be the smallest positive float64.