March 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Increasing MPI ranks
by Jeffrey Larson 11 Mar '14

11 Mar '14

I just updated mpiexec last week because an early version of my script was pausing for a considerable length of time after spawning 8, 16, 24... processes. I sent that earlier code to someone else and they said they didn't observe that behavior and they had mpiexec version 3.1 installed. So to solve an earlier bug, I installed the latest mpiexec. I only mentioned the mpich2 version because I saw there was an "mpich2version" command. It gives the 1.4.1 output. On Tue, Mar 11, 2014 at 4:37 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > Thank you for your response. Attached are the script and the simple > function that it calls. > > The command: > $ mpiexec -n 3 python script.py > works great, but 30 crashes. > > I am using MPICH2 Version: 1.4.1. and mpiexec version 3.1. > > > > On Tue, Mar 11, 2014 at 4:31 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > >> Hi, Jeffrey, >> >> Can you send us a minimum example of your script.py? >> Simple python scripts seem to work fine for me on both Mac and Ubuntu >> machines. >> >> Also, what version of MPICH are you using? >> -- >> Huiwei Lu >> Postdoc Appointee >> Mathematics and Computer Science Division, Argonne National Laboratory >> http://www.mcs.anl.gov/~huiweilu/ >> >> On Mar 11, 2014, at 4:08 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: >> >> > Hello, >> > >> > I am using mpi4py to call MPI from python, and when I increase the >> number of ranks at the command line so something like: >> > >> > [jlarson@mintthinkpad test]$ mpiexec -n 30 python script.py >> > >> > I receive the following error messages: >> > >> > [mpiexec@mintthinkpad] handle_pmi_cmd (pm/pmiserv/pmiserv_cb.c:52): >> Unrecognized PMI command: | cleaning up processes >> > [mpiexec@mintthinkpad] control_cb (pm/pmiserv/pmiserv_cb.c:280): >> unable to process PMI command >> > [mpiexec@mintthinkpad] HYDT_dmxu_poll_wait_for_event >> (tools/demux/demux_poll.c:76): callback returned error status >> > [mpiexec@mintthinkpad] HYD_pmci_wait_for_completion >> (pm/pmiserv/pmiserv_pmci.c:198): error waiting for event >> > [mpiexec@mintthinkpad] main (ui/mpich/mpiexec.c:336): process manager >> error waiting for completion >> > >> > When I search online for help with these error messages, I am only >> pointed towards the repository containing the files that are themselves >> throwing the error. For example: Googling for "handle_pmi_cmd Unrecognized >> PMI command" only returns: >> > >> > >> https://svn.mcs.anl.gov/repos/mpi/mpich2/tags/release/mpich2-1.3a1/src/pm/h… >> > >> > >> > Note that my script is using very few resources; each rank is spawning >> a simple external function. The function takes a vector and then sums all >> the entries, squares them, and returns the number to each rank. The script >> works as expected when the number of initial ranks is small. >> > >> > Thank you for your help. >> > Jeffrey Larson >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > >

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Lu, Huiwei 11 Mar '14

11 Mar '14

A quick question before we digging into the script: why are you using different version of MPICH2 and mpiexec? — Huiwei On Mar 11, 2014, at 4:37 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > Thank you for your response. Attached are the script and the simple function that it calls. > > The command: > $ mpiexec -n 3 python script.py > works great, but 30 crashes. > > I am using MPICH2 Version: 1.4.1. and mpiexec version 3.1. > > > > On Tue, Mar 11, 2014 at 4:31 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > Hi, Jeffrey, > > Can you send us a minimum example of your script.py? > Simple python scripts seem to work fine for me on both Mac and Ubuntu machines. > > Also, what version of MPICH are you using? > — > Huiwei Lu > Postdoc Appointee > Mathematics and Computer Science Division, Argonne National Laboratory > http://www.mcs.anl.gov/~huiweilu/ > > On Mar 11, 2014, at 4:08 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > > > Hello, > > > > I am using mpi4py to call MPI from python, and when I increase the number of ranks at the command line so something like: > > > > [jlarson@mintthinkpad test]$ mpiexec -n 30 python script.py > > > > I receive the following error messages: > > > > [mpiexec@mintthinkpad] handle_pmi_cmd (pm/pmiserv/pmiserv_cb.c:52): Unrecognized PMI command: | cleaning up processes > > [mpiexec@mintthinkpad] control_cb (pm/pmiserv/pmiserv_cb.c:280): unable to process PMI command > > [mpiexec@mintthinkpad] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status > > [mpiexec@mintthinkpad] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:198): error waiting for event > > [mpiexec@mintthinkpad] main (ui/mpich/mpiexec.c:336): process manager error waiting for completion > > > > When I search online for help with these error messages, I am only pointed towards the repository containing the files that are themselves throwing the error. For example: Googling for "handle_pmi_cmd Unrecognized PMI command" only returns: > > > > https://svn.mcs.anl.gov/repos/mpi/mpich2/tags/release/mpich2-1.3a1/src/pm/h… > > > > > > Note that my script is using very few resources; each rank is spawning a simple external function. The function takes a vector and then sums all the entries, squares them, and returns the number to each rank. The script works as expected when the number of initial ranks is small. > > > > Thank you for your help. > > Jeffrey Larson > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > <function.py><script.py>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Jeffrey Larson 11 Mar '14

