Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] opal / fortran / Flogical
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-06-02 07:48:02


It looks like Rainer reverted the stuff in r21342.

Rainer -- is it safe for Ralph to move the arch.c stuff back up into
OMPI, or will that conflict with your stuff?

On Jun 1, 2009, at 11:12 PM, Ralph Castain wrote:

> Just to throw some $0.002 into this overall discussion...
>
> Not knowing this was going to be happening, I was actually about to
> propose moving the opal/util/arch.c code back to the ompi layer. The
> original move had caused quite a bit of angst due to the fortran
> stuff. Originally, I had needed to make the move because the design
> for modex-less operations needed to know the architecture prior to
> launching the app. However, as things evolved, it turns out that this
> isn't necessary at all - in fact, the launch system doesn't actually
> take advantage of the ORTE layer knowing the arch.
>
> So from the point of view of the current system, there is no value in
> having the opal/util/arch.c code - it can be restored to the original
> datatype area.
>
> I realize that Rainer is pursuing a different objective, and that's
> fine. My point here is that the original motivation for breaking the
> abstraction barrier no longer exists, so whatever we do here is free
> to reflect that change in requirement.
>
> I would personally like to see OPAL retain its original objective and
> avoid having Fortran knowledge down there.
> Ralph
>
> On Jun 1, 2009, at 3:02 PM, Rainer Keller wrote:
>
> > Thanks, Jeff!
> >
> >
> > On Monday 01 June 2009 04:53:19 pm Jeff Squyres wrote:
> >> Per the MPI_Flogical issue -- I think Rainer just exposed some old
> >> ugliness. We've apparently had MPI_Flogical defined in
> >> ompi_config.h.in for a long, long time -- we used it in some places
> >> and used ompi_fortran_logical_t in other places.
> >>
> >> Even though I *may* be responsible for this particular bit of
> >> ugliness
> >> way back in the past :-), I think the #define for MPI_Flogical
> should
> >> be removed if for no other reason than 6-12 months from now when
> >> someone else re-discovers it, they'll have to go lookup to see if
> >> it's
> >> a real MPI type -- which it's not. Even though it's longer, we
> >> should
> >> use ompi_fortran_logical_t everywhere.
> >>
> >> My $0.02.
> >>
> >> On Jun 1, 2009, at 1:23 PM, Brian W. Barrett wrote:
> >>> Well, this may just be another sign that the push of the DDT to
> OPAL
> >>> is a
> >>> bad idea. That's been my opinion from the start, so I'm biased.
> >>> But OPAL
> >>> was intended to be single process systems portability, not MPI
> crud.
> >>>
> >>> Brian
> >>>
> >>> On Mon, 1 Jun 2009, Rainer Keller wrote:
> >>>> Hmm, OK, I see.
> >>>> However, I do see potentially a problem with work getting ddt on
> >>>
> >>> the OPAL
> >>>
> >>>> layer when we do have a fortran compiler with different alignment
> >>>
> >>> requirements
> >>>
> >>>> for the same-sized basic types...
> >>>>
> >>>> As far as I understand the OPAL layer to abstract away from
> >>>
> >>> underlying system
> >>>
> >>>> portability, libc-quirks, and compiler information.
> >>>>
> >>>> But I am perfectly fine with reverting this!
> >>>> Let's discuss, maybe phone?
> >>>>
> >>>> Thanks,
> >>>> Rainer
> >>>>
> >>>> On Monday 01 June 2009 10:38:51 am Jeff Squyres wrote:
> >>>>> Hmm. I'm not sure that I like this commit.
> >>>>>
> >>>>> George, Brian, and I specifically kept Fortran out of (the non-
> >>>>> generated code in) opal because the MPI layer is the *only*
> layer
> >>>
> >>> that
> >>>
> >>>>> uses Fortran. There was one or two minor abstraction breaks
> (you
> >>>>> cited opal/util/arch.c), but now we have Fortran all throughout
> >>>
> >>> Opal.
> >>>
> >>>>> Hmmm... :-\
> >>>>>
> >>>>> Is MPI_Flogical a real type? I don't see it defined in the
> >>>>> MPI-2.2
> >>>>> latex sources, but I could be missing it. I *thought* we used
> >>>>> ompi_fortran_logical_t internally because there was no
> officially
> >>>>> sanctioned MPI_<foo> type for it...?
> >
> > --
> >
> ------------------------------------------------------------------------
> > Rainer Keller, PhD Tel: +1 (865) 241-6293
> > Oak Ridge National Lab Fax: +1 (865) 241-4811
> > PO Box 2008 MS 6164 Email: keller_at_[hidden]
> > Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

-- 
Jeff Squyres
Cisco Systems