polar2grid viirs2gtiff crashes on springbok

[rayg-ssec]

I'd like to localize where this floating point exception is coming from. Can you set "ulimit -c unlimited" and get a core dump onto jpss-cloud? And is the input data available somewhere else? Also can you send output for "rpm -qa |grep glibc" and "cat /etc/issue"? Should I get an account on springbok?

The first order questions are

• is this gdal, ms2gt, or python crashing?
• is the kernel version complaint due to the system C library being older than what we build polar2grid/shellb3 with?
• are there other machines that this fails on? does it work on galactica?

The glibc on the CSPP build machine is 2.5-81. The build machine for the ftp site ShellB3 builds is 2.5-65.

On 13 Mar 2013, at 17:39 , Kathy Strabala kathys@ssec.wisc.edu wrote:

Hi Ray,

At our polar2grid meeting today, we decided that it is time to start using the polar2grid software to create the MODIS products that are being viewed in AWIPS. The operational machine that we are using is called springbok, and I have never gotten any of the ShellB3 packages to work on it. I remember there being a statement that said something about the kernel being too old. When I try to run polar2grid on the test data, I get an error message that looks like this:

[kathys@springbok work]$ viirs2gtiff.sh -d ../input /data3/kathys/p2g/polar2grid/bin/viirs2gtiff.sh: line 40: 22134 Floating point exception$POLAR2GRID_HOME/ShellB3/bin/python -m polar2grid.viirs2gtiff -vv $@

Is it possible for you to try to build a version for polar2grid on this machine?
I copied the output of uname -a and cpuinfo below.

Kathy

Linux springbok.ssec.wisc.edu 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux

processor : 3 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 870 stepping : 0 cpu MHz : 995.278 cache size : 1024 KB physical id : 1 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext lm 3dnowext 3dnow pni bogomips : 1992.67 TLB size : 1088 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp

[rayg-ssec]

From Kathy: I put the core file in jpss-cloud:/home/kathys/p2g

I had just installed the package on springbok and was executing it with the test data.

rpm -qa |grep glibc compat-glibc-2.3.2-95.30 glibc-devel-2.3.4-2.19 glibc-2.3.4-2.19 glibc-kernheaders-2.4-9.1.98.EL glibc-devel-2.3.4-2.19 glibc-common-2.3.4-2.19 glibc-2.3.4-2.19 glibc-headers-2.3.4-2.19 compat-glibc-headers-2.3.2-95.30

cat /etc/issue CentOS release 4.3 (Final) Kernel \r on an \m

Should I get an account on springbok? Yes, you should get an account on springbok. Ask them to give you an account on /data3 also.

• are there other machines that this fails on? does it work on galactica? It does execute correctly on galactica. I don't know of any other 64 machines in the buildind

[rayg-ssec]

springbok is CentOS4 so this isn't surprising. had to build tar 1.26 on my account (in ~rayg/opt) in order to get modern tar xf behavior for shallbethree.sh. trying an out-of-box sh shallbethree.sh mk_cspp in a screen session using nice. note that CentOS 4 uses GCC 3.4 - this could be a hairy build...

[rayg-ssec]

Python interpreter built-in isn't sufficient for building libxml2 - had to build a secondary version of that in ~/opt . see build/ShellB3/env.sh ...

[rayg-ssec]

alas, no gfortran either.

[rayg-ssec]

Hi Ray,

Liam and I talked about this yesterday. Thanks for exploring this. We decided that it would be better use of all of our time, to generate the MODIS products for AWIPS on a different machine (dragon). Thanks for you efforts.

Kathy

On Mar 14, 2013, at 5:26 PM, Ray Garcia wrote:

I did a bit of exploratory on springbok and first off, it's on CentOS4 - so the big question is whether it's worth the effort to do a build special for a system that's 2006-vintage. It's using GCC3.4, glibc 2.3, has no gfortran, etc.. I had to rebuild the whole 'tar' utility just to get 'tar xf' used by the build scripts to work, and the built-in python interpreter is 2.3 (originally released 2003), so I had to pre-build python from scratch just to get XML libraries to build.

I think it could be done if I switch over to using the CentOS 4 virtual machine I keep around for compiling S-HIS flight code (a custom linux build from 10 years ago) - but the time might be better spent bringing the machine up to at least CentOS 5.

Opinion?