March 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] Questions about MPI_Comm_spawn
by Bill Long 25 Mar '14

25 Mar '14

On Mar 25, 2014, at 10:13 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > How to get the length? Use len(argv(i)) and select an arbitrary i ? len(argv) will do. If the argument of LEN is an array, the result is the length of one element of the array. Cheers, Bill > > --Junchao Zhang > > > On Tue, Mar 25, 2014 at 9:59 AM, Bill Long <longb(a)cray.com> wrote: > > On Mar 25, 2014, at 9:51 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > > Hello, Fortran experts, > > > > p.377 of MPI3 defines prototype of MPI_Comm_spawn. > > > > MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, intercomm, array_of_errcodes, ierror) > > CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) > > ... > > > > I can understand that command is a variable-length character. I fetch its length by len(command). The Fortran compiler needs to pass in data of command, as well as length of command. > > But I can't understand argv(*). I interpret it as an assumed-size array of variable-length characters. Does that imply each argv(i) could have different lengths, e.g., len(argv(1)) may be different from len(argv(2))? > > I think it is unreasonable, since if that, the compiler has to pass in length of every element of argv(*). > > > It is unreasonable. All elements of a character array have the same length. > > Cheers, > Bill > > > > > > Thank you > > --Junchao Zhang > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long longb(a)cray.com > Fortran Technical Suport & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Questions about MPI_Comm_spawn
by Junchao Zhang 25 Mar '14

25 Mar '14

How to get the length? Use len(argv(i)) and select an arbitrary i ? --Junchao Zhang On Tue, Mar 25, 2014 at 9:59 AM, Bill Long <longb(a)cray.com> wrote: > > On Mar 25, 2014, at 9:51 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > > Hello, Fortran experts, > > > > p.377 of MPI3 defines prototype of MPI_Comm_spawn. > > > > MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, intercomm, > array_of_errcodes, ierror) > > CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) > > ... > > > > I can understand that command is a variable-length character. I fetch > its length by len(command). The Fortran compiler needs to pass in data of > command, as well as length of command. > > But I can't understand argv(*). I interpret it as an assumed-size array > of variable-length characters. Does that imply each argv(i) could have > different lengths, e.g., len(argv(1)) may be different from len(argv(2))? > > I think it is unreasonable, since if that, the compiler has to pass in > length of every element of argv(*). > > > It is unreasonable. All elements of a character array have the same > length. > > Cheers, > Bill > > > > > > Thank you > > --Junchao Zhang > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long > longb(a)cray.com > Fortran Technical Suport & voice: > 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >

1 0

Re: [MPIWG Fortran] Questions about MPI_Comm_spawn
by Rolf Rabenseifner 25 Mar '14

25 Mar '14

Dear Junchao, The values of len(command) and len(argv(1)) may be different. All len(argv(i)) are identical. All details are described in MPI-3.0 p378:20 - p379:20. There is nothing new since MPI-2.0. Rolf ----- Original Message ----- > From: "Junchao Zhang" <jczhang(a)mcs.anl.gov> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, March 25, 2014 3:51:37 PM > Subject: [MPIWG Fortran] Questions about MPI_Comm_spawn > > > > > Hello, Fortran experts, > > p.377 of MPI3 defines prototype of MPI_Comm_spawn. > > > MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, > intercomm, array_of_errcodes, ierror) > CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) > ... > > > I can understand that command is a variable-length character. I fetch > its length by len(command). The Fortran compiler needs to pass in > data of command, as well as length of command. > But I can't understand argv(*). I interpret it as an assumed-size > array of variable-length characters. Does that imply each argv(i) > could have different lengths, e.g., len(argv(1)) may be different > from len(argv(2))? > I think it is unreasonable, since if that, the compiler has to pass > in length of every element of argv(*). > > > Thank you > > --Junchao Zhang > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- 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] Questions about MPI_Comm_spawn
by Bill Long 25 Mar '14

25 Mar '14

On Mar 25, 2014, at 9:51 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hello, Fortran experts, > > p.377 of MPI3 defines prototype of MPI_Comm_spawn. > > MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, intercomm, array_of_errcodes, ierror) > CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) > ... > > I can understand that command is a variable-length character. I fetch its length by len(command). The Fortran compiler needs to pass in data of command, as well as length of command. > But I can't understand argv(*). I interpret it as an assumed-size array of variable-length characters. Does that imply each argv(i) could have different lengths, e.g., len(argv(1)) may be different from len(argv(2))? > I think it is unreasonable, since if that, the compiler has to pass in length of every element of argv(*). It is unreasonable. All elements of a character array have the same length. Cheers, Bill > > Thank you > --Junchao Zhang > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Questions about MPI_Comm_spawn
by Junchao Zhang 25 Mar '14