11 Mar '14

Thank you for your response. Attached are the script and the simple function that it calls. The command: $ mpiexec -n 3 python script.py works great, but 30 crashes. I am using MPICH2 Version: 1.4.1. and mpiexec version 3.1. On Tue, Mar 11, 2014 at 4:31 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > Hi, Jeffrey, > > Can you send us a minimum example of your script.py? > Simple python scripts seem to work fine for me on both Mac and Ubuntu > machines. > > Also, what version of MPICH are you using? > -- > Huiwei Lu > Postdoc Appointee > Mathematics and Computer Science Division, Argonne National Laboratory > http://www.mcs.anl.gov/~huiweilu/ > > On Mar 11, 2014, at 4:08 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > > > Hello, > > > > I am using mpi4py to call MPI from python, and when I increase the > number of ranks at the command line so something like: > > > > [jlarson@mintthinkpad test]$ mpiexec -n 30 python script.py > > > > I receive the following error messages: > > > > [mpiexec@mintthinkpad] handle_pmi_cmd (pm/pmiserv/pmiserv_cb.c:52): > Unrecognized PMI command: | cleaning up processes > > [mpiexec@mintthinkpad] control_cb (pm/pmiserv/pmiserv_cb.c:280): unable > to process PMI command > > [mpiexec@mintthinkpad] HYDT_dmxu_poll_wait_for_event > (tools/demux/demux_poll.c:76): callback returned error status > > [mpiexec@mintthinkpad] HYD_pmci_wait_for_completion > (pm/pmiserv/pmiserv_pmci.c:198): error waiting for event > > [mpiexec@mintthinkpad] main (ui/mpich/mpiexec.c:336): process manager > error waiting for completion > > > > When I search online for help with these error messages, I am only > pointed towards the repository containing the files that are themselves > throwing the error. For example: Googling for "handle_pmi_cmd Unrecognized > PMI command" only returns: > > > > > https://svn.mcs.anl.gov/repos/mpi/mpich2/tags/release/mpich2-1.3a1/src/pm/h… > > > > > > Note that my script is using very few resources; each rank is spawning a > simple external function. The function takes a vector and then sums all the > entries, squares them, and returns the number to each rank. The script > works as expected when the number of initial ranks is small. > > > > Thank you for your help. > > Jeffrey Larson > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Lu, Huiwei 11 Mar '14

11 Mar '14

Hi, Jeffrey, Can you send us a minimum example of your script.py? Simple python scripts seem to work fine for me on both Mac and Ubuntu machines. Also, what version of MPICH are you using? — Huiwei Lu Postdoc Appointee Mathematics and Computer Science Division, Argonne National Laboratory http://www.mcs.anl.gov/~huiweilu/ On Mar 11, 2014, at 4:08 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > Hello, > > I am using mpi4py to call MPI from python, and when I increase the number of ranks at the command line so something like: > > [jlarson@mintthinkpad test]$ mpiexec -n 30 python script.py > > I receive the following error messages: > > [mpiexec@mintthinkpad] handle_pmi_cmd (pm/pmiserv/pmiserv_cb.c:52): Unrecognized PMI command: | cleaning up processes > [mpiexec@mintthinkpad] control_cb (pm/pmiserv/pmiserv_cb.c:280): unable to process PMI command > [mpiexec@mintthinkpad] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status > [mpiexec@mintthinkpad] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:198): error waiting for event > [mpiexec@mintthinkpad] main (ui/mpich/mpiexec.c:336): process manager error waiting for completion > > When I search online for help with these error messages, I am only pointed towards the repository containing the files that are themselves throwing the error. For example: Googling for "handle_pmi_cmd Unrecognized PMI command" only returns: > > https://svn.mcs.anl.gov/repos/mpi/mpich2/tags/release/mpich2-1.3a1/src/pm/h… > > > Note that my script is using very few resources; each rank is spawning a simple external function. The function takes a vector and then sums all the entries, squares them, and returns the number to each rank. The script works as expected when the number of initial ranks is small. > > Thank you for your help. > Jeffrey Larson > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Increasing MPI ranks
by Jeffrey Larson 11 Mar '14

