August 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] New Fortran errata Ticket #390
by Rolf Rabenseifner 23 Aug '13

23 Aug '13

Dear Bill, thank you for your detailed review. I put all on the ticket. By the way, I changed now the mpi3-fortran(a)lists.mpi-forum.org into mpiwg-fortran(a)lists.mpi-forum.org on the CC line (therefore the mail-rejection that you saw). Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu>, "Jeff Squyres" <jsquyres(a)cisco.com>, "MPI-3 Fortran working group" > <mpi3-fortran(a)lists.mpi-forum.org>, "Jeff Hammond" <jeff.science(a)gmail.com> > Sent: Friday, August 23, 2013 6:15:31 PM > Subject: Re: New Fortran errata Ticket #390 > Hi Rolf, > > I read through ticket and have these corrections: > > 1) In the first line of the Description, "lines 21-23" should be > "lines > 29-31". > > 2) In the last edit title, "lines 17-24" should be "lines 16-24". (for > citation on page 411). > > 3) The existing text for the interfaces has a common problem - there > is > a use of the constant MPI_ADDRESS_KIND but this is not defined in the > interface. Since these are all contained in either a module or header > file where MPI_ADDRESS_KIND is defined, we only need a statement > > IMPORT :: MPI_ADDRESS_KIND > > 8 times (twice for each replacement interface block, one for each > subroutine). Within each interface block: > > - In the first subroutine, the IMPORT statement should be inserted > between the SUBROUTINE statement and the first INTEGER statement. > > - In the second subroutine, the IMPORT statement should be inserted > immediately after the USE statement. > > You might want to include a paragraph at the beginning noting that > this > Errata also fixes the existing error in the text regarding the missing > IMPORT statements. > > I am planning to wait for these changes before adding comments > directly > to the ticket. > > Cheers, > Bill > > > > > On 8/22/13 3:10 AM, Rolf Rabenseifner wrote: > > Dear Craig, Jeff S., and Bill L., > > > > I updated the ticket as discussed yesterday. > > Please, can you write your reviews as comments on the ticket. > > > > Best regard, > > Rolf > > > > ----- Original Message ----- > >> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >> To: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu>, "Jeff Squyres" > >> <jsquyres(a)cisco.com>, "Bill Long" <longb(a)cray.com>, > >> "Jeff Hammond" <jeff.science(a)gmail.com>, "Rolf Rabenseifner" > >> <rabenseifner(a)hlrs.de> > >> Cc: "MPI-3 Fortran working group" > >> <mpi3-fortran(a)lists.mpi-forum.org> > >> Sent: Tuesday, August 20, 2013 11:01:53 AM > >> Subject: New Fortran errata Ticket #390 > >> Dear Craig, Jeff S., Bill, and Jeff H., > >> (now with correct subject line: "Fortran") > >> > >> I issued > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 > >> after a hint from Bill Long that our syntax was not really correct > >> because always both specific interfaces should be put together > >> into one generic interface. > >> > >> As member of the binding chapter committee, please can you check > >> the ticket and add a review to the ticket that we can > >> - announce it 2 weeks before the meeting in Madrid, and > >> - vote on it in Madrid. > >> > >> Thanks and best regards > >> Rolf > > > > -- > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] New Fortran errata Ticket #390
by Rolf Rabenseifner 22 Aug '13

22 Aug '13

Dear Craig, Jeff S., and Bill L., [now with new working group email address] I updated the ticket as discussed yesterday. Please, can you write your reviews as comments on the ticket. Best regard, Rolf ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Long" <longb(a)cray.com>, > "Jeff Hammond" <jeff.science(a)gmail.com>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, August 20, 2013 11:01:53 AM > Subject: New Fortran errata Ticket #390 > Dear Craig, Jeff S., Bill, and Jeff H., > (now with correct subject line: "Fortran") > > I issued > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 > after a hint from Bill Long that our syntax was not really correct > because always both specific interfaces should be put together > into one generic interface. > > As member of the binding chapter committee, please can you check > the ticket and add a review to the ticket that we can > - announce it 2 weeks before the meeting in Madrid, and > - vote on it in Madrid. > > Thanks and best regards > Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPI3 Fortran] New Fortran errata Ticket #390
by Jeff Hammond 20 Aug '13