25 Mar '14

Hello, Fortran experts, p.377 of MPI3 defines prototype of MPI_Comm_spawn. MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, intercomm, array_of_errcodes, ierror) CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) ... I can understand that command is a variable-length character. I fetch its length by len(command). The Fortran compiler needs to pass in data of command, as well as length of command. But I can't understand argv(*). I interpret it as an assumed-size array of variable-length characters. Does that imply each argv(i) could have different lengths, e.g., len(argv(1)) may be different from len(argv(2))? I think it is unreasonable, since if that, the compiler has to pass in length of every element of argv(*). Thank you --Junchao Zhang

1 0

Re: [MPIWG Fortran] Fortran hints on pages 52, 78, 103, 465, 507
by William Gropp 21 Mar '14

21 Mar '14

I'm sorry for not informing everyone; I was hurrying to get the draft ready. However, it is incorrect to use different titles for the sections that the actual ones; it was in comparing them to the actual titles that I realized that they were incorrect when I could not find them by name. It was also wrong to embed them as text (and in multiple places!), making it nearly impossible to keep them consistent. In my rush, I may have over simplified. Please remember that the standard is not a user manual nor is it a tutorial. It is a standard. The advice to users is intended to illuminate the standard, not provide guidance about how not to write code. I'm very uncomfortable with the same text appearing in multiple places in the standard - once should be enough. Finally, I find the old text useless - its so awkward to read that I just skip over it. I frankly believe that the shortened version is *more* likely to be read and considered. But this is my preference, and if the Fortran wg would like to propose text that is not incorrect, I'm happy to restore it. Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Mar 21, 2014, at 12:37 PM, Rolf Rabenseifner wrote: > The titles are cited in a shortened and summarizing form. > There seems to be nothing outdated or wrong. > The cited sections are the most relevant for further reading. > And it would be good if the process would include > that the relevant authors are informed when errors > are detected, in this case the Fortran WG together > with the chapter committee. > > The hints are based on reported experience that users of Fortran > often fail to handle these issues in a correct way. > > Rolf > > ----- Original Message ----- >> From: "William Gropp" <wgropp(a)illinois.edu> >> To: "Jim Dinan" <james.dinan(a)gmail.com> >> Cc: "Jeff Hammond" <jeff.science(a)gmail.com>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "David Solt" >> <dsolt(a)us.ibm.com>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Martin Schulz" >> <schulzm(a)llnl.gov>, "George Bosilca" <bosilca(a)icl.utk.edu>, chap-terms(a)lists.mpi-forum.org >> Sent: Friday, March 21, 2014 5:42:54 PM >> Subject: Re: MPI-Terms - 06 - Addresses and displacements >> >> Here's the reason. The text was incorrect, in large part because it >> included out of date (read *wrong*) and totally unnecessary section >> titles. The source files have the explanation; from the first >> occurrence of the incorrect text in the point-to-point chapter: >> >> >> >> %% Note that a previous version of this included what it hoped were the >> %% titles of the sections. That hope was misplaced, as the section >> %% titles had been changed. Another example of the folly in trying to >> %% keep multiple references manually synchronized. The titles are really >> %% not necessary here, as the first sentance covers the general issues. >> %% Attempting to enumerate them all is also a mistake, as it leaves out >> %% some that are also important. >> >> If there is a better update, let me know. There was no intent to >> change the meaning of the text, only correct errors. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute Thomas M. Siebel Chair in >> Computer Science >> >> University of Illinois Urbana-Champaign >> >> >> On Mar 21, 2014, at 10:34 AM, Jim Dinan wrote: >> >> According to SVN, this passage was commented out by gropp in r1711, >> which has the following log entry: >> >> >> >> ------------------------------------------------------------------------ >> r1711 | gropp | 2013-10-28 13:17:38 -0400 (Mon, 28 Oct 2013) | 1 line >> Changed paths: >> M /approved/MPI-3.1/MAKE-APPLANG >> M /approved/MPI-3.1/chap-binding/binding-2.tex >> M /approved/MPI-3.1/chap-coll/coll.tex >> M /approved/MPI-3.1/chap-context/context.tex >> M /approved/MPI-3.1/chap-datatypes/datatypes.tex >> M /approved/MPI-3.1/chap-dynamic/dynamic-2.tex >> M /approved/MPI-3.1/chap-frontm/abstract-cpy.tex >> M /approved/MPI-3.1/chap-frontm/history.tex >> M /approved/MPI-3.1/chap-intro/intro.tex >> M /approved/MPI-3.1/chap-io/io-2.tex >> M /approved/MPI-3.1/chap-one-side/one-side-2.tex >> M /approved/MPI-3.1/chap-pt2pt/pt2pt.tex >> M /approved/MPI-3.1/chap-topol/topol.tex >> M /approved/MPI-3.1/getlatex >> >> >> More updates >> ------------------------------------------------------------------------ >> >> >> Looking over the history, this appears to be part of a series of >> LaTeX-related updates, and may have been unintentional. >> >> >> ~Jim. >> >> >> >> On Fri, Mar 21, 2014 at 9:15 AM, Jeff Hammond < >> jeff.science(a)gmail.com > wrote: >> >> >> You can run SVN log/blame to see who removed the text. I have no idea >> about this so I cannot discuss the process by which it came to pass. >> >> Jeff >> >> Sent from my iPhone >> >> >> >>> On Mar 21, 2014, at 5:48 AM, Rolf Rabenseifner < >>> rabenseifner(a)hlrs.de > wrote: >>> >>> Hi Jim and all, >>> >>> a really negative surprise was that Fortran related text >>> was removed from the approved svn without >>> discussing this together with the Fortran working group. >>> >>> This is the fastest way to get additional inconsistencies >>> into the MPI standard. >>> >>> George and Jeff H. as Chap.4 committee, >>> please can you check the process and tell me what went wrong. >>> This will be also an input for the discussion how to keep >>> or get the document consistent. >>> The probably lost text portion is MPI-3.0 p103:42-46. >>> > ... > > -- > 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