11 Mar '14

Hello, I am using mpi4py to call MPI from python, and when I increase the number of ranks at the command line so something like: [jlarson@mintthinkpad test]$ mpiexec -n 30 python script.py I receive the following error messages: [mpiexec@mintthinkpad] handle_pmi_cmd (pm/pmiserv/pmiserv_cb.c:52): Unrecognized PMI command: | cleaning up processes [mpiexec@mintthinkpad] control_cb (pm/pmiserv/pmiserv_cb.c:280): unable to process PMI command [mpiexec@mintthinkpad] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status [mpiexec@mintthinkpad] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:198): error waiting for event [mpiexec@mintthinkpad] main (ui/mpich/mpiexec.c:336): process manager error waiting for completion When I search online for help with these error messages, I am only pointed towards the repository containing the files that are themselves throwing the error. For example: Googling for "handle_pmi_cmd Unrecognized PMI command" only returns: https://svn.mcs.anl.gov/repos/mpi/mpich2/tags/release/mpich2-1.3a1/src/pm/h… Note that my script is using very few resources; each rank is spawning a simple external function. The function takes a vector and then sums all the entries, squares them, and returns the number to each rank. The script works as expected when the number of initial ranks is small. Thank you for your help. Jeffrey Larson

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Scot Breitenfeld 11 Mar '14

11 Mar '14