20 Aug '13

Looks good to me but I'm hardly the Fortran 2008 master you guys are. Best, Jeff PS Rolf: If possible, please use "jhammond" on the Forum Trac site since that will find me at whatever address I'm using at the time, which happens to be jeff.science(a)gmail.com right now but may not always be. I fixed it on this ticket already. On Tue, Aug 20, 2013 at 4:01 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de>wrote: > Dear Craig, Jeff S., Bill, and Jeff H., > (now with correct subject line: "Fortran") > > I issued > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 > after a hint from Bill Long that our syntax was not really correct > because always both specific interfaces should be put together > into one generic interface. > > As member of the binding chapter committee, please can you check > the ticket and add a review to the ticket that we can > - announce it 2 weeks before the meeting in Madrid, and > - vote on it in Madrid. > > Thanks and best regards > Rolf > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > -- Jeff Hammond jeff.science(a)gmail.com

1 0

[MPI3 Fortran] New Fortran errata Ticket #390
by Rolf Rabenseifner 20 Aug '13

20 Aug '13

Dear Craig, Jeff S., Bill, and Jeff H., (now with correct subject line: "Fortran") I issued https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 after a hint from Bill Long that our syntax was not really correct because always both specific interfaces should be put together into one generic interface. As member of the binding chapter committee, please can you check the ticket and add a review to the ticket that we can - announce it 2 weeks before the meeting in Madrid, and - vote on it in Madrid. Thanks and best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

[MPI3 Fortran] New Frotran errata Ticket #390
by Rolf Rabenseifner 20 Aug '13

20 Aug '13

Dear Craig, Jeff S., Bill, and Jeff H., I issued https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 after a hint from Bill Long that our syntax was not really correct because always both specific interfaces should be put together into one generic interface. As member of the binding chapter committee, please can you check the ticket and add a review to the ticket that we can - announce it 2 weeks before the meeting in Madrid, and - vote on it in Madrid. Thanks and best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPI3 Fortran] [Mpi3-tools] Tools meeting Monday Oct 3
by Rolf Rabenseifner 03 Aug '13

03 Aug '13

Please ignore the out-dated email "Re: [Mpi3-tools] Tools meeting Monday Oct 3", see the reasons described by Jeff Squyres on August 2, 2013 7:39:01 PM: > Indiana U, which is the email hosting provider for the MPI Forum > mailing lists, is experiencing some difficulties with their email > system today. > > For example, the mail below is from Oct 3, 2011. I think it's safe to > ignore it at this point. :-) ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "Craig E Rasmussen" <rasmussn(a)lanl.gov> > Cc: "Craig Rasmussen" <crasmussen(a)newmexicoconsortium.org>, "MPI3 Tools" <mpi3-tools(a)lists.mpi-forum.org>, "MPI-3 > Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Monday, October 3, 2011 5:53:29 PM > Subject: Re: [Mpi3-tools] Tools meeting Monday Oct 3 > And the same for each peer rotine of each routine group > > > > # Symbols for mpif.h and use mpi > > # define MPI_SEND_with_mpi_OLD > > # > > MPI_SEND > > mpi_send > > mpi_send_ > > mpi_send__ > > > > > > #define MPI_SEND_with_mpi_TR > > # > > MPI_Send_f # has choice buffer as array descriptor > > > > > > # Symbols for use mpi_f08 (not using the new interop TR) > > # define MPI_SEND_with_mpi_f08_OLD > > # > > MPI_SEND_f08 > > mpi_send_f08 > > mpi_send_f08_ > > mpi_send_f08__ > > > > > > # define MPI_SEND_with_mpi_f08_TR > > # > > MPI_Send_f08 # has choice buffer as array descriptor > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues
by Jeff Squyres (jsquyres) 02 Aug '13