Fortran hints on pages 52, 78, 103, 465, 507
by Rolf Rabenseifner 21 Mar '14

21 Mar '14

The titles are cited in a shortened and summarizing form. There seems to be nothing outdated or wrong. The cited sections are the most relevant for further reading. And it would be good if the process would include that the relevant authors are informed when errors are detected, in this case the Fortran WG together with the chapter committee. The hints are based on reported experience that users of Fortran often fail to handle these issues in a correct way. Rolf ----- Original Message ----- > From: "William Gropp" <wgropp(a)illinois.edu> > To: "Jim Dinan" <james.dinan(a)gmail.com> > Cc: "Jeff Hammond" <jeff.science(a)gmail.com>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "David Solt" > <dsolt(a)us.ibm.com>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Martin Schulz" > <schulzm(a)llnl.gov>, "George Bosilca" <bosilca(a)icl.utk.edu>, chap-terms(a)lists.mpi-forum.org > Sent: Friday, March 21, 2014 5:42:54 PM > Subject: Re: MPI-Terms - 06 - Addresses and displacements > > Here's the reason. The text was incorrect, in large part because it > included out of date (read *wrong*) and totally unnecessary section > titles. The source files have the explanation; from the first > occurrence of the incorrect text in the point-to-point chapter: > > > > %% Note that a previous version of this included what it hoped were the > %% titles of the sections. That hope was misplaced, as the section > %% titles had been changed. Another example of the folly in trying to > %% keep multiple references manually synchronized. The titles are really > %% not necessary here, as the first sentance covers the general issues. > %% Attempting to enumerate them all is also a mistake, as it leaves out > %% some that are also important. > > If there is a better update, let me know. There was no intent to > change the meaning of the text, only correct errors. > > Bill > > William Gropp > Director, Parallel Computing Institute Thomas M. Siebel Chair in > Computer Science > > University of Illinois Urbana-Champaign > > > On Mar 21, 2014, at 10:34 AM, Jim Dinan wrote: > > According to SVN, this passage was commented out by gropp in r1711, > which has the following log entry: > > > > ------------------------------------------------------------------------ > r1711 | gropp | 2013-10-28 13:17:38 -0400 (Mon, 28 Oct 2013) | 1 line > Changed paths: > M /approved/MPI-3.1/MAKE-APPLANG > M /approved/MPI-3.1/chap-binding/binding-2.tex > M /approved/MPI-3.1/chap-coll/coll.tex > M /approved/MPI-3.1/chap-context/context.tex > M /approved/MPI-3.1/chap-datatypes/datatypes.tex > M /approved/MPI-3.1/chap-dynamic/dynamic-2.tex > M /approved/MPI-3.1/chap-frontm/abstract-cpy.tex > M /approved/MPI-3.1/chap-frontm/history.tex > M /approved/MPI-3.1/chap-intro/intro.tex > M /approved/MPI-3.1/chap-io/io-2.tex > M /approved/MPI-3.1/chap-one-side/one-side-2.tex > M /approved/MPI-3.1/chap-pt2pt/pt2pt.tex > M /approved/MPI-3.1/chap-topol/topol.tex > M /approved/MPI-3.1/getlatex > > > More updates > ------------------------------------------------------------------------ > > > Looking over the history, this appears to be part of a series of > LaTeX-related updates, and may have been unintentional. > > > ~Jim. > > > > On Fri, Mar 21, 2014 at 9:15 AM, Jeff Hammond < > jeff.science(a)gmail.com > wrote: > > > You can run SVN log/blame to see who removed the text. I have no idea > about this so I cannot discuss the process by which it came to pass. > > Jeff > > Sent from my iPhone > > > > > On Mar 21, 2014, at 5:48 AM, Rolf Rabenseifner < > > rabenseifner(a)hlrs.de > wrote: > > > > Hi Jim and all, > > > > a really negative surprise was that Fortran related text > > was removed from the approved svn without > > discussing this together with the Fortran working group. > > > > This is the fastest way to get additional inconsistencies > > into the MPI standard. > > > > George and Jeff H. as Chap.4 committee, > > please can you check the process and tell me what went wrong. > > This will be also an input for the discussion how to keep > > or get the document consistent. > > The probably lost text portion is MPI-3.0 p103:42-46. > > ... -- 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] Type of MPI_Status
by Bill Long 18 Mar '14

