SNAP/snappy system requirements

development
#1

I’m trying to use SNAP/snappy on a super-computer which has older system architecture. I understand that GLIBC 2.14, Oracle JDK 8, Apache Maven 3, JPY, JBLAS, and glibfortran3 are required for snappy to run properly.

I don’t have admin rights, so I’ve installed the required dependencies separately. By default the system has:

  • SUSE Linux Enterprise Server 11 SP4
  • GNU libc 2.11.3
  • GNU Fortran (SUSE Linux) 4.8.5
  • java version “1.7.0_21”
    OpenJDK Runtime Environment (IcedTea 2.3.9) (suse-0.17.15-x86_64)
    OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
  • Python 3.4.2 (default, Jan 20 2015, 14:34:56)
    [GCC 4.7.2 20130108 [gcc-4_7-branch revision 195014]] on linux

Through trial and error and using the forum as a guide, I managed to do:

  • Separate install of Python 3.4.2 (default install was missing ‘bdist_wheel’ that is required by JPY)
  • Install GCC 9.2.0 (with dependencies gmp-6.1.2, mpfr-4.0.2 and mpc-1.1.0) to fix GLIBC version
  • Install Oracle JDK 8, JRE 8, Maven 3.6.3, and JPY
  • Install JBLAS (with lapack-lite-3.1.1, atlas-3.8.3 and ant-1.10.7 dependencies)
  • Created a conda environment to run snappy

With the above, I can get snappy to read input zip files, apply orbits, concatenate two scenes for a date, split by swaths and save each swath as a *.dim file. When I go to the next processing step (back geocoding, ESD, initial ifg, deburst, multi-look, filter, write output), I get a fatal error when trying to write the *.dim file:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe8e4da500c, pid=18162, tid=0x00007fe8e45f2700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64 )
# Problematic frame:
# C  [libjblas.so+0x1b000c]  ATL_dcopy_xp0yp0aXbX+0x1c

If I exclude the write function, it runs without any errors. My research suggests that ‘SIGSEGV occurred with a thread executing in the library libjblas.so’.

I’m stuck and can’t find a solution to fix this problem. Given the older architecture, I’m not sure if there are just too many conflicts causing problems in the back-end.

Can anyone advise if the system is just too old to run SNAP/snappy properly without lots of modifications, or if there is something else I can try to get it working?

Thanks

#2

Did you configure atlas for multi-thread support? Jblas Issue 107 indicates others may have encountered this. There are alternatives to Atlas which might have multi-thread support.

Since the problem appears to be with jblas (and ultimately with atlas or gcc 9), so your best hope is to contact the upstream developers. The
good news is that multi-threading blas have been used for years on super-computers, so should be a “solved problem”.

#3

Thanks, I tried to configure Atlas for multi-thread support, but it didn’t work properly. So I used OpenBLAS instead which appears to be multi-threaded as standard.

I could install everything with no errors, but unfortunately I still get the same fatal error. Rather than continue battling this system, I’ll see if it can be upgraded or use a different system.

#4

Have you checked upstream Atlas for multi-thread advice? The jblas-users forum gives some tweaks needed for a multithreaded Atlas build.

#5

Thanks, after a lot of trial and error I’ve managed to install all the dependencies and it appears snappy works, but if I run gpt on the command line, it creates a new library error. As a result of all this, I’ve been given a different system with admin rights to try and use instead.