Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] opal / fortran / Flogical
From: Ralph Castain (rhc_at_[hidden])
Date: 2009-06-02 15:31:03


Quick question, George - are you planning on leaving that arch computation
in OPAL, but just moving it to the new opal/datatype area? If so, then I
won't worry about removing the arch-related calls from ORTE right away.

If you are planning on moving it back to OMPI, then I'll put my efforts at a
higher priority.

Thanks
Ralph

On Tue, Jun 2, 2009 at 10:30 AM, Ralph Castain <rhc_at_[hidden]> wrote:

> Please feel free to do so, George, as far as I'm concerned. I will modify
> the ORTE code in anticipation of it by removing the arch-related calls.
> Should have that for you later today or tomorrow.
>
> If it doesn't move, no harm done - like I said, I really don't need it any
> more, but was suggesting the move only to finally clear that abstraction
> break we all hated when I originally did it (apologies in hindsight). :-)
>
>
>
> On Tue, Jun 2, 2009 at 9:45 AM, George Bosilca <bosilca_at_[hidden]>wrote:
>
>> The datatype engine (where the arch code was originally from), needs a way
>> to describe the architectures in order to know how to convert the data.
>> Therefore I will advocate the return of the opal/util/arch.h back in the
>> datatype.
>>
>> george.
>>
>>
>> On Jun 2, 2009, at 07:24 , Rainer Keller wrote:
>>
>> Hi Jeff,
>>> no, that's not an issue. The comment is correct: For any Fortran
>>> integer*kind
>>> we need to have _some_ C-representation as well, otherwise we disregard
>>> the
>>> type (tm), see e.g. the old and resolved ticket #1094.
>>> The representation chosen is set in opal/util/arch.c and is conclusive as
>>> far
>>> as I can tell...
>>>
>>> We do however still have a buglet with FCFLAGS='-i8 -r16', but that's
>>> with our
>>> internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket
>>> #1812).
>>>
>>> CU,
>>> Rainer
>>>
>>> PS: I especially like the comment in opal/util/arch.c ;-):
>>> /* sizeof fortran logical
>>> *
>>> * RHC: technically, use of the ompi_ prefix is
>>> * an abstraction violation. However, this is actually
>>> * an error in our configure scripts that transcends
>>> * all the data types and eventually should be fixed.
>>> * The guilty part is f77_check.m4. Fixing it right
>>> * now is beyond a reasonable scope - this comment is
>>> * placed here to explain the abstraction break and
>>> * indicate that it will eventually be fixed
>>> */
>>>
>>>
>>>
>>> On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote:
>>>
>>>> On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote:
>>>>
>>>>> Rainer -- is it safe for Ralph to move the arch.c stuff back up into
>>>>>> OMPI, or will that conflict with your stuff?
>>>>>>
>>>>>
>>>>> Yes, we use it.
>>>>> Please leave it at the OPAL layer. We need a way to describe and
>>>>> store the
>>>>> remote architecture at the OPAL layer.
>>>>>
>>>>
>>>> Question about the fortran stuff in opal/util/arch.c...
>>>>
>>>> I see the following comment:
>>>>
>>>> ** The fortran integer is dismissed here, since there is no
>>>> ** platform known to me, were fortran and C-integer do not match
>>>>
>>>> You can tell the intel compiler (and maybe others?) to compile fortran
>>>> with double-sized integers and reals. Are we disregarding this?
>>>> I.e., does this make this portion of the datatype heterogeneity
>>>> detection incorrect?
>>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>> 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
>>
>
>