ARSC HPC Users' Newsletter 239, February 15, 2002
Workshop on OpenMP Applications and Tools (WOMPAT)
WOMPAT 2002 Announcement ======================== Dates: August 5-7, 2002. Location: Arctic Region Supercomputing Center, University of Fairbanks, Fairbanks, ALASKA.
The Workshop on OpenMP Applications and Tools (WOMPAT 2002) will serve as a forum for users and developers of OpenMP to meet, share ideas and experiences, and to discuss the latest developments in OpenMP and applications.
WOMPAT2002 follows a series of workshops on OpenMP, such as WOMPAT2001, EWOMP2001, and WOMPEI2002. It is part of the cOMPunity initiative whose main objective is the dissemination and exchange of information about OpenMP. (See http://www.compunity.org/ for more details of this activity and contents of past meetings.)
WOMPAT2002 is co-sponsored by the OpenMP Architecture Review Board.
Contributions are welcome and a one page extended abstract, either ASCII text or pdf, should be sent to:firstname.lastname@example.org
The deadline for submission of abstracts is April 19th. More details of the meeting can be found at http://www.compunity.org/ shortly. See issue 217 ). Out of the huge number of MPI operations available, there is a small portable subset -- and a small number of portable ways to use that subset.
In general, codes get to be more robust as they are ported to different systems. Compilers tend to interpret "correct" code uniformly, and differ on the weird stuff. If a program works the same way on several different systems, it's also more likely to be easily maintainable and scalable. Thus it will also better survive system upgrades and their inevitable retirement.
You may notice there are some familiar elements from software engineering in the above list. Looking at requirements and design as much as possible on paper first (as opposed to just sitting down and coding) has been recognized as good practice for decades. If you can't draw a good picture of how the data needs to move around, you'll probably spend much longer coding -- with less chance of it working correctly in the end -- than if you had done the preliminary work.
Making sure code continues to work correctly while adding a new message passing scheme can be difficult. If a data set is 3D, visualizing in 3D can save a lot of headaches. I've found that visualization, combined with some numerical check (i.e. iterating over all values in an output file, checking that all differences fall within an allowable tolerance range from an output file as produced by a verified run of the original code) works best. The shortcomings of each are compensated by the other.
So far I've only started on the test code. The original is far too cumbersome for repeated trials. The savings in compile time alone far exceed the time required to create the test. It's also easier to fit how the test code works into my little brain, focusing on one problem at a time.
Out of all of the absurdities of life, this one is pretty small. If Nietzsche could conclude "that which does not kill us makes us stronger" after pondering many of the bigger strangenesses of how hard-won things so easily shift to irrelevancy in the modern world, I can rewrite a little program. I figure I'll just have to be philosophical about it... Fortunately, with all of the different systems on which to test the code (MPI is available on ARSC's IBM, Crays, SGIs, and Linux cluster) and all of the helpful people at ARSC it is quite possible to write a program that will be robust and portable -- thus far better able to withstand the constant change on the systems where it must run.
Quick-Tip Q & A
The quick tip is still in hibernation... If you have any tips to share, we'd love to see them.
Many thanks to those who have already responded to this plea!
[[ Answers, Questions, and Tips Graciously Accepted ]]
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669 Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
Subscribe to (or unsubscribe from) the e-mail edition of the
ARSC HPC Users' Newsletter.
Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.