Error converting phase to elevation for DEM generation


I am getting an error during the final step of the DEM generation process when executing the phase to elevation function. I am using the Fogo dataset from the TOPS Interferometry tutorial. I will first outline how I am generating the data because the tutorial I was following focused on deformation, not topology and I may have missed a fundamental earlier step:

1 Open the products: For DEM generation the products must be Single Look Complex (SLC), and have the same Mode, Track and pass.

2 Coregister the images into a stack:
Radar -> S1 TOPS coregistration -> S1 TOPS Coregistration

3 In the TOPSAR-Split tab, select the IW3 subswath for each of the products.

4 Interferogram Formation:
Radar -> Interferometric -> Products -> Interferogram Formation

4 TOPS Deburst to join all burst data into a single image:
Radar -> Sentinel1 TOPS -> S1-TOPS deburst

5 Goldstein Phase Filtering
Radar -> Interferometric -> Filtering -> Goldstein Phase Filtering

6 Unwrap into SNAPHU format:
Radar -> Interferometric -> unwrapping -> Snaphu export
make sure the statistical cost mode if TOPO for DEM in snaphuExport
7 Run Snaphu. It must be compiled and run on linux (or possibly cygwin)
The export generates a snaphu.conf file that contains the command to execute, e.g.:
snaphu -f snaphu.conf Phase_ifg_IW3_VV_03Nov2014_27Nov2014.snaphu.img 3946

Snaphu currently crashes with Segmentation fault (core dumped) on 64 bit machines. This is due to a problem in the source:

This is caused by ctime() function in src/snaphu_io.c file [1]. To solve this problem, edit this file, change “#include <sys/time.h>” into “#include <time.h>”, and then compile and install again

8 Import Snaphu:
Radar -> Interferometric -> unwrapping -> Snaphu import
make sure the read-phase is the package you exported and the read-unwrapped-phase is
the .hdr file outputted by snaphu

9 Generate DEM by converting phase to height:
Radar -> Interferometric -> products -> Phase to Height

10 Apply Range Doppler Terrain Correction:
Radar -> Geometric -> terrain correction -> Range Doppler Terrain Correction.

I get the following error at step 9:
org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(
at org.esa.s1tbx.insar.gpf.PhaseToElevationOp.computeTileStack(
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(
Caused: org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
at org.esa.snap.core.gpf.internal.OperatorExecutor$GPFImagingListener.errorOccurred(
at com.bc.ceres.glevel.MultiLevelImage.getData(
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(
[catch] at

I have tried several variations on the approach but all of them get the same exception. I have also tried phase to height but when I click run, nothing is output. Any help understanding the bug or working out where I went wrong would be greatly appreciated.

Elevation horizontals

Did you try phase to elevation instead of phase to height?


apologies, step 9 should have said phase to elevation, which is throwing the null pointer exception. I only tried phase to height the last time and accidentally wrote it down. Phase to height doesn’t throw an error but doesnt output anything either.

All the guides specify executing phase to elevation which is what I use.


Do you use the latest version of SNAP?


I use the latest version of snap on linux but I also tried version 5 and version 4 on windows to see if the version was the problem. I had the same problem on all versions


just to confirm, do those steps look correct, am I using the right approach?

Submitting a bug to the snap toolbox team
Submitting a bug to the snap toolbox team

yes. I would have done it the same.


Thanks for clarifying. I tried the exact same process on my windows desktop and it produces the same error. I will file a bug report. Thanks for your help!


Hi everyone

When I am applying phase to elevation operator (DEM generation) after import of snaphu process. I have following error.

Please help
I have adopt following processing chain

  1. S1 TOPS Coregistration
    -Read - Apply orbit file (Auto download) - Backgeocoding using SRTM 3sec (Auto download)

  2. Interferogram Generation
    -Subtract Flat earth phase - Include coherence estimation - Square pixel Rg=10, Az=2

  3. S1 TOPS Deburst

  4. Goldstein Filtering
    Window size=3

  5. Multilooking
    1 x 4 looks

  6. Snaphu Export
    using TOPO

  7. Phase unwrapping using Cygwin terminal
    Completed successfully

  8. Import snaphu

  9. Phase to elevation operator (DEM generation)

I got error in step 9

Plz help


I think you should remove this step and try out once more.


Okay, I will do it and share results with you. Thank you


Hello Falahfakhri

I got the same error again, i didn’t apply multilooking this time.
Please help


I tried it with different datasets and got the same error. I think there is
something wrong with the phase to elevation code.


May be you are right


I’m sorry for delay but as I got from your explanation that the unwrapping processing the export and import run properly with out any error?


still not working for me. It seems to be an old bug that was not fixed:

which is strange because it is quite basic functionality.
If you need to get DEMs now then it is best to go for the NASA 1 arcsecond SRTM mission:

All the processing is done and you can download the DEMS directly.


It’s quite safe to assume that SRTM is of better quality than a DEM generated from a single repeat-pass InSAR pair.


I was hoping to merge repeated scans to see if that generated a more
accurate model but it may have ended up rounding out the peaks.,


I Have this DEM and I am wondering which one is correct
by using Phase to elevation or phase to height
it is the same area with same data just one by elevation and the other is to height
if you look well there is a deference between ?

Thank you


@squeakus was the phase to elevation working for you now? Because I have the problem that the hole process runs without an error, but the DEM is just not looking like a DEM and the values are realy funny (for example - 6000 to + 6000 and I am not working in Himalaya region :wink: ) I also tried the phase to height but this was not running but also did not show an error, just nothing happened. I tried this with a lot of different S1 pairs and also with other radar data like TD-X and TS-X, but always the same issues… And of course I tried different versions of SNAP (3 / 4/ 5).

Any ideas? Maybe @ABraun?
Thank you!