02 Aug '13

Indiana U, which is the email hosting provider for the MPI Forum mailing lists, is experincing some difficulties with their email system today. For example, the mail below is from Oct 3, 2011. I think it's safe to ignore it at this point. :-) On Oct 3, 2011, at 6:18 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear all, > > according to pages:lines in > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > and the decision of the Santorini 2011 meeting, > we should add the following text to accommodate the tools implementors. > > P559:20-21 reads > equals .FALSE.. If > but should read > equals .FALSE., and > > After p559 the following text should be added: > > ---------------------------- > To simplify the development of profiling libraries, the MPI routines > are grouped together and it is required that > if the peer routine of a group is available within an MPI library > with one of its possible linker names then all of the routines > in this group must be also provided according to the same linker > name scheme, and if the peer routine is not available through > a linker name scheme then all other routines have also not to be > available through this scheme. > > Peer routines and their groups: > - MPI_ALLOC_MEM > MPI_ALLOC_MEM and MPI_WIN_ALLOCATE. > - MPI_FREE_MEM > Only this routine is in this group. > - MPI_GET_ADDRESS > MPI_GET_ADDRESS and MPI_ADDRESS. > - MPI_SEND > All routines with choice buffer arguments that > are not declared as ASYNCHRONOUS within the mpi_f08 module > and exist already in MPI-2.2. > - MPI_NEIGHBOR_ALLTOALL > All routines with choice buffer arguments that > are not declared as ASYNCHRONOUS within the mpi_f08 module > and are new in MPI-3.0. > - MPI_ISEND > All routines with choice buffer arguments that > are declared as ASYNCHRONOUS within the mpi_f08 module > and exist already in MPI-2.2. > - MPI_IBCAST > All routines with choice buffer arguments that > are declared as ASYNCHRONOUS within the mpi_f08 module > and are new in MPI-3.0. > - MPI_OP_CREATE > Only this routine is in this group. > - MPI_REGISTER_DATAREP > Only this routine is in this group. > - MPI_COMM_KEYVAL_CREATE > All other routines with callback function arguments. > - MPI_COMM_DUP_FN > All predefined callback routines. > - MPI_COMM_RANK > All other MPI routines that exist already in MPI-2.2. > - MPI_IBARRIER > All other MPI routines that are new in MPI-3.0. > > Advice to implementors. > If all the following conditions are fulfilled > (which is the case for most compilers) > - the handles in the mpi_f08 module occupy one Fortran > numerical storage unit (same as an INTEGER handle), and > - the internal argument passing used to pass an actual ierror > argument to a non optional ierror dummy argument is binary > compatible to passing an actual ierror argument to an ierror > dummy argument that is declared as OPTIONAL, and > - the internal argument passing for ASYNCHRONOUS and > non-ASYNCHRONOUS arguments is the same, and > - the internal routine call mechanism is the same for > the Fortran and the C compiler, and > - the compiler does not provide TR 29113, > then for most groups, the implementor may use the same > internal routine implementations for all Fortran support > methods with only different linker names. > For TR 29113 quality, new routines are needed only for > the routine groups of MPI_ISEND and MPI_IBCAST. > End of advice to implementors. > ---------------------------- > > Not directly relevant for the tools people, but giving the reason > for differentiating several Choice-buffer routine groups, > the following changes are also done: > > P552:14-18 read > - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to > .TRUE. and declare choice buffers using the Fortran 2008 TR 29113 > feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..), > if the underlying Fortran compiler supports it. With this, > non-contiguous sub-arrays can be used as buffers in nonblocking routines. > but should read > - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to > .TRUE. and declare choice buffers using the Fortran 2008 TR 29113 > feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..) > in all nonblocking, split collective and persistent communication > routines, > if the underlying Fortran compiler supports it. With this, > non-contiguous sub-arrays can be used as buffers in nonblocking routines. > > Rationale. In all blocking routines, i.e., if the choice-buffer > is not declared as ASYNCHRONOUS, the TR 29113 feature is not needed > for the support of non-contiguous buffers because the compiler > can pass the buffer by in-and-out-copy through a contiguous scratch > array. End of rationale. > > P555:7-10 read > - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to > .TRUE. if all choice buffer arguments > are declared with TYPE(*), DIMENSION(..), otherwise set it to > .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous > subarrays can be used as buers in nonblocking routines. > but should read > - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to > .TRUE. if all choice buffer arguments > in all nonblocking, split collective and persistent communication > routines > are declared with TYPE(*), DIMENSION(..), otherwise set it to > .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous > subarrays can be used as buers in nonblocking routines. > > I'll try to be at the tel-con today. > > Best regards > Rolf > > > ----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> >> Cc: "MPI3 Tools" <mpi3-tools(a)lists.mpi-forum.org>, "Martin Schulz" <schulz6(a)llnl.gov>, "Craig E Rasmussen" >> <rasmussn(a)lanl.gov>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Andreas >> Knï¿½pfer" <andreas.knuepfer(a)tu-dresden.de>, "Todd Gamblin" <tgamblin(a)llnl.gov>, "Tobias Hilbrich" >> <tobias.hilbrich(a)tu-dresden.de>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >> Sent: Sunday, October 2, 2011 6:13:46 AM >> Subject: Re: [Mpi3-tools] Questions on the F2008 profiling interface issues >> Hi Marc-Andre, >> >> On Sep 30, 2011, at 6:27 AM, Marc-Andre Hermanns wrote: >> >>> Martin, >>> >>>> I was in Dresden the last few days (visiting the Vampir group, in >>>> particular Andreas Knuepfer and Tobias Hilbrich who are responsible >>>> for >>>> their MPI wrappers) and we sat down to talk about the issues around >>>> the >>>> profiling interface in ticket #229. >>>> >>>> Here is a quick summary with a few questions that came up: >>>> >>>> * With the new Fortran symbol naming variants, there are 6 or 8 or >>>> 10 >>>> versions for every MPI subroutine. Tools could intercept all >>>> versions by >>>> providing own symbols for all versions. >>> >>> If it is clear which name the symbols have, additional symbol names >>> should be easy to generate, so at this stage I think it doesn't >>> matter >>> much, whether we have 6, 8, or 10 different schemes to cover. Right? >> >> I agree - as long as we can generate a full list of names, we can >> intercept them all. Adding wrappers shouldn't be a problem. >> >>> >>>> Now the problem: Within the wrapper function a tool needs to call >>>> the >>>> correct PMPI call which usually is the same prefix (either '_f08', >>>> '_f', '__' etc.) as the MPI call it is in. A mapping to matching C >>>> functions (as most tools do it now) is not possible due to problems >>>> with calling conventions for callback routines. >>> >>> As far as I know our wrappers call the C routines, because we jump >>> through all sorts of hoops to get a proper Fortran to C conversion >>> and >>> back. So in this regard, we need to fix this. Interestingly this has >>> not >>> popped up yet. >> >> I agree - this is remarkable. >> >>> >>> If we write Fortran wrappers in Fortran, how would a Fortran wrapper >>> compiled with Fortran 77 have to call the C measurement code inside >>> the >>> wrapper? If the Fortran compiler implicitly adds underscores to the >>> calls, do I have to provide a special Fortran interface to my >>> measurement system then? >> >> That is a question for the Fortran experts. >> >>> >>>> * Would the following solution work? All wrappers for Fortran are >>>> written >>>> in Fortran instead of C. >>>> [...] >>>> For every MPI function, there are 6 or 8 variants and all of them >>>> need to be provided by a tool. This would probably mean that we >>>> have >>>> to compile wrappers with all three calling conventions (mpif.h, use >>>> mpi_f and use mpi_f08) and then link them together? >>> >>> Don't we need to compile with all three calling conventions on all >>> possible compilers on a given system? >> >> Also, here, I think the Fortran experts need to weigh in. >> >>> >>> We currently provide all 4 name-mangling schemes with every install >>> of >>> Scalasca, because we had some issues with applications using two >>> different Fortran compilers for different sub-modules. (This came up >>> in >>> a project some years back, and ever since then we provide all >>> schemes in >>> the same library and it seems to work.) >>> >>>> * As discussed at the forum, if we want to keep our tools in C >>>> (which is >>>> probably still the easier and better option), we need to know the >>>> symbols >>>> on the "p" side and we need a portable way to figure this out. We >>>> talked >>>> about the solution of two groups of routines - one for which we >>>> have _f08 >>>> symbols for one for which we don't. Rolf, how will you add this to >>>> the >>>> standard, in particular how will you form those groups. >>> >>> I started to get some doubts about this approach. One of the issues >>> was >>> that some choice-buffer routines had names longer than the proposed >>> limit. So they need to be mangled differently, especially, their >>> symbol >>> needs to be shortened. And as I understood it, the current idea is >>> to >>> leave it to the MPI implementation to define the shortened name. >> >> I thought that was just for the argument checking in mpif.h and that >> we decided to not support this. Are there more locations were the >> names are too long? >> >>> >>> It is one thing, finding out which suffix is used. Finding how >>> function >>> names are mangled without any form of restricting to possible >>> schemes >>> seems to be another ball game? >>> >>> Am I missing something? >> >> Yes, if we do have to shorten names, I agree - I think, though, we got >> around the issue, or did we not? >> >>> >>> I think, as it was pointed out in Santorini with the Fortran >>> Bindings in >>> general, we (or at least I) don't have enough Fortran expertise to >>> think >>> this through all to the end and consider all implications. I think >>> it >>> would be a great benefit to have people of the Fortran WG to join on >>> the >>> call on Monday. I hope this is possible. >> >> Yes, that would be great - all are cc-ed. >> >> Martin >> >> >>> >>> Cheers, >>> Marc-Andre >>> -- >>> Marc-Andre Hermanns >>> German Research School for >>> Simulation Sciences GmbH >>> c/o Laboratory for Parallel Programming >>> 52056 Aachen | Germany >>> >>> Tel +49 241 80 99753 >>> Fax +49 241 80 6 99753 >>> Web www.grs-sim.de >>> >>> Members: Forschungszentrum Jï¿½lich GmbH | RWTH Aachen University >>> Registered in the commercial register of the local court of >>> Dï¿½ren (Amtsgericht Dï¿½ren) under registration number HRB 5268 >>> Registered office: Jï¿½lich >>> Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes >>> >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues
by Jeff Squyres (jsquyres) 02 Aug '13

