Can you point the users of the CentOS 5.5+ (redhat enterprise linux comes with Python 2.4) to a recommended page for adding and using python 2.7 with SeaDAS?

I ask since what I have found so far says:

"So, we have all heard the horror stories of replacing the 2.4 interpreter with a newer one that is not offered in any of the maintained repos. Clouds part, log files build, mutt inboxes overflow and yum (among many other binaries) basically die.... Whatever the reason, replacing the 2.4x interpreter is f'n spooky and bad juju no matter how you smoke it."

Thanks,
Brock

Brock,

You need not replace the existing python.  You can have both installed side by side.
This is what was done for our 32bit linux development box (also CentOS 5.5 ... for now,
within 6 months we'll no longer have CentOS systems here).

There is a new script  ($SEADAS/run/scripts/pyverchk.py) that will check the default
installed python version, and give you the option of pointing the SeaDAS python scripts
to another installed version if it sees that the default version is not at 2.6 or higher
(in the 2.x series).

Sean

If you're "dumping" CentOS, what is going to be your "preferred" linux platform?

Bruce,

We don't have a preferred platform, nor do we endorse any distribution.
Choose what suites you're needs.  My comment about CentOS was for
informational purposes only - to let you know that the current SeaDAS
32bit build was created on a CentOS system, so I know that python 2.6
is available for it and can run in parallel with the default 2.4 installation.

As our production system is being migrated to 64bit servers, that older
32bit CentOS system will be decommissioned.
No, we did not choose CentOS as the OS for the 64bit servers, but what
we chose should not influence your decisions.

Sean

Sean,

I understand that they should be able to coexist, I was wondering if you would point out a reference page or link that can help us make that happen.
A good way to ensure that no cross-containation occurs? Our production servers are 64 bit and updated to CentOS release 5.7 (Final).
We are not planning on changing that for a variety of reasons. And as you stated, shouldn't matter.

Since you have already done this on a 32bit CentOS platform, your experience in this is invaluable.

Brock

Brock,

I didn't do it, one of our sysadmins did.  I believe he simply found an RPM and installed it.
You could go to the python website, download the tarball, read to the bottom of the README
paying attention to the sqlite3 and multiple installtions sections, run "configure" with the
appropriate options, make and install...

Sean

Sean,

I am seeing this:

optics 121 :/optics1/software/seadas/seadas_6.3> ./config/seadas_setup
Your default python interpreter is too old.
Do you have another python installation >= v2.6? (Y or N): Y
What is the full path to your python (v2.6 or greater)?: /optics1/software/python27/bin
/optics1/software/python27/bin does not exist.
What is the full path to your python (v2.6 or greater)?: /optics1/software/python27/bin/python
Traceback (most recent call last):
  File "/optics1/software/seadas/seadas_6.3/run/scripts/pyverchk.py", line 46, in ?
    pylons = os.listdir(os.path.join(os.getenv("OCSSWROOT"), 'run', 'scripts'))
  File "/usr/lib64/python2.4/posixpath.py", line 62, in join
    elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
IDL Version 8.0.1 (linux x86_64 m64). (c) 2010, ITT Visual Information Solutions
Installation number: 17539.
Licensed for use by: USF Dept of Marine Sciences

Is this an issue?

I think it is as the first thing I tried to do was update the luts:
optics 124 :/optics1/software/seadas/seadas_6.3> seadas
IDL Version 8.0.1 (linux x86_64 m64). (c) 2010, ITT Visual Information Solutions
Installation number: 17539.
Licensed for use by: USF Dept of Marine Sciences

SeaDAS Version 6.3 (pid = 14243)
SeaDAS>
update_luts.py aqua --verbose
Traceback (most recent call last):
  File "/optics1/software/seadas/seadas_6.3/run/scripts/update_luts.py", line 12, in ?
    import modules.lut_utils as lu
  File "/optics1/software/seadas/seadas_6.3/run/scripts/modules/lut_utils.py", line 4, in ?
    import ProcUtils as ProcUtils
  File "/optics1/software/seadas/seadas_6.3/run/scripts/modules/ProcUtils.py", line 44
    with open(file, 'wb') as file:
            ^
SyntaxError: invalid syntax

Thanks,
Brock

I think the error is a result of not defining the python binary prior to running ./config/seadas_setup

optics 142 :/optics1/software/seadas/seadas_6.3> which python
python:          aliased to /optics1/software/python27/bin/python
optics 143 :/optics1/software/seadas/seadas_6.3> ./config/seadas_setup
Your default python interpreter is too old.
Do you have another python installation >= v2.6? (Y or N): Y
What is the full path to your python (v2.6 or greater)?: /optics1/software/python27/bin/python
The following scripts have been modified to use /optics1/software/python27/bin/python as the interpreter:
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_GEO.py
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_L1A.py
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_L1B.py
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_L1A_extract.py
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_geocheck.py
        /optics1/software/seadas/seadas_6.3/run/scripts/modis_atteph.py
        /optics1/software/seadas/seadas_6.3/run/scripts/update_luts.py
        /optics1/software/seadas/seadas_6.3/run/scripts/getanc.py
IDL Version 8.0.1 (linux x86_64 m64). (c) 2010, ITT Visual Information Solutions
Installation number: 17539.
Licensed for use by: USF Dept of Marine Sciences

% Compiled module: SDS_ENV.
optics 144 :/optics1/software/seadas/seadas_6.3> seadas
IDL Version 8.0.1 (linux x86_64 m64). (c) 2010, ITT Visual Information Solutions
Installation number: 17539.
Licensed for use by: USF Dept of Marine Sciences

SeaDAS Version 6.3 (pid = 17440)
SeaDAS>
update_luts.py aqua --verbose
[ MODIS ]
+ leapsec.dat
+ utcpole.dat
[ MODIS: AQUA ]
[ Done ]

> but what we chose should not influence your decisions.

OK, I'll toss this out there...  So I can choose *any* Linux distribution and you'll "support" it?

In the "old days" I was a die-hard fedora user, consistently upgrading to the most recent version within days of availability.  At one point that "broke" SeaDAS and the response from you (the generic group, not Sean in particular) was something along the lines of "we plan on supporting every other even release (6, 10, 14, etc). 

At that point, as much as it pained me, I fell back to CentOS as that was one of the Linux distros that you supported.

I'd MUCH prefer to go back to a bleeding edge release but if it's going to break SeaDAS again, I won't. 

If I knew which 64 bit release you were using, SeaDAS is much more likely to work, thus my question about which one you're using (it should help be make a hopefully more intelligent decision).

Bruce

Bruce,

No, I didn't say we'd support it, I said it should build.  We're happy to provide
guidance as we are able, but as the saying goes - your mileage may vary.

In the 'old days', the SeaDAS development was separate from the science code. 
Much of the porting to was done by the SeaDAS developers, not the science
software developers.  This was also a time when there were more differences
between the various OS's that SeaDAS supported.  Over time, three major things
have occurred.  First, there is now a greater parity between the various OS's.
(We also no longer support Sun, IRIX or PowerPC platforms.  Not that the code
won't build on these, we just no longer have any to try it on.)
Second, we reorganized and there is no longer a separation of developers.
And finally, we wanted to make the code 64bit compatible.  So, over time we
have made the code cleaner and reduced the number of magic incantations
necessary to get the code built.

So should build on just about any linux distribution (or even Sun, IRIX, and PowerPC)
with the required  compilers.  As for our 64 systems, we have settled on Ubuntu.  This
is not an endorsement, just a bit of FYI.

As things stand now, the 64bit system we have includes glibc2.7 - so if you have
an OS with an older glibc, the binaries we distribute won't work.  Our 32bit system
is still using 2.5, so it's binaries are more "portable".

Sean

Do you consider "Your libXX version is too old for SeaDAS, please recompile or upgrade" to be adequate support, or does your definition of support mean OBPG should provide a binary version that works for you?

Current mainstream distros have made big strides in improving compatibility, so "recompile or upgrade" will work in nearly all cases.  The main problems in providing cross-platform binaries these days are a) differences in library versions supplied by the distro and b) figuring out which package contains the library that is missing.   SeaDAS avoids many of these problems by including key libraries (hdf4, hdf-eos, hdf5, netcdf, gsl, etc).  As for trying to match what OBPG uses, you would also have to duplicate the hardware so you don't run into buggy drivers, etc.

