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 <r...@open-mpi.org> 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 <bosi...@eecs.utk.edu>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: kel...@ornl.gov >>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > >
