Progress in Multi-platform Software Deployment(Linux and Windows)

Tim Kwiatkowski

Welcome Consortium MembersNovember 29, 2012

1

• Where we started• Where we are now• The AASPI Operational Structure• Challenges• How we intend to proceed

Overview

2

3

Where We Started…

• All of our code was based on the Stanford Exploration Project I/O and utilities along with Seismic Unix (which SEP depends on for SEGY import at least)

• The SEP/SU code was heavily tied to UN*X and UN*X internals.• Pipes (supported by windows but differently)• Sockets (No internal sockets)• Other trickery like prog > out.H would

determine the output name out.H.

• No Graphical Interfaces. All graphics utilities were based on SEP vplot library which supported all kinds of old and arcane terminals and output devices.

4

Where We Are…

• All of our I/O is now rewritten in C++ with multiplatform support. No SEP/SU dependency.

• We have opted not to use pipes in our base codes even though the I/O library does support this. All code basically adheres to POSIX standards where possible.

• We have GUIs using a multiplatform toolkit (The FOX Toolkit) although there is still code to spawn the shell scripts which is not yet multiplatform.

• Using the same GUI library, we now have our own graphics support.

5

The Basic AASPI Structure

AASPI Core ProgramsNew I/O core written in C++ is multiplatform. With the Intel Fortran compiler, code compiles.

The core has not been tested extensively on Windows. We still may have a few gotchas. Third party library

dependencies are an issue. (MPI, FFTW, Lapack)

Driver scriptsMultiplatform Scripting Language

(Python)Majority of scripts still use Unix-based Bourne shell scripts (bash)

AASPI Graphical User InterfaceMultiplatform GUI Toolkit Code to spawn scripts still not

multiplatform

6

The Challenges…

• Multiplatform graphics – We have this one mostly covered.

• File path specifications – Windows uses a different path separator and a concept of drive letters. This makes moving files between platforms a bit tricky. In addition, I/O internals need to be aware of these differences.

• Multiplatform scripting – This has some of the same problems with path specifications and OS differences. Python offers good support for handling this.

• Third party libraries – FFTW3, Lapack, BLAS, MPI. There is support for FFTW3, Lapack and BLAS under Windows.

7

The Big Challenge…

• MPI – The Message Passing Interface.

• MPI allows us to tackle the big problems in a reasonable amount of time on large Linux clusters.

• Most of the AASPI codes such as dip3d, curvature3d, sof3d and others depend heavily on MPI.

• Although there is a non-MPI option on most of the codes:• The programs will run slow…• Logistically, we still have an MPI library linked

into the code. However, we can build some type of a “dummy” library to handle the linking issue.

8

Dealing with MPI

• MPI – The Windows platform does not lend itself well to supporting MPI.• Security and Firewall issues.• Microsoft Cluster Services support MPI/HPC

• BUT, it requires essentially a modified Windows release this is part of Windows server line.

• We do have a candidate implementation of MPI for Windows:• DeinoMPI

• This implementation deals with the security issues and doesn’t require a server version of the OS. Requires .NET

• We have not evaluated this as yet although it looks like a promising solution.

9

Other Considerations

• Not are only are we interested in Microsoft Windows Support, we are interested in supporting batch queuing systems such as LSF under Linux. Some institutions provide access to their Linux clusters only through batch queues.

• We have are own interest in this as well. In order to fully access our own supercomputing capabilities at OU (OSCER), we need to adopt that as well.

• This support will mostly involve revamping our scripting layer. This support will be included as we recode all of our scripts in Python.

10

How we intend to proceed…

1. Remove the final straggling SEP codes. (Some rarely used code I believe)

2. Remove remaining UNIX dependencies from the GUI code.

3. Migrate to Python Scripts.4. Fully test our I/O library on Windows.5. Test our non-MPI C++ codes on Windows with

the new scripting layer.6. Create core Fortran libraries with and without MPI

support or split our core library as MPI/non-MPI.7. Release a preliminary Windows version for non-

MPI code. Unfortunately, this leaves out a major part of our software if we stick to non-MPI code.

8. Put everything together for a full AASPI code release for Windows

AASPI Software Computational EnvironmentTim Kwiatkowski

Thank You!

Questions?

11