[OMPI devel] VampirTrace within OpenMPI
Finally, VampirTrace is usable from within OpenMPI. From the tmp/vt-integration/ repository you can get an extended OMPI version: #> svn co http://svn.open-mpi.org/svn/ompi/tmp/vt-integration #> cd vt-integration #> ./autogen.sh #> ./configure --prefix=/tmp/openmpi_with_vampirtrace/ #> make #> make install Then you should be able to compile a small MPI example with 'mpicc' and run it with 'mpirun'. Now simply change 'mpicc' to 'mpicc-vt'. The run command is still the default 'mpirun'. If you run the new executable again you'll find an 'a.otf' file plus 'a.0.def' plus some 'a.*.events' files. Some files may have a '.z' suffix which is optional (additional zlib compression). There are a few issues left however. - we need to add a ''---disable-vampirtrace" configure parameter - So far, the configure option '--platform=optimized' makes vampirtrace use the same very strict compiler warnings as openmpi. thus, it will stop with an error because of "-Werror'. we'll check this but so far without '--platform=optimized' everything is fine. - Sometimes vampirtrace detects another installed MPI lib and wants to link it which results in linker errors when building your mpi app. This is because vampirtrace is configured and build before mpi is ready, which is unusual. this is another thing for us to fix. - 'make dist' seems to work fine including all necessary vampirtrace files. maybe this needs to be tested, however - updating the included vampirtrace version should be as simple as extracting a new tarball in the subdir 'tracing'. we could even check + fetch the latest tarball via wget when one does 'make update-vampirtrace in subdir 'tracing'. what's your opinion? - we need an new configure option which simply passes special optionto vampirtrace's configure script So much for the most important issues. If you're interested please try it and send us your results. @Jeff, can we give read access to the tmp/vt-integration/ subtree of SVN? best regards, andreas ps: I'll be out of office for next three weeks but Matthias will respond (at least for a part of this time). -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 pgpHxjjrWafGV.pgp Description: PGP signature
Re: [OMPI devel] VampirTrace within OpenMPI
On Aug 10, 2007, at 5:54 AM, Andreas Knüpfer wrote: Finally, VampirTrace is usable from within OpenMPI. From the tmp/vt-integration/ repository you can get an extended OMPI version: Thanks for doing this. Although I promised to help, I've had zero time to do so recently. :-( #> svn co http://svn.open-mpi.org/svn/ompi/tmp/vt-integration #> cd vt-integration #> ./autogen.sh #> ./configure --prefix=/tmp/openmpi_with_vampirtrace/ #> make #> make install Then you should be able to compile a small MPI example with 'mpicc' and run it with 'mpirun'. Now simply change 'mpicc' to 'mpicc-vt'. The run command is still the default 'mpirun'. If you run the new executable again you'll find an 'a.otf' file plus 'a.0.def' plus some 'a.*.events' files. Some files may have a '.z' suffix which is optional (additional zlib compression). Sweet. There are a few issues left however. - we need to add a ''---disable-vampirtrace" configure parameter - So far, the configure option '--platform=optimized' makes vampirtrace use the same very strict compiler warnings as openmpi. thus, it will stop with an error because of "-Werror'. we'll check this but so far without '--platform=optimized' everything is fine. - Sometimes vampirtrace detects another installed MPI lib and wants to link it which results in linker errors when building your mpi app. This is because vampirtrace is configured and build before mpi is ready, which is unusual. this is another thing for us to fix. - 'make dist' seems to work fine including all necessary vampirtrace files. maybe this needs to be tested, however - updating the included vampirtrace version should be as simple as extracting a new tarball in the subdir 'tracing'. we could even check + fetch the latest tarball via wget when one does 'make update-vampirtrace in subdir 'tracing'. what's your opinion? It might be easier to just allow compiling / linking against a VT that is outside of the OMPI tree. - we need an new configure option which simply passes special optionto vampirtrace's configure script We'll probably also want to put VT into the /vendor branch (per http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.advanced.vendorbr). So much for the most important issues. If you're interested please try it and send us your results. @Jeff, can we give read access to the tmp/vt-integration/ subtree of SVN? I think I set the SVN privs right; the public should now be able to read this directory. -- Jeff Squyres Cisco Systems
[OMPI devel] Public tmp branches
Right now all branches under /tmp are private to the OMPI core group (e.g., to allow unpublished academic work). However, there are definitely cases where it would be useful to allow public branches when there's development work that is public but not yet ready for the trunk. Periodically, we go an assign individual permissions to / tmp branches (like I just did to /tmp/vt-integration), but it would be easier if we had a separate tree for public "tmp" branches. Would anyone have an objection if I added /public (or any better name that someone can think of) for tmp-style branches, but that are open for read-only access to the public? -- Jeff Squyres Cisco Systems
[OMPI devel] Status update
Hello all This is just to let you know of a change in my status. I will be on vacation all of next week (Aug 13-17), and possibly part of the following week as well. I will not have my computer with me, so I will not be reading or responding to email for up to two weeks. When I return, I will only be working on Open MPI roughly 50% of my time for the remainder of this fiscal year (through end Sept). During that time, I hope to complete the revamp of the ORTE code that has been widely discussed. I will obviously keep you updated on that milestone, but you should expect a slower response to communications during that time as other duties claim their share of my attention. Ralph