02 Aug '13

Note that IU -- the mailing list hosting provider for the MPI Forum lists -- is experiencing some difficulties with their mailing lists. For example, the mail below appears to be from nearly 2 years ago. I think it's safe to ignore at this point. :-) On Oct 3, 2011, at 10:49 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > Craig already agreed to be here today (in about 10 mins). > > > > On Oct 2, 2011, at 5:21 PM, Martin Schulz wrote: > >> Hi Rolf, >> >> Sorry, this must have gone lost in the long email trail. All the meeting information is on the tools Wiki at: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools >> >> I know the holiday is a problem, but I couldn't see an option on how to avoid this since moving it to next week would have been too late to provide feedback in time. It would be great if you could make it anyway. Otherwise, any feedback by email would be great as well, in particular on the grouping of _f08 functions we talked about during the last forum. >> >> Thanks, >> >> Martin >> >> >> On Oct 2, 2011, at 2:15 PM, Rolf Rabenseifner wrote: >> >>> >>>>> I think it >>>>> would be a great benefit to have people of the Fortran WG to join on >>>>> the call on Monday. I hope this is possible. >>>> >>>> Yes, that would be great - all are cc-ed. >>> >>> What must I do? >>> Can you provide date, time, number? >>> Oct. 3 is a holiday in Germany, therefore, I'm nut sure >>> that I can join. >>> >>> Rolf >>> >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0