SNAPHU export and file paths

Microwave Toolbox
#1

The SNAPHU export operation creates a snaphu.conf file which references the inputs. It also has a useful snippet informing the user how to manually run snaphu, e.g.:

#       snaphu -f snaphu.conf Phase_VV_15Aug2016_27Aug2016.snaphu.img 4475

That’s fine, but assuming someone really tries to run that command, they might be surprised to see that snaphu crashes. The issue is that the path to CORRFILE is relative to the snaphu.conf directory. snaphu tries to open it, fails, but logs the error in a file called snaphu_tiles_$PID/tmptilelog_$X_$Y, which might not be obvious to the user.

Relevant snaphu.conf snippet:

CORRFILE 		coh_IW3_VV_15Aug2016_27Aug2016.snaphu.img
OUTFILE 		UnwPhase_VV_15Aug2016_27Aug2016.snaphu.img
LOGFILE 		snaphu.log

It would be better to use absolute paths here in order to make debugging easier for users.

Additionally, the process count seems to be set to 4:

NPROC              4

Since the phase unwrapping is somewhat slow, it might be a good idea to use something closer to the CPU count of the computer instead.

RuntimeError: java.lang.NullPointerException in snappy
#2

Sample of snaphu crashing because of this issue:

$ ./snaphu -f ~/snaphu_test/snaphu.conf ~/snaphu_test/Phase_VV_15Aug2016_27Aug2016.snaphu.img 4475

snaphu v1.4.2
27 parameters input from file ~/snaphu_test/snaphu.conf (84 lines total)
Logging run-time parameters to file snaphu.log
Creating temporary directory snaphu_tiles_17423
Unwrapping tile at row 0, column 0 (pid 17424)
Unwrapping tile at row 0, column 1 (pid 17425)
Unwrapping tile at row 0, column 2 (pid 17426)
Unwrapping tile at row 0, column 3 (pid 17427)
Unexpected or abnormal exit of child process 17424
Abort
#3

are you sure this error is related to the relative/absolute paths?

I ran snaphu multiple times (successfully) and whenever I received an “abnormal exit” it was related to the parameters (number of tiles, for example)

#4

In my case, yes. Note that I’m only using the export functionality in SNAP.

strace -f output:

[pid 14583] openat(AT_FDCWD, "coh_IW3_VV_15Aug2016_27Aug2016.snaphu.img", O_RDONLY <unfinished ...>
[pid 14581] read(5,  <unfinished ...>
[pid 14583] <... openat resumed> )      = -1 ENOENT (No such file or directory)

It works if I run it from the expected directory, but this thread is about making life easier for users that don’t or can’t follow the expected workflow (because e.g. running snaphu from SNAP doesn’t work for them).

$ cat snaphu_tiles_17423/tmptilelog_0_0
snaphu (pid 17424): unwrapping tile at row 0, column 0

Current working directory is ~/snaphu/bin
Reading wrapped phase from file ~/snaphu_test/Phase_VV_15Aug2016_27Aug2016.snaphu.img
No weight file specified.  Assuming uniform weights
Reading correlation data from file coh_IW3_VV_15Aug2016_27Aug2016.snaphu.img
Can't open file coh_IW3_VV_15Aug2016_27Aug2016.snaphu.img
Abort
#5

I agree. But this is the case for any scripting language, right? If no full path is given, the file is expected in the current working directory.
On the other hand, I see no downside of adding the full path when the conf file is generated by SNAP.

#6

My command line has the full paths:

$ ./snaphu -f ~/snaphu_test/snaphu.conf ~/snaphu_test/Phase_VV_15Aug2016_27Aug2016.snaphu.img 4475

The not so obvious issue is that ~/snaphu_test/snaphu.conf contains references to other files, and if the user doesn’t notice this and happens to run shaphu from some other directory, it will fail with a not-quite-useful error message.

Exactly, that’s what I’m suggesting.

#7

I can be wrong but if it was a path problem, my guess is that the process wouldn’t even start.

#8

It starts and crashes rather quickly with no useful error message, as you can see in my second post.