On Dec 25, 2005, at 5:31 AM, Fred wrote:
> Now we have been looking at the code, it looks like it's based on
> LAM MPI's debug layer and we are still trying to figure out how
> it's running. We haven't spent a lot of time on reading the source
> though, got a lot to do but we're going to be more busy in January.
> Our goal was to split the graphical part and the "core" part, each
> part communicating though XML streams. That means, we should be
> able to redirect the libxmpi outputs to XML objects, this should
> bring more flexibility in the GUI part. But before we do that, we
> have to figure out how the core engine works (how it runs the
> program, how it monitors it, how they interact, ...). We are
> looking at the code, but a quick technical explanation from you
> core developers would be real handful so we can have a rough
> meaning of how to start with ;)
The current design of XMPI is divided into two components - the first
is libxmpi, which contains all the code for talking to the MPI
implementation in order to start MPI jobs and download traces (and
convert them into a standard format) and the xmpi source code, which
has all the gui and interaction logic in it. At one time, SGI's MPI
implementation supported XMPI (long ago in a galaxy far away), so the
portability code was factored out.
There isn't a well documented separation of code for all the non-
portability code. When XMPI was written, MOTIF was the only logical
choice for a GUI, and the logical way to program it was to integrate
it into all the other logic in your code.
> PS : Do you mean LAM MPI is dead and Open MPI is its successor ?
Open MPI is definitely the successor to LAM/MPI. I wouldn't say that
LAM/MPI is dead -- it's still supported and will be for the
foreseeable future. But no new features will be developed for LAM by
the LAM team.
Brian
> 2005/12/24, Brian Barrett <brbarret_at_[hidden] >:On Nov 14, 2005,
> at 2:11 AM, Fred wrote:
>
> > I'm an IT ingeneering student at the ISIMA school in Clermont-
> > Ferrand (France), and we (myself and Thomas) will at least start
> > porting XMPI to QT as our yearly project for the LASMEA institute.
> > QT4 was chosen because of its portability and say, "sexyness" ;).
> > This portage should run primarly on a MacOSX computing grid, but of
> > course our work will be freely available as GNU GPL code.
> > We are now looking at your source code and we will start working on
> > it as soon as we have a good understanding of the way it works.
> > We just wanted to let you know before everything starts. Which
> > version of XMPI should we try to port ? I just downloaded 2.2.3b8,
> > does it contain the latest sources and fixes, and is this version a
> > good basis to work on ?
>
> I apologize for the long delay in replying - your message
> unfortunately got lost in a pile of e-mail.
>
> XMPI 2.2.3b8 is the latest version of the source - there are no
> changes in our (private) CVS that are not in b8, so that would be the
> best starting point. XMPI is available under a license similar to
> the BSD license, so you are free to do with it what you like, as long
> as you include our original copyright notice somewhere in the
> distribution. This, of course, is not legal advice, but at least
> covers the spirit we were going for.
>
> As you might know, LAM/MPI has entered a bug-fix only maintenance
> mode as the developers focus more and more on Open MPI. At present,
> there are no plans to make XMPI and Open MPI interoperate. There are
> two things that would need to happen in order to have XMPI and Open
> MPI work together:
>
> - XMPI would need to be extended to talk to Open MPI's run-time
> system (so that
> process launching and the like work properly)
> - Open MPI would need to be extended to emit traces in XMPI's
> format
>
> If there is significant interest, both are probably possible to do
> with minimal effort.
>
> If you are successful with your project, we would be more than happy
> to add a link from the XMPI and LAM/MPI pages to your project. Good
> luck, and let us know if you have any specific questions -- our
> response time is usually much faster than this -- usually under 24
> hours.
>
> Brian
>
>
>
>
> --
> Brian Barrett
> LAM/MPI developer and all around nice guy
> Have a LAM/MPI day: http://www.lam-mpi.org/
>
>
> _______________________________________________
> This list is archived at
> http://www.lam-mpi.org/MailArchives/xmpi/
>
> _______________________________________________
> This list is archived at
> http://www.lam-mpi.org/MailArchives/xmpi/
|