18 Mar '14

On Mar 18, 2014, at 9:10 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Jeff, > > based on Bill's explanations > I understand that all is the same: > > KIND(0) = KIND(1) = KIND(237834) > = KIND(any default INTEGER number) Right. > > = KIND(any default INTEGER variable) = KIND(ICVDhjk) > = KIND(INTEger) > > provided that there is no "IMPLICIT NONE"and therefore, > the with I beginning variables ICVDhjk and INTEger > are automatically of type default INTEGER Or if you explicitly declare the argument to be a default integer, which is safer in case you accidentally choose a variable also used by the surrounding code. > > Remark: You should never use KIND(INTEGER) because it may Reasonable rule of thumb for various reasons. But this also excludes KIND(INTEger) since variable names in Fortran are case-insensitive. Cheers, Bill > cause a name conflict if the MPI applications declares an > own variable with name INTEGER. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Tuesday, March 18, 2014 2:23:24 PM >> Subject: Re: [MPIWG Fortran] Type of MPI_Status >> >> On Mar 17, 2014, at 6:09 PM, Bill Long <longb(a)cray.com> wrote: >> >>>> Crap, again? I keep forgetting which language I'm programming in. >>>> I checked this with gfortran and it worked (as it should, but >>>> not in the way I thought it would). That is why I originally >>>> suggested to Jeff it be >>>> >>>> KIND(1) >>>> >>>> (because the literal 1 is an integer), but he asked what the heck >>>> does that mean so I came up with an example that I thought was >>>> more clear (but was actually worse). >>> >>> More important, 1 is of type *default* integer, which is the >>> requirement here. >> >> >> So -- I'm now confused. Should I use KIND(0) or KIND(1)? Both have >> been cited in this email thread. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > 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) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Type of MPI_Status
by Rolf Rabenseifner 18 Mar '14

18 Mar '14

Jeff, based on Bill's explanations I understand that all is the same: KIND(0) = KIND(1) = KIND(237834) = KIND(any default INTEGER number) = KIND(any default INTEGER variable) = KIND(ICVDhjk) = KIND(INTEger) provided that there is no "IMPLICIT NONE"and therefore, the with I beginning variables ICVDhjk and INTEger are automatically of type default INTEGER Remark: You should never use KIND(INTEGER) because it may cause a name conflict if the MPI applications declares an own variable with name INTEGER. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, March 18, 2014 2:23:24 PM > Subject: Re: [MPIWG Fortran] Type of MPI_Status > > On Mar 17, 2014, at 6:09 PM, Bill Long <longb(a)cray.com> wrote: > > >> Crap, again? I keep forgetting which language I'm programming in. > >> I checked this with gfortran and it worked (as it should, but > >> not in the way I thought it would). That is why I originally > >> suggested to Jeff it be > >> > >> KIND(1) > >> > >> (because the literal 1 is an integer), but he asked what the heck > >> does that mean so I came up with an example that I thought was > >> more clear (but was actually worse). > > > > More important, 1 is of type *default* integer, which is the > > requirement here. > > > So -- I'm now confused. Should I use KIND(0) or KIND(1)? Both have > been cited in this email thread. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- 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] Type of MPI_Status
by Jeff Squyres (jsquyres) 18 Mar '14

18 Mar '14

On Mar 17, 2014, at 6:09 PM, Bill Long <longb(a)cray.com> wrote: >> Crap, again? I keep forgetting which language I'm programming in. I checked this with gfortran and it worked (as it should, but not in the way I thought it would). That is why I originally suggested to Jeff it be >> >> KIND(1) >> >> (because the literal 1 is an integer), but he asked what the heck does that mean so I came up with an example that I thought was more clear (but was actually worse). > > More important, 1 is of type *default* integer, which is the requirement here. So -- I'm now confused. Should I use KIND(0) or KIND(1)? Both have been cited in this email thread. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0