1 / 11

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

Progress in Multi-platform Software Deployment (Linux and Windows) Tim Kwiatkowski. Welcome Consortium Members November 29, 2012. Overview. Where we started Where we are now The AASPI Operational Structure Challenges How we intend to proceed. Where We Started….

faith-levine
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Progress in Multi-platform Software Deployment (Linux and Windows) Tim Kwiatkowski Welcome Consortium Members November 29, 2012

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

  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

  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… • Remove the final straggling SEP codes. (Some rarely used code I believe) • Remove remaining UNIX dependencies from the GUI code. • Migrate to Python Scripts. • Fully test our I/O library on Windows. • Test our non-MPI C++ codes on Windows with the new scripting layer. • Create core Fortran libraries with and without MPI support or split our core library as MPI/non-MPI. • 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. • Put everything together for a full AASPI code release for Windows

  11. AASPI Software Computational Environment Tim Kwiatkowski Thank You! Questions?

More Related