I ran the modified program using mpich 3.1 instead and it fixes the problem on 32 bit, so it seems to work everywhere using mpich 3.1 Thanks, Scot On Mar 11, 2014, at 2:51 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > I ran it on a Mac. 64 bit. > > Rajeev > > On Mar 11, 2014, at 2:49 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> > wrote: > >> I could also get it to work on >> >> Linux 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> >> which is probably what your laptop is running? >> >> Maybe it’s a 32-bit version issue? >> >> The comment about documentation was geared toward the people in charge of mpich.org, since they run the mailing list and I’m assuming they are in charge of the Documentation Manpages on mpich.org. I just gravitate to an html document rather then scanning a pdf :) >> >> Thanks, >> Scot >> >> >> On Mar 11, 2014, at 2:13 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> >>> The modified program works correctly on my laptop. >>> >>>> Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>>> >>>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >>> >>> That page provides the C binding and generic description of arguments identical to the one provided on pg 93 of the MPI 3.0 standard. In any case, the definitive source for function bindings should be the MPI 3.0 standard available at www.mpi-forum.org, not any other web site. >>> >>> Rajeev >>> >>> >>> >>> On Mar 11, 2014, at 1:39 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >>> >>>> I checked the original program and the suggested version on another machine using >>>> >>>> mpif90 for MPICH2 version 1.5 >>>> exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) >>>> exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) >>>> >>>> And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>>> >>>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >>>> >>>> I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. >>>> >>>> Scot >>>> >>>> Updated program: >>>> >>>> PROGRAM struct >>>> >>>> USE mpi >>>> USE iso_c_binding >>>> >>>> IMPLICIT NONE >>>> >>>> INTEGER, PARAMETER :: NELEM = 2 >>>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>>> INTEGER :: stat(MPI_STATUS_SIZE) >>>> INTEGER :: fh >>>> INTEGER :: status >>>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>>> >>>> INTEGER, DIMENSION(1:3) :: iiaux >>>> >>>> TYPE Particle >>>> SEQUENCE >>>> INTEGER, DIMENSION(1:3) :: indx >>>> END TYPE Particle >>>> >>>> TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles >>>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent >>>> INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets >>>> TYPE(C_PTR) :: fptr >>>> >>>> CALL MPI_INIT(ierr) >>>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>>> >>>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>>> offsets(1) = 0 >>>> oldtypes(1) = MPI_INTEGER >>>> blockcounts(1) = 3 >>>> >>>> ! Now define structured TYPE and commit it >>>> CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) >>>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>>> >>>> disp = 0 >>>> >>>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>>> >>>> particles(1)%indx = -1 >>>> >>>> fptr = C_LOC( particles(1)%indx(1)) >>>> >>>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>>> >>>> PRINT*,"Derived type" >>>> DO i=1,nelem >>>> PRINT*,particles(i)%indx >>>> ENDDO >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>>> MPI_INFO_NULL, fh, ierr) >>>> >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> >>>> PRINT*,"No derived type" >>>> >>>> PRINT*,iiaux >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> PRINT*,iiaux >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_FINALIZE(ierr) >>>> END PROGRAM struct >>>> >>>> >>>> >>>> >>>> >>>> On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> I created a file in fortran using (which I compiled with mpif90): >>>>> >>>>> PROGRAM writeUstream >>>>> >>>>> IMPLICIT NONE >>>>> INTEGER :: i, ii >>>>> INTEGER, DIMENSION(1:3,1:25) :: buf >>>>> >>>>> OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") >>>>> >>>>> ii = 1 >>>>> >>>>> DO i=1, 25 >>>>> buf(1,i) = ii >>>>> buf(2,i) = ii+1 >>>>> buf(3,i) = ii+2 >>>>> WRITE(11) buf(1:3,i) >>>>> ii = ii + 3 >>>>> ENDDO >>>>> CLOSE(UNIT=11) >>>>> >>>>> END PROGRAM writeUstream >>>>> >>>>> And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: >>>>> >>>>> PROGRAM struct >>>>> >>>>> USE mpi >>>>> >>>>> IMPLICIT NONE >>>>> >>>>> INTEGER, PARAMETER :: NELEM = 2 >>>>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>>>> INTEGER :: stat(MPI_STATUS_SIZE) >>>>> INTEGER :: fh >>>>> INTEGER :: status >>>>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>>>> >>>>> INTEGER, DIMENSION(1:3) :: iiaux >>>>> >>>>> TYPE Particle >>>>> SEQUENCE >>>>> INTEGER, DIMENSION(1:3) :: indx >>>>> END TYPE Particle >>>>> >>>>> TYPE(Particle), DIMENSION(1:nelem) :: particles >>>>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent >>>>> >>>>> CALL MPI_INIT(ierr) >>>>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>>>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>>>> >>>>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>>>> offsets(1) = 0 >>>>> oldtypes(1) = MPI_INTEGER >>>>> blockcounts(1) = 3 >>>>> >>>>> ! Now define structured TYPE and commit it >>>>> CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) >>>>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>>>> >>>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>>>> >>>>> disp = 0 >>>>> >>>>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>>>> >>>>> particles(1:nelem)%indx = -1 >>>>> >>>>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>>>> >>>>> PRINT*,"derived type" >>>>> DO i=1,nelem >>>>> PRINT*,particles(i)%indx >>>>> ENDDO >>>>> >>>>> CALL MPI_File_close(fh, ierr) >>>>> >>>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>>>> MPI_INFO_NULL, fh, ierr) >>>>> >>>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>>> >>>>> PRINT*,"No derived type" >>>>> >>>>> PRINT*,iiaux >>>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>>> PRINT*,iiaux >>>>> >>>>> CALL MPI_File_close(fh, ierr) >>>>> >>>>> CALL MPI_FINALIZE(ierr) >>>>> END PROGRAM struct >>>>> >>>>> >>>>> When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: >>>>> >>>>> derived type >>>>> 24 0 3 >>>>> 4 5 6 >>>>> No derived type >>>>> 1 2 3 >>>>> 4 5 6 >>>>> >>>>> I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux >>>>> I not exactly sure what is going on. >>>>> >>>>> Thanks, >>>>> Scot >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Failed to allocate memory for an unexpected message
by Kenneth Raffenetti 11 Mar '14

11 Mar '14