[edit 2012-03-17] A case where "recompile of upgrade" didn't work -- I have SeaDAS 6.3 working (including builds) on Scientific Linux 6, but build fails on the RHEL 6 box because libm.a (needed with the "-static -lm" options used in the lib3 makefiles) isn't found.  Our RHEL admin looked high and low, and only finds libm.a in compatibility package for older gcc versions.  I don't know is this is an oversight or part of the general push to eliminate static linking (for reasons of security).   I plan to try using SL binaries in RHEL, but won't have access to the machines for a couple weeks.

SeaDAS use case: I just (e.g., during the workshop new versions of the linux distro and SeaDAS were released!) came back from a workshop where we used SeaDAS-6.2 in Lubuntu 11.04 with VMware player hosted on Windows 7.  [I chose this over NASA's seadasva because I wanted to simulate
installing SeaDAS on a stand-alone linux system (and also because I like to load a bathymetry image first off to check the display capabilities and the seadasva needs tweaks to make this work).]  To run SeaDAS-6.2 we needed to install the tcsh and libxp6 (xprint) packages and then chose a suitable SDSWFONT.  

The "best" distro for SeaDAS  is the one that you can configure to meet your needs for the least effort.   Suppose OBPG uses Ubuntu YY.MM.  I've noticed that Ubuntu is running into problems with outdated mirror sites, leading to situations where installs/updates fail because some of the required packages are missing from the mirror site you are using, so for many users Ubuntu configuration has become more difficult for reasons that have nothing to do with the "inherit properties" of the distribution.  Unless you are familiar with Debian packaging and have a reliable nearby Ubuntu mirror, you might be better off sticking with an rpm-based distro, and it doesn't take a lot of time lost to problems with bad mirror sites to justify the expense of a commercial linux license if it gets you robust access to the packages.

Virtual machines allow you to explore configuration issues using the virtualized, e.g., standardized, hardware (but you can still run into problems caused by bugs in host hardware drivers).  

If you are using l2gen heavily there are considerations of the mass storage configuration and filesystem.  It takes some effort to get linux on decent hardware, e.g., desktop core i7, to match the performance of Apple machines with lower specs, e.g., laptop core i5.  

George,

We provide three "generic" binary distributions (32bit linux, 64bit linux and intel mac - currently 32bit).  We cannot
custom build binaries for any users particular flavor of OS, so if the binaries we supply do not work on a particular
system, we provide the source so that the binaries can be recompiled locally.  We will provide what assistance we can
for users who have to go the 'recompile route' - but in any event the support we can provide will be limited as our
resources are limited.  That said, we have done our best to make the build go as smoothly as possible.

Two of the three things you needed to do to get 6.2 running are due to IDL (libxp6 and SDSWFONT), the third was
eliminated with the migration to python in 6.3.  The first two go away with SeaDAS 7 (although there will be the added
requirement of java...)

As for the remainder of your comments, good points Thanks for providing your perspective.

Sean