You could use MPI_Probe/MPI_Iprobe and pass in your "data" tag to test for any more pending messages. Ken On 03/11/2014 02:50 PM, Luiz Carlos da Costa Junior wrote: > Dear all, > > I am all set with your suggestions and my program is working quite well > without any "unexpected message" since then, thanks again. > > However now I am facing a small problem I describe next. > > My receiver process receives actually 2 types of messages (2 different > tags): > > * the basic tag means that the message is a "data message" ("data" > tag) that should be processed. > * the second one means that the worker process is done and it will > send no more messages ("end_of_processing" tag). > > Once all worker processes send their end_of_processing tag, the receiver > process finishes its execution. > > The problem I noticed is that some of the last messages sent by the > worker processes were not being processed. I think the problem is > related with the logic I am using with MPI_WAITANY in the receiver > process. I am simply counting the number of end_of_processing messages > received and if it reaches the number of worker processes, I finish the > execution without checking if there are more messages to be received at > the MPI_WAITANY queue. > > As the order that messages arrive is not relevant for MPI_WAITANY I > think that my logic forgets some of the messages at the end of the > queue. Is this right? > > Is there any way to check if there is any pending request to be processed? > > Best regards, > Luiz > > > On 16 January 2014 16:57, "Antonio J. Peña" <apenya(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > A profiling of both of your codes would help to understand where the > time is spent and the difference between them in terms of performance. > > Antonio > > > > On 01/16/2014 12:47 PM, Luiz Carlos da Costa Junior wrote: >> Yes, I am comparing original x new implementation. >> >> The original implementation is as follows. >> >> c----------------------------------------------------------------------- >> subroutine my_receiver_original >> c ------------------------------------------------------------------ >> (...) >> >> c Local >> c ----- >> integer*4 m_stat(MPI_STATUS_SIZE) >> character card*(zbuf) ! buffer for messages received >> >> do while( keep_receiving ) >> call MPI_RECV(card, zbuf, MPI_CHARACTER, >> . MPI_ANY_SOURCE, M_RECCSV, MY_COMM, >> . m_stat, m_ierr ) >> >> c Process message: disk IO >> c --------------- >> <DO SOMETHING> >> if( SOMETHING_ELSE ) then >> keep_receiving = .false. >> end if >> end do >> >> (...) >> >> return >> end >> >> Regards, >> Luiz >> >> On 16 January 2014 16:19, Balaji, Pavan <balaji(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> >> On Jan 16, 2014, at 12:16 PM, Luiz Carlos da Costa Junior >> <lcjunior(a)ufrj.br <mailto:[email protected]>> wrote: >> > No, these failures don't occur all the time. I have a >> successful run (with my original implementation) which I am >> using as the base case for comparison. >> >> What are the two cases you are comparing? Original >> implementation vs. new implementation? What’s the original >> implementation? >> >> — Pavan >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> >> _______________________________________________ >> discuss mailing listdiscuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847 > apenya(a)mcs.anl.gov <mailto:[email protected]> > www.mcs.anl.gov/~apenya <http://www.mcs.anl.gov/~apenya> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Rajeev Thakur 11 Mar '14

11 Mar '14

>> The comment about documentation was geared toward the people in charge of mpich.org, since they run the mailing list and I’m assuming they are in charge of the Documentation Manpages on mpich.org. I just gravitate to an html document rather then scanning a pdf :) I meant to say the documentation on that page is correct. It is exactly as it is in the MPI standard. The description of arguments is a generic description, where integer does not refer to a particular size of integer. Rajeev On Mar 11, 2014, at 2:51 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > I ran it on a Mac. 64 bit. > > Rajeev > > On Mar 11, 2014, at 2:49 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> > wrote: > >> I could also get it to work on >> >> Linux 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> >> which is probably what your laptop is running? >> >> Maybe it’s a 32-bit version issue? >> >> The comment about documentation was geared toward the people in charge of mpich.org, since they run the mailing list and I’m assuming they are in charge of the Documentation Manpages on mpich.org. I just gravitate to an html document rather then scanning a pdf :) >> >> Thanks, >> Scot >> >> >> On Mar 11, 2014, at 2:13 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> >>> The modified program works correctly on my laptop. >>> >>>> Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>>> >>>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >>> >>> That page provides the C binding and generic description of arguments identical to the one provided on pg 93 of the MPI 3.0 standard. In any case, the definitive source for function bindings should be the MPI 3.0 standard available at www.mpi-forum.org, not any other web site. >>> >>> Rajeev >>> >>> >>> >>> On Mar 11, 2014, at 1:39 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >>> >>>> I checked the original program and the suggested version on another machine using >>>> >>>> mpif90 for MPICH2 version 1.5 >>>> exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) >>>> exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) >>>> >>>> And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>>> >>>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >>>> >>>> I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. >>>> >>>> Scot >>>> >>>> Updated program: >>>> >>>> PROGRAM struct >>>> >>>> USE mpi >>>> USE iso_c_binding >>>> >>>> IMPLICIT NONE >>>> >>>> INTEGER, PARAMETER :: NELEM = 2 >>>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>>> INTEGER :: stat(MPI_STATUS_SIZE) >>>> INTEGER :: fh >>>> INTEGER :: status >>>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>>> >>>> INTEGER, DIMENSION(1:3) :: iiaux >>>> >>>> TYPE Particle >>>> SEQUENCE >>>> INTEGER, DIMENSION(1:3) :: indx >>>> END TYPE Particle >>>> >>>> TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles >>>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent >>>> INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets >>>> TYPE(C_PTR) :: fptr >>>> >>>> CALL MPI_INIT(ierr) >>>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>>> >>>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>>> offsets(1) = 0 >>>> oldtypes(1) = MPI_INTEGER >>>> blockcounts(1) = 3 >>>> >>>> ! Now define structured TYPE and commit it >>>> CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) >>>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>>> >>>> disp = 0 >>>> >>>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>>> >>>> particles(1)%indx = -1 >>>> >>>> fptr = C_LOC( particles(1)%indx(1)) >>>> >>>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>>> >>>> PRINT*,"Derived type" >>>> DO i=1,nelem >>>> PRINT*,particles(i)%indx >>>> ENDDO >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>>> MPI_INFO_NULL, fh, ierr) >>>> >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> >>>> PRINT*,"No derived type" >>>> >>>> PRINT*,iiaux >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> PRINT*,iiaux >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_FINALIZE(ierr) >>>> END PROGRAM struct >>>> >>>> >>>> >>>> >>>> >>>> On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> I created a file in fortran using (which I compiled with mpif90): >>>>> >>>>> PROGRAM writeUstream >>>>> >>>>> IMPLICIT NONE >>>>> INTEGER :: i, ii >>>>> INTEGER, DIMENSION(1:3,1:25) :: buf >>>>> >>>>> OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") >>>>> >>>>> ii = 1 >>>>> >>>>> DO i=1, 25 >>>>> buf(1,i) = ii >>>>> buf(2,i) = ii+1 >>>>> buf(3,i) = ii+2 >>>>> WRITE(11) buf(1:3,i) >>>>> ii = ii + 3 >>>>> ENDDO >>>>> CLOSE(UNIT=11) >>>>> >>>>> END PROGRAM writeUstream >>>>> >>>>> And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: >>>>> >>>>> PROGRAM struct >>>>> >>>>> USE mpi >>>>> >>>>> IMPLICIT NONE >>>>> >>>>> INTEGER, PARAMETER :: NELEM = 2 >>>>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>>>> INTEGER :: stat(MPI_STATUS_SIZE) >>>>> INTEGER :: fh >>>>> INTEGER :: status >>>>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>>>> >>>>> INTEGER, DIMENSION(1:3) :: iiaux >>>>> >>>>> TYPE Particle >>>>> SEQUENCE >>>>> INTEGER, DIMENSION(1:3) :: indx >>>>> END TYPE Particle >>>>> >>>>> TYPE(Particle), DIMENSION(1:nelem) :: particles >>>>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent >>>>> >>>>> CALL MPI_INIT(ierr) >>>>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>>>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>>>> >>>>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>>>> offsets(1) = 0 >>>>> oldtypes(1) = MPI_INTEGER >>>>> blockcounts(1) = 3 >>>>> >>>>> ! Now define structured TYPE and commit it >>>>> CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) >>>>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>>>> >>>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>>>> >>>>> disp = 0 >>>>> >>>>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>>>> >>>>> particles(1:nelem)%indx = -1 >>>>> >>>>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>>>> >>>>> PRINT*,"derived type" >>>>> DO i=1,nelem >>>>> PRINT*,particles(i)%indx >>>>> ENDDO >>>>> >>>>> CALL MPI_File_close(fh, ierr) >>>>> >>>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>>>> MPI_INFO_NULL, fh, ierr) >>>>> >>>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>>> >>>>> PRINT*,"No derived type" >>>>> >>>>> PRINT*,iiaux >>>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>>> PRINT*,iiaux >>>>> >>>>> CALL MPI_File_close(fh, ierr) >>>>> >>>>> CALL MPI_FINALIZE(ierr) >>>>> END PROGRAM struct >>>>> >>>>> >>>>> When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: >>>>> >>>>> derived type >>>>> 24 0 3 >>>>> 4 5 6 >>>>> No derived type >>>>> 1 2 3 >>>>> 4 5 6 >>>>> >>>>> I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux >>>>> I not exactly sure what is going on. >>>>> >>>>> Thanks, >>>>> Scot >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Rajeev Thakur 11 Mar '14

11 Mar '14

I ran it on a Mac. 64 bit. Rajeev On Mar 11, 2014, at 2:49 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > I could also get it to work on > > Linux 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > which is probably what your laptop is running? > > Maybe it’s a 32-bit version issue? > > The comment about documentation was geared toward the people in charge of mpich.org, since they run the mailing list and I’m assuming they are in charge of the Documentation Manpages on mpich.org. I just gravitate to an html document rather then scanning a pdf :) > > Thanks, > Scot > > > On Mar 11, 2014, at 2:13 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > >> The modified program works correctly on my laptop. >> >>> Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>> >>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >> >> That page provides the C binding and generic description of arguments identical to the one provided on pg 93 of the MPI 3.0 standard. In any case, the definitive source for function bindings should be the MPI 3.0 standard available at www.mpi-forum.org, not any other web site. >> >> Rajeev >> >> >> >> On Mar 11, 2014, at 1:39 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >> >>> I checked the original program and the suggested version on another machine using >>> >>> mpif90 for MPICH2 version 1.5 >>> exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) >>> exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) >>> >>> And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >>> >>> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >>> >>> I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. >>> >>> Scot >>> >>> Updated program: >>> >>> PROGRAM struct >>> >>> USE mpi >>> USE iso_c_binding >>> >>> IMPLICIT NONE >>> >>> INTEGER, PARAMETER :: NELEM = 2 >>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>> INTEGER :: stat(MPI_STATUS_SIZE) >>> INTEGER :: fh >>> INTEGER :: status >>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>> >>> INTEGER, DIMENSION(1:3) :: iiaux >>> >>> TYPE Particle >>> SEQUENCE >>> INTEGER, DIMENSION(1:3) :: indx >>> END TYPE Particle >>> >>> TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles >>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent >>> INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets >>> TYPE(C_PTR) :: fptr >>> >>> CALL MPI_INIT(ierr) >>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>> >>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>> offsets(1) = 0 >>> oldtypes(1) = MPI_INTEGER >>> blockcounts(1) = 3 >>> >>> ! Now define structured TYPE and commit it >>> CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) >>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>> >>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>> >>> disp = 0 >>> >>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>> >>> particles(1)%indx = -1 >>> >>> fptr = C_LOC( particles(1)%indx(1)) >>> >>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>> >>> PRINT*,"Derived type" >>> DO i=1,nelem >>> PRINT*,particles(i)%indx >>> ENDDO >>> >>> CALL MPI_File_close(fh, ierr) >>> >>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>> MPI_INFO_NULL, fh, ierr) >>> >>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>> >>> PRINT*,"No derived type" >>> >>> PRINT*,iiaux >>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>> PRINT*,iiaux >>> >>> CALL MPI_File_close(fh, ierr) >>> >>> CALL MPI_FINALIZE(ierr) >>> END PROGRAM struct >>> >>> >>> >>> >>> >>> On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >>> >>>> Hi, >>>> >>>> I created a file in fortran using (which I compiled with mpif90): >>>> >>>> PROGRAM writeUstream >>>> >>>> IMPLICIT NONE >>>> INTEGER :: i, ii >>>> INTEGER, DIMENSION(1:3,1:25) :: buf >>>> >>>> OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") >>>> >>>> ii = 1 >>>> >>>> DO i=1, 25 >>>> buf(1,i) = ii >>>> buf(2,i) = ii+1 >>>> buf(3,i) = ii+2 >>>> WRITE(11) buf(1:3,i) >>>> ii = ii + 3 >>>> ENDDO >>>> CLOSE(UNIT=11) >>>> >>>> END PROGRAM writeUstream >>>> >>>> And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: >>>> >>>> PROGRAM struct >>>> >>>> USE mpi >>>> >>>> IMPLICIT NONE >>>> >>>> INTEGER, PARAMETER :: NELEM = 2 >>>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>>> INTEGER :: stat(MPI_STATUS_SIZE) >>>> INTEGER :: fh >>>> INTEGER :: status >>>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>>> >>>> INTEGER, DIMENSION(1:3) :: iiaux >>>> >>>> TYPE Particle >>>> SEQUENCE >>>> INTEGER, DIMENSION(1:3) :: indx >>>> END TYPE Particle >>>> >>>> TYPE(Particle), DIMENSION(1:nelem) :: particles >>>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent >>>> >>>> CALL MPI_INIT(ierr) >>>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>>> >>>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>>> offsets(1) = 0 >>>> oldtypes(1) = MPI_INTEGER >>>> blockcounts(1) = 3 >>>> >>>> ! Now define structured TYPE and commit it >>>> CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) >>>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>>> >>>> disp = 0 >>>> >>>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>>> >>>> particles(1:nelem)%indx = -1 >>>> >>>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>>> >>>> PRINT*,"derived type" >>>> DO i=1,nelem >>>> PRINT*,particles(i)%indx >>>> ENDDO >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>>> MPI_INFO_NULL, fh, ierr) >>>> >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> >>>> PRINT*,"No derived type" >>>> >>>> PRINT*,iiaux >>>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>>> PRINT*,iiaux >>>> >>>> CALL MPI_File_close(fh, ierr) >>>> >>>> CALL MPI_FINALIZE(ierr) >>>> END PROGRAM struct >>>> >>>> >>>> When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: >>>> >>>> derived type >>>> 24 0 3 >>>> 4 5 6 >>>> No derived type >>>> 1 2 3 >>>> 4 5 6 >>>> >>>> I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux >>>> I not exactly sure what is going on. >>>> >>>> Thanks, >>>> Scot >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Failed to allocate memory for an unexpected message
by Luiz Carlos da Costa Junior 11 Mar '14

11 Mar '14

Dear all, I am all set with your suggestions and my program is working quite well without any "unexpected message" since then, thanks again. However now I am facing a small problem I describe next. My receiver process receives actually 2 types of messages (2 different tags): - the basic tag means that the message is a "data message" ("data" tag) that should be processed. - the second one means that the worker process is done and it will send no more messages ("end_of_processing" tag). Once all worker processes send their end_of_processing tag, the receiver process finishes its execution. The problem I noticed is that some of the last messages sent by the worker processes were not being processed. I think the problem is related with the logic I am using with MPI_WAITANY in the receiver process. I am simply counting the number of end_of_processing messages received and if it reaches the number of worker processes, I finish the execution without checking if there are more messages to be received at the MPI_WAITANY queue. As the order that messages arrive is not relevant for MPI_WAITANY I think that my logic forgets some of the messages at the end of the queue. Is this right? Is there any way to check if there is any pending request to be processed? Best regards, Luiz On 16 January 2014 16:57, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: > > A profiling of both of your codes would help to understand where the time > is spent and the difference between them in terms of performance. > > Antonio > > > > On 01/16/2014 12:47 PM, Luiz Carlos da Costa Junior wrote: > > Yes, I am comparing original x new implementation. > > The original implementation is as follows. > > c----------------------------------------------------------------------- > subroutine my_receiver_original > c ------------------------------------------------------------------ > (...) > > c Local > c ----- > integer*4 m_stat(MPI_STATUS_SIZE) > character card*(zbuf) ! buffer for messages received > > do while( keep_receiving ) > call MPI_RECV(card, zbuf, MPI_CHARACTER, > . MPI_ANY_SOURCE, M_RECCSV, MY_COMM, > . m_stat, m_ierr ) > > c Process message: disk IO > c --------------- > <DO SOMETHING> > if( SOMETHING_ELSE ) then > keep_receiving = .false. > end if > end do > > (...) > > return > end > > Regards, > Luiz > > On 16 January 2014 16:19, Balaji, Pavan <balaji(a)mcs.anl.gov> wrote: > >> >> On Jan 16, 2014, at 12:16 PM, Luiz Carlos da Costa Junior < >> lcjunior(a)ufrj.br> wrote: >> > No, these failures don't occur all the time. I have a successful run >> (with my original implementation) which I am using as the base case for >> comparison. >> >> What are the two cases you are comparing? Original implementation vs. >> new implementation? What's the original implementation? >> >> -- Pavan >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847apenya(a)mcs.anl.govwww.mcs.anl.gov/~apenya > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0