[OMPI users] where is mpif.h ?
Does openmpi have any "mpif.h" ?? if yes, where? in openmpi_dir/include ??!!
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Ahhh, now that makes sense. Never included, always used. Thanks! On Mon, Sep 22, 2008 at 8:55 PM, Terry Frankcombe wrote: > Remember what include does: it essentially dumps mpif.h into the > source. So to be proper F90 you need: > > PROGRAM main > USE local_module > IMPLICT NONE > INCLUDE 'mpif.h' > ... > > > On Mon, 2008-09-22 at 20:17 -0600, Brian Harker wrote: >> Well, I'm stumped then...my top-level program is the only one that >> uses MPI interfaces. I USE other f90 module files, but none of them >> are dependent on MPI functions. For example here's the first few >> lines of code where things act up: >> >> PROGRAM main >> INCLUDE 'mpif.h' (this line used to be "USE mpi"...this is >> correct replacement, right?) >> USE local_module >> IMPLICIT NONE >> ... >> STOP >> END PROGRAM main >> >> with local_module.f90: >> >> MODULE local_module >> CONTAINS >> >> SUBROUTINE local_subroutine >> IMPLICIT NONE >> ... >> RETURN >> END SUBROUTINE local_subroutine >> >> END MODULE local_module >> >> and mpif90 gives me grief about local_module being out of scope within >> main. To the best of my knowledge, I have never used fixed-form or >> had free-vs-fixed form compiler issues with ifort. Thanks! >> >> On Mon, Sep 22, 2008 at 7:56 PM, Gus Correa wrote: >> > Hi Brian and list >> > >> > On my code I have >> > >> > include 'mpif.h' >> > >> > with single quotes around the file name. >> > I use single quotes, but double quotes are also possible according to the >> > F90 standard. >> > If you start at column 7 and end at column 72, >> > you avoid any problems with free vs. fixed Fortran form (which may happen >> > if >> > one decides >> > to mess the compiler options on Makefiles, for instance). >> > This is PDP, paranoid defensive programming. >> > I type the Fortran commands in lowercase (include) but this may not really >> > make any difference >> > (although there are compiler options to transliterate upper to lower, >> > be/not >> > be case sensitive, etc) >> > >> > However, since you asked, I changed the "include 'mpif.h'" location to >> > column 1, column 6, >> > etc, and I could compile the code with OpenMPI mpif90 without any problems. >> > Hence, I presume mpif90 uses the free form as default. >> > So, I wonder if you still have some residual mix of gfortran and ifort >> > there, >> > or if there is some funny configuration on your ifort.cfg file choosing the >> > fixed form as a default. >> > >> > In any case, going out of scope probably has nothing to do with fixed vs >> > free form. >> > I only have one "use mpi" statement, no other modules "used" in the little >> > hello_f90. >> > It may well be that if you try other "use" statements, particularly if the >> > respective modules >> > involve other MPI modules or MPI function interfaces, things may break and >> > be out of scope. >> > I presume you are not talking of hello_f90 anymore, but of a larger code. >> > The large code examples I have here use other F90 modules (not mpi.mod), >> > but they don't rely on MPI interfaces. >> > >> > Glad to know that the main problem is gone (I read the more recent >> > messages). >> > I was reluctant to tell you to do a "make distclean", and start fresh, >> > configure again, make again, >> > because you said you had built the OpenMPI library more than once. >> > Now I think that was exactly what I should have told you to do. >> > Everybody builds these things many times to get them right. >> > Then a few more times to make it efficient, to optimize, etc. >> > Can you imagine how many times Rutherford set up that gold foil experiment >> > until he got it right? :) >> > After it is done, the past errors become trivial, and all the rest is >> > reduced just to stamp collecting. :) >> > Configure is always complex, and dumping its output to a log file is >> > worth the effort, to check out for sticky problems like this, which often >> > happen. >> > (Likewise for make and make install.) >> > >> > I hope this helps, >> > Gus Correa >> > >> > -- >> > - >> > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu >> > Lamont-Doherty Earth Observatory - Columbia University >> > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA >> > - >> > >> > >> > Brian Harker wrote: >> > >> >> Hi Gus- >> >> >> >> Thanks for the idea. One question: how do you position INCLUDE >> >> statements in a fortran program, because if I just straight substitute >> >> ' INCLUDE "mpif.h" ' for ' USE mpi ', I get a lot of crap telling me >> >> my other USE statements are not positioned correctly within the scope >> >> and nothing compiles. I have tried various positions, but I seem to >> >> be suffering from a lot of BS. Am I overlooking something very >> >> obvious? >> >> >> >> On Mon, Sep 22, 2008 at 5:42 PM, Gus Correa >> >> wrote: >> >> >> >>> >> >>> Hi Brian and list
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Remember what include does: it essentially dumps mpif.h into the source. So to be proper F90 you need: PROGRAM main USE local_module IMPLICT NONE INCLUDE 'mpif.h' ... On Mon, 2008-09-22 at 20:17 -0600, Brian Harker wrote: > Well, I'm stumped then...my top-level program is the only one that > uses MPI interfaces. I USE other f90 module files, but none of them > are dependent on MPI functions. For example here's the first few > lines of code where things act up: > > PROGRAM main > INCLUDE 'mpif.h' (this line used to be "USE mpi"...this is > correct replacement, right?) > USE local_module > IMPLICIT NONE > ... > STOP > END PROGRAM main > > with local_module.f90: > > MODULE local_module > CONTAINS > > SUBROUTINE local_subroutine > IMPLICIT NONE > ... > RETURN > END SUBROUTINE local_subroutine > > END MODULE local_module > > and mpif90 gives me grief about local_module being out of scope within > main. To the best of my knowledge, I have never used fixed-form or > had free-vs-fixed form compiler issues with ifort. Thanks! > > On Mon, Sep 22, 2008 at 7:56 PM, Gus Correa wrote: > > Hi Brian and list > > > > On my code I have > > > > include 'mpif.h' > > > > with single quotes around the file name. > > I use single quotes, but double quotes are also possible according to the > > F90 standard. > > If you start at column 7 and end at column 72, > > you avoid any problems with free vs. fixed Fortran form (which may happen if > > one decides > > to mess the compiler options on Makefiles, for instance). > > This is PDP, paranoid defensive programming. > > I type the Fortran commands in lowercase (include) but this may not really > > make any difference > > (although there are compiler options to transliterate upper to lower, be/not > > be case sensitive, etc) > > > > However, since you asked, I changed the "include 'mpif.h'" location to > > column 1, column 6, > > etc, and I could compile the code with OpenMPI mpif90 without any problems. > > Hence, I presume mpif90 uses the free form as default. > > So, I wonder if you still have some residual mix of gfortran and ifort > > there, > > or if there is some funny configuration on your ifort.cfg file choosing the > > fixed form as a default. > > > > In any case, going out of scope probably has nothing to do with fixed vs > > free form. > > I only have one "use mpi" statement, no other modules "used" in the little > > hello_f90. > > It may well be that if you try other "use" statements, particularly if the > > respective modules > > involve other MPI modules or MPI function interfaces, things may break and > > be out of scope. > > I presume you are not talking of hello_f90 anymore, but of a larger code. > > The large code examples I have here use other F90 modules (not mpi.mod), > > but they don't rely on MPI interfaces. > > > > Glad to know that the main problem is gone (I read the more recent > > messages). > > I was reluctant to tell you to do a "make distclean", and start fresh, > > configure again, make again, > > because you said you had built the OpenMPI library more than once. > > Now I think that was exactly what I should have told you to do. > > Everybody builds these things many times to get them right. > > Then a few more times to make it efficient, to optimize, etc. > > Can you imagine how many times Rutherford set up that gold foil experiment > > until he got it right? :) > > After it is done, the past errors become trivial, and all the rest is > > reduced just to stamp collecting. :) > > Configure is always complex, and dumping its output to a log file is > > worth the effort, to check out for sticky problems like this, which often > > happen. > > (Likewise for make and make install.) > > > > I hope this helps, > > Gus Correa > > > > -- > > - > > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > > Lamont-Doherty Earth Observatory - Columbia University > > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > > - > > > > > > Brian Harker wrote: > > > >> Hi Gus- > >> > >> Thanks for the idea. One question: how do you position INCLUDE > >> statements in a fortran program, because if I just straight substitute > >> ' INCLUDE "mpif.h" ' for ' USE mpi ', I get a lot of crap telling me > >> my other USE statements are not positioned correctly within the scope > >> and nothing compiles. I have tried various positions, but I seem to > >> be suffering from a lot of BS. Am I overlooking something very > >> obvious? > >> > >> On Mon, Sep 22, 2008 at 5:42 PM, Gus Correa wrote: > >> > >>> > >>> Hi Brian and list > >>> > >>> I seldom used the "use mpi" syntax before. > >>> I have a lot of code here written in Fortran 90, > >>> but and mpif.h is included instead "use mpi". > >>> The MPI function calls are the same in Fortran 77 and Fortran 90 syntax, > >>> hence there is just one line
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Well, I'm stumped then...my top-level program is the only one that uses MPI interfaces. I USE other f90 module files, but none of them are dependent on MPI functions. For example here's the first few lines of code where things act up: PROGRAM main INCLUDE 'mpif.h' (this line used to be "USE mpi"...this is correct replacement, right?) USE local_module IMPLICIT NONE ... STOP END PROGRAM main with local_module.f90: MODULE local_module CONTAINS SUBROUTINE local_subroutine IMPLICIT NONE ... RETURN END SUBROUTINE local_subroutine END MODULE local_module and mpif90 gives me grief about local_module being out of scope within main. To the best of my knowledge, I have never used fixed-form or had free-vs-fixed form compiler issues with ifort. Thanks! On Mon, Sep 22, 2008 at 7:56 PM, Gus Correa wrote: > Hi Brian and list > > On my code I have > > include 'mpif.h' > > with single quotes around the file name. > I use single quotes, but double quotes are also possible according to the > F90 standard. > If you start at column 7 and end at column 72, > you avoid any problems with free vs. fixed Fortran form (which may happen if > one decides > to mess the compiler options on Makefiles, for instance). > This is PDP, paranoid defensive programming. > I type the Fortran commands in lowercase (include) but this may not really > make any difference > (although there are compiler options to transliterate upper to lower, be/not > be case sensitive, etc) > > However, since you asked, I changed the "include 'mpif.h'" location to > column 1, column 6, > etc, and I could compile the code with OpenMPI mpif90 without any problems. > Hence, I presume mpif90 uses the free form as default. > So, I wonder if you still have some residual mix of gfortran and ifort > there, > or if there is some funny configuration on your ifort.cfg file choosing the > fixed form as a default. > > In any case, going out of scope probably has nothing to do with fixed vs > free form. > I only have one "use mpi" statement, no other modules "used" in the little > hello_f90. > It may well be that if you try other "use" statements, particularly if the > respective modules > involve other MPI modules or MPI function interfaces, things may break and > be out of scope. > I presume you are not talking of hello_f90 anymore, but of a larger code. > The large code examples I have here use other F90 modules (not mpi.mod), > but they don't rely on MPI interfaces. > > Glad to know that the main problem is gone (I read the more recent > messages). > I was reluctant to tell you to do a "make distclean", and start fresh, > configure again, make again, > because you said you had built the OpenMPI library more than once. > Now I think that was exactly what I should have told you to do. > Everybody builds these things many times to get them right. > Then a few more times to make it efficient, to optimize, etc. > Can you imagine how many times Rutherford set up that gold foil experiment > until he got it right? :) > After it is done, the past errors become trivial, and all the rest is > reduced just to stamp collecting. :) > Configure is always complex, and dumping its output to a log file is > worth the effort, to check out for sticky problems like this, which often > happen. > (Likewise for make and make install.) > > I hope this helps, > Gus Correa > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > >> Hi Gus- >> >> Thanks for the idea. One question: how do you position INCLUDE >> statements in a fortran program, because if I just straight substitute >> ' INCLUDE "mpif.h" ' for ' USE mpi ', I get a lot of crap telling me >> my other USE statements are not positioned correctly within the scope >> and nothing compiles. I have tried various positions, but I seem to >> be suffering from a lot of BS. Am I overlooking something very >> obvious? >> >> On Mon, Sep 22, 2008 at 5:42 PM, Gus Correa wrote: >> >>> >>> Hi Brian and list >>> >>> I seldom used the "use mpi" syntax before. >>> I have a lot of code here written in Fortran 90, >>> but and mpif.h is included instead "use mpi". >>> The MPI function calls are the same in Fortran 77 and Fortran 90 syntax, >>> hence there is just one line of code to change, if one wants to go fully >>> F90. >>> All works well, though. >>> This style is a legacy from the times when the Fortran90 interface of MPI >>> was not fully developed, >>> and the mpi.mod was broken most of the time. >>> That is no longer the case, though. >>> >>> This mixed mode may be one way around your problem, although not ideal. >>> The main drawback of using the "include mpif.h" syntax >>> is that there is no parameter checking of the MPI f
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Brian and list On my code I have include 'mpif.h' with single quotes around the file name. I use single quotes, but double quotes are also possible according to the F90 standard. If you start at column 7 and end at column 72, you avoid any problems with free vs. fixed Fortran form (which may happen if one decides to mess the compiler options on Makefiles, for instance). This is PDP, paranoid defensive programming. I type the Fortran commands in lowercase (include) but this may not really make any difference (although there are compiler options to transliterate upper to lower, be/not be case sensitive, etc) However, since you asked, I changed the "include 'mpif.h'" location to column 1, column 6, etc, and I could compile the code with OpenMPI mpif90 without any problems. Hence, I presume mpif90 uses the free form as default. So, I wonder if you still have some residual mix of gfortran and ifort there, or if there is some funny configuration on your ifort.cfg file choosing the fixed form as a default. In any case, going out of scope probably has nothing to do with fixed vs free form. I only have one "use mpi" statement, no other modules "used" in the little hello_f90. It may well be that if you try other "use" statements, particularly if the respective modules involve other MPI modules or MPI function interfaces, things may break and be out of scope. I presume you are not talking of hello_f90 anymore, but of a larger code. The large code examples I have here use other F90 modules (not mpi.mod), but they don't rely on MPI interfaces. Glad to know that the main problem is gone (I read the more recent messages). I was reluctant to tell you to do a "make distclean", and start fresh, configure again, make again, because you said you had built the OpenMPI library more than once. Now I think that was exactly what I should have told you to do. Everybody builds these things many times to get them right. Then a few more times to make it efficient, to optimize, etc. Can you imagine how many times Rutherford set up that gold foil experiment until he got it right? :) After it is done, the past errors become trivial, and all the rest is reduced just to stamp collecting. :) Configure is always complex, and dumping its output to a log file is worth the effort, to check out for sticky problems like this, which often happen. (Likewise for make and make install.) I hope this helps, Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: Hi Gus- Thanks for the idea. One question: how do you position INCLUDE statements in a fortran program, because if I just straight substitute ' INCLUDE "mpif.h" ' for ' USE mpi ', I get a lot of crap telling me my other USE statements are not positioned correctly within the scope and nothing compiles. I have tried various positions, but I seem to be suffering from a lot of BS. Am I overlooking something very obvious? On Mon, Sep 22, 2008 at 5:42 PM, Gus Correa wrote: Hi Brian and list I seldom used the "use mpi" syntax before. I have a lot of code here written in Fortran 90, but and mpif.h is included instead "use mpi". The MPI function calls are the same in Fortran 77 and Fortran 90 syntax, hence there is just one line of code to change, if one wants to go fully F90. All works well, though. This style is a legacy from the times when the Fortran90 interface of MPI was not fully developed, and the mpi.mod was broken most of the time. That is no longer the case, though. This mixed mode may be one way around your problem, although not ideal. The main drawback of using the "include mpif.h" syntax is that there is no parameter checking of the MPI function calls, whereas the "use mpi" syntax provide some level of parameter checking through the mpi.mod module. If you are careful when you write your MPI calls, and check if all parameters match the syntax requirements strictly, this shouldn't be a problem, though. (Nevertheless, a few days ago somebody was suffering here on the list with a problem that was just a missing "ierr" parameter in an MPI_Send call. Jeff found it out, after several emails back and forth.) If not for anything else, just for the fun of it, to see how far the compilation goes, I would comment out "use mpi" and replace it by "include mpif.h". As for architecture and compiler, I have used with no problem OpenMPI (and MPICH2 and MPICH-1) on various x86 and x86_64 machines, both AMD and Intel, under different Linux flavors (Fedora, CentOS, Red Hat), in standalone machines (using SMP and shared memory), and on a small cluster using Ethernet 100T , then using Gigabit Ethernet, compiling it with gcc and ifort and with gcc and pgf9
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Yes I have matched all the arguments. I should mention that the code compiles and runs flawlessly using MPICH2-1.0.7 so it's got to be an issue with my specific build of openMPI. I want to get openMPI up and running for performance comparisons. On Mon, Sep 22, 2008 at 6:43 PM, Jeff Squyres wrote: > What's the source code in question, then? Did you match all the arguments? > > > On Sep 22, 2008, at 8:36 PM, Brian Harker wrote: > >> Nope, no user-defined types or arrays greater than 2 dimensions. >> >> On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres wrote: >>> >>> On Sep 22, 2008, at 6:48 PM, Brian Harker wrote: >>> when I compile my production code, I get: fortcom: Error: driver.f90: line 211: There is no matching specific subroutine for this generic subroutine call. [MPI_SEND] Seems odd that it would spit up on MPI_SEND, but has no problem with MPI_RECV... What do you guys think? And thanks again for your help and patience? >>> >>> The F90 MPI bindings have some well-known design flaws (i.e., problems >>> with >>> the standard itself, not any particular implementation). Many of them >>> center around the fact that F90 is a strongly-typed language. See this >>> paper for some details: >>> >>> http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/ >>> >>> Here's the highlights, as they pertain to writing F90 MPI apps: >>> >>> - There is no equivalent to C's (void*). This means that the F90 MPI >>> bindings cannot accept user-defined datatypes. >>> >>> - This also means that *every* pre-defined type must have a F90 MPI >>> binding. >>> There are approximately 15 intrinsic size/type combinations. There are >>> 50 >>> MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 >>> functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying >>> this >>> math from the paper, and I think we got it slightly wrong (there was a >>> discussion about it on this list a while ago), but it results in many >>> *millions* of F90 MPI bindings functions. There's no compiler on the >>> planet >>> than can handle all of these in a single F90 module. >>> >>> Open MPI compensates for this with the following: >>> >>> - F90 bindings are not created for any of the 2-choice-buffer functions >>> - F90 bindings are created for all the 1-choice-buffer functions, but >>> only >>> for dimensions up to N dimensions (N defaults to 4, IIRC). You can >>> change >>> the value of N with OMPI's configure script; use the >>> --with-f90-max-array-dim. The maximum value of N is 7. >>> >>> So -- your app failed to compile because you either used a user-defined >>> datatype or you used an array with a dimension greater than 4. If it was >>> a >>> greater-dimension issue, you can reconfigure/recompile/reinstall OMPI >>> (again, sorry) with a larger N value. If it was a user-defined datatype, >>> you unfortunately have to "include mpif.h" in that >>> subroutine/function/whatever, sorry (and you lose the type checking). >>> :-( >>> >>> Here's some info from OMPI's README: >>> >>> - >>> - The Fortran 90 MPI bindings can now be built in one of three sizes >>> using --with-mpi-f90-size=SIZE (see description below). These sizes >>> reflect the number of MPI functions included in the "mpi" Fortran 90 >>> module and therefore which functions will be subject to strict type >>> checking. All functions not included in the Fortran 90 module can >>> still be invoked from F90 applications, but will fall back to >>> Fortran-77 style checking (i.e., little/none). >>> >>> - trivial: Only includes F90-specific functions from MPI-2. This >>> means overloaded versions of MPI_SIZEOF for all the MPI-supported >>> F90 intrinsic types. >>> >>> - small (default): All the functions in "trivial" plus all MPI >>> functions that take no choice buffers (meaning buffers that are >>> specified by the user and are of type (void*) in the C bindings -- >>> generally buffers specified for message passing). Hence, >>> functions like MPI_COMM_RANK are included, but functions like >>> MPI_SEND are not. >>> >>> - medium: All the functions in "small" plus all MPI functions that >>> take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...). All >>> one-choice-buffer functions have overloaded variants for each of >>> the MPI-supported Fortran intrinsic types up to the number of >>> dimensions specified by --with-f90-max-array-dim (default value is >>> 4). >>> >>> Increasing the size of the F90 module (in order from trivial, small, >>> and medium) will generally increase the length of time required to >>> compile user MPI applications. Specifically, "trivial"- and >>> "small"-sized F90 modules generally allow user MPI applications to >>> be compiled fairly quickly but lose type safety for all MPI >>> functions with choice buffers. "medium"-sized F90 modules generally >>> take longer to compile user applications but provide greater type >>> safety for MPI functions. >>> >>> Note that MPI func
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
What's the source code in question, then? Did you match all the arguments? On Sep 22, 2008, at 8:36 PM, Brian Harker wrote: Nope, no user-defined types or arrays greater than 2 dimensions. On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres wrote: On Sep 22, 2008, at 6:48 PM, Brian Harker wrote: when I compile my production code, I get: fortcom: Error: driver.f90: line 211: There is no matching specific subroutine for this generic subroutine call. [MPI_SEND] Seems odd that it would spit up on MPI_SEND, but has no problem with MPI_RECV... What do you guys think? And thanks again for your help and patience? The F90 MPI bindings have some well-known design flaws (i.e., problems with the standard itself, not any particular implementation). Many of them center around the fact that F90 is a strongly-typed language. See this paper for some details: http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/ Here's the highlights, as they pertain to writing F90 MPI apps: - There is no equivalent to C's (void*). This means that the F90 MPI bindings cannot accept user-defined datatypes. - This also means that *every* pre-defined type must have a F90 MPI binding. There are approximately 15 intrinsic size/type combinations. There are 50 MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying this math from the paper, and I think we got it slightly wrong (there was a discussion about it on this list a while ago), but it results in many *millions* of F90 MPI bindings functions. There's no compiler on the planet than can handle all of these in a single F90 module. Open MPI compensates for this with the following: - F90 bindings are not created for any of the 2-choice-buffer functions - F90 bindings are created for all the 1-choice-buffer functions, but only for dimensions up to N dimensions (N defaults to 4, IIRC). You can change the value of N with OMPI's configure script; use the --with-f90-max-array-dim. The maximum value of N is 7. So -- your app failed to compile because you either used a user- defined datatype or you used an array with a dimension greater than 4. If it was a greater-dimension issue, you can reconfigure/recompile/reinstall OMPI (again, sorry) with a larger N value. If it was a user-defined datatype, you unfortunately have to "include mpif.h" in that subroutine/function/whatever, sorry (and you lose the type checking). :-( Here's some info from OMPI's README: - - The Fortran 90 MPI bindings can now be built in one of three sizes using --with-mpi-f90-size=SIZE (see description below). These sizes reflect the number of MPI functions included in the "mpi" Fortran 90 module and therefore which functions will be subject to strict type checking. All functions not included in the Fortran 90 module can still be invoked from F90 applications, but will fall back to Fortran-77 style checking (i.e., little/none). - trivial: Only includes F90-specific functions from MPI-2. This means overloaded versions of MPI_SIZEOF for all the MPI-supported F90 intrinsic types. - small (default): All the functions in "trivial" plus all MPI functions that take no choice buffers (meaning buffers that are specified by the user and are of type (void*) in the C bindings -- generally buffers specified for message passing). Hence, functions like MPI_COMM_RANK are included, but functions like MPI_SEND are not. - medium: All the functions in "small" plus all MPI functions that take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...). All one-choice-buffer functions have overloaded variants for each of the MPI-supported Fortran intrinsic types up to the number of dimensions specified by --with-f90-max-array-dim (default value is 4). Increasing the size of the F90 module (in order from trivial, small, and medium) will generally increase the length of time required to compile user MPI applications. Specifically, "trivial"- and "small"-sized F90 modules generally allow user MPI applications to be compiled fairly quickly but lose type safety for all MPI functions with choice buffers. "medium"-sized F90 modules generally take longer to compile user applications but provide greater type safety for MPI functions. Note that MPI functions with two choice buffers (e.g., MPI_GATHER) are not currently included in Open MPI's F90 interface. Calls to these functions will automatically fall through to Open MPI's F77 interface. A "large" size that includes the two choice buffer MPI functions is possible in future versions of Open MPI. - FWIW, we're arguing^H^H^H^H^H^H^Hdiscussing new Fortran 2003 bindings for MPI in the MPI-3 Forum right now. We have already addressed the problems discussed above (F03 now has an equivalent of (void*)), and hope to do a few more minor things as well. There's also discussion of the possibility of a Boost.MPI-l
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
BTW, thanks for hanging in there with me on this guys. I appreciate your time and input. On Mon, Sep 22, 2008 at 6:36 PM, Brian Harker wrote: > Nope, no user-defined types or arrays greater than 2 dimensions. > > On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres wrote: >> On Sep 22, 2008, at 6:48 PM, Brian Harker wrote: >> >>> when I compile my production code, I get: >>> >>> fortcom: Error: driver.f90: line 211: There is no matching specific >>> subroutine for this generic subroutine call. [MPI_SEND] >>> >>> Seems odd that it would spit up on MPI_SEND, but has no problem with >>> MPI_RECV... What do you guys think? And thanks again for your help >>> and patience? >> >> The F90 MPI bindings have some well-known design flaws (i.e., problems with >> the standard itself, not any particular implementation). Many of them >> center around the fact that F90 is a strongly-typed language. See this >> paper for some details: >> >>http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/ >> >> Here's the highlights, as they pertain to writing F90 MPI apps: >> >> - There is no equivalent to C's (void*). This means that the F90 MPI >> bindings cannot accept user-defined datatypes. >> >> - This also means that *every* pre-defined type must have a F90 MPI binding. >> There are approximately 15 intrinsic size/type combinations. There are 50 >> MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 >> functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying this >> math from the paper, and I think we got it slightly wrong (there was a >> discussion about it on this list a while ago), but it results in many >> *millions* of F90 MPI bindings functions. There's no compiler on the planet >> than can handle all of these in a single F90 module. >> >> Open MPI compensates for this with the following: >> >> - F90 bindings are not created for any of the 2-choice-buffer functions >> - F90 bindings are created for all the 1-choice-buffer functions, but only >> for dimensions up to N dimensions (N defaults to 4, IIRC). You can change >> the value of N with OMPI's configure script; use the >> --with-f90-max-array-dim. The maximum value of N is 7. >> >> So -- your app failed to compile because you either used a user-defined >> datatype or you used an array with a dimension greater than 4. If it was a >> greater-dimension issue, you can reconfigure/recompile/reinstall OMPI >> (again, sorry) with a larger N value. If it was a user-defined datatype, >> you unfortunately have to "include mpif.h" in that >> subroutine/function/whatever, sorry (and you lose the type checking). :-( >> >> Here's some info from OMPI's README: >> >> - >> - The Fortran 90 MPI bindings can now be built in one of three sizes >> using --with-mpi-f90-size=SIZE (see description below). These sizes >> reflect the number of MPI functions included in the "mpi" Fortran 90 >> module and therefore which functions will be subject to strict type >> checking. All functions not included in the Fortran 90 module can >> still be invoked from F90 applications, but will fall back to >> Fortran-77 style checking (i.e., little/none). >> >> - trivial: Only includes F90-specific functions from MPI-2. This >>means overloaded versions of MPI_SIZEOF for all the MPI-supported >>F90 intrinsic types. >> >> - small (default): All the functions in "trivial" plus all MPI >>functions that take no choice buffers (meaning buffers that are >>specified by the user and are of type (void*) in the C bindings -- >>generally buffers specified for message passing). Hence, >>functions like MPI_COMM_RANK are included, but functions like >>MPI_SEND are not. >> >> - medium: All the functions in "small" plus all MPI functions that >>take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...). All >>one-choice-buffer functions have overloaded variants for each of >>the MPI-supported Fortran intrinsic types up to the number of >>dimensions specified by --with-f90-max-array-dim (default value is >>4). >> >> Increasing the size of the F90 module (in order from trivial, small, >> and medium) will generally increase the length of time required to >> compile user MPI applications. Specifically, "trivial"- and >> "small"-sized F90 modules generally allow user MPI applications to >> be compiled fairly quickly but lose type safety for all MPI >> functions with choice buffers. "medium"-sized F90 modules generally >> take longer to compile user applications but provide greater type >> safety for MPI functions. >> >> Note that MPI functions with two choice buffers (e.g., MPI_GATHER) >> are not currently included in Open MPI's F90 interface. Calls to >> these functions will automatically fall through to Open MPI's F77 >> interface. A "large" size that includes the two choice buffer MPI >> functions is possible in future versions of Open MPI. >> - >> >> FWIW, we're arguing^H^H^H^H^H^H^Hdiscussin
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Nope, no user-defined types or arrays greater than 2 dimensions. On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres wrote: > On Sep 22, 2008, at 6:48 PM, Brian Harker wrote: > >> when I compile my production code, I get: >> >> fortcom: Error: driver.f90: line 211: There is no matching specific >> subroutine for this generic subroutine call. [MPI_SEND] >> >> Seems odd that it would spit up on MPI_SEND, but has no problem with >> MPI_RECV... What do you guys think? And thanks again for your help >> and patience? > > The F90 MPI bindings have some well-known design flaws (i.e., problems with > the standard itself, not any particular implementation). Many of them > center around the fact that F90 is a strongly-typed language. See this > paper for some details: > >http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/ > > Here's the highlights, as they pertain to writing F90 MPI apps: > > - There is no equivalent to C's (void*). This means that the F90 MPI > bindings cannot accept user-defined datatypes. > > - This also means that *every* pre-defined type must have a F90 MPI binding. > There are approximately 15 intrinsic size/type combinations. There are 50 > MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 > functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying this > math from the paper, and I think we got it slightly wrong (there was a > discussion about it on this list a while ago), but it results in many > *millions* of F90 MPI bindings functions. There's no compiler on the planet > than can handle all of these in a single F90 module. > > Open MPI compensates for this with the following: > > - F90 bindings are not created for any of the 2-choice-buffer functions > - F90 bindings are created for all the 1-choice-buffer functions, but only > for dimensions up to N dimensions (N defaults to 4, IIRC). You can change > the value of N with OMPI's configure script; use the > --with-f90-max-array-dim. The maximum value of N is 7. > > So -- your app failed to compile because you either used a user-defined > datatype or you used an array with a dimension greater than 4. If it was a > greater-dimension issue, you can reconfigure/recompile/reinstall OMPI > (again, sorry) with a larger N value. If it was a user-defined datatype, > you unfortunately have to "include mpif.h" in that > subroutine/function/whatever, sorry (and you lose the type checking). :-( > > Here's some info from OMPI's README: > > - > - The Fortran 90 MPI bindings can now be built in one of three sizes > using --with-mpi-f90-size=SIZE (see description below). These sizes > reflect the number of MPI functions included in the "mpi" Fortran 90 > module and therefore which functions will be subject to strict type > checking. All functions not included in the Fortran 90 module can > still be invoked from F90 applications, but will fall back to > Fortran-77 style checking (i.e., little/none). > > - trivial: Only includes F90-specific functions from MPI-2. This >means overloaded versions of MPI_SIZEOF for all the MPI-supported >F90 intrinsic types. > > - small (default): All the functions in "trivial" plus all MPI >functions that take no choice buffers (meaning buffers that are >specified by the user and are of type (void*) in the C bindings -- >generally buffers specified for message passing). Hence, >functions like MPI_COMM_RANK are included, but functions like >MPI_SEND are not. > > - medium: All the functions in "small" plus all MPI functions that >take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...). All >one-choice-buffer functions have overloaded variants for each of >the MPI-supported Fortran intrinsic types up to the number of >dimensions specified by --with-f90-max-array-dim (default value is >4). > > Increasing the size of the F90 module (in order from trivial, small, > and medium) will generally increase the length of time required to > compile user MPI applications. Specifically, "trivial"- and > "small"-sized F90 modules generally allow user MPI applications to > be compiled fairly quickly but lose type safety for all MPI > functions with choice buffers. "medium"-sized F90 modules generally > take longer to compile user applications but provide greater type > safety for MPI functions. > > Note that MPI functions with two choice buffers (e.g., MPI_GATHER) > are not currently included in Open MPI's F90 interface. Calls to > these functions will automatically fall through to Open MPI's F77 > interface. A "large" size that includes the two choice buffer MPI > functions is possible in future versions of Open MPI. > - > > FWIW, we're arguing^H^H^H^H^H^H^Hdiscussing new Fortran 2003 bindings for > MPI in the MPI-3 Forum right now. We have already addressed the problems > discussed above (F03 now has an equivalent of (void*)), and hope to do a few > more minor things as well. There's also discussion of
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
On Sep 22, 2008, at 6:48 PM, Brian Harker wrote: when I compile my production code, I get: fortcom: Error: driver.f90: line 211: There is no matching specific subroutine for this generic subroutine call. [MPI_SEND] Seems odd that it would spit up on MPI_SEND, but has no problem with MPI_RECV... What do you guys think? And thanks again for your help and patience? The F90 MPI bindings have some well-known design flaws (i.e., problems with the standard itself, not any particular implementation). Many of them center around the fact that F90 is a strongly-typed language. See this paper for some details: http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/ Here's the highlights, as they pertain to writing F90 MPI apps: - There is no equivalent to C's (void*). This means that the F90 MPI bindings cannot accept user-defined datatypes. - This also means that *every* pre-defined type must have a F90 MPI binding. There are approximately 15 intrinsic size/type combinations. There are 50 MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying this math from the paper, and I think we got it slightly wrong (there was a discussion about it on this list a while ago), but it results in many *millions* of F90 MPI bindings functions. There's no compiler on the planet than can handle all of these in a single F90 module. Open MPI compensates for this with the following: - F90 bindings are not created for any of the 2-choice-buffer functions - F90 bindings are created for all the 1-choice-buffer functions, but only for dimensions up to N dimensions (N defaults to 4, IIRC). You can change the value of N with OMPI's configure script; use the --with- f90-max-array-dim. The maximum value of N is 7. So -- your app failed to compile because you either used a user- defined datatype or you used an array with a dimension greater than 4. If it was a greater-dimension issue, you can reconfigure/recompile/ reinstall OMPI (again, sorry) with a larger N value. If it was a user- defined datatype, you unfortunately have to "include mpif.h" in that subroutine/function/whatever, sorry (and you lose the type checking). :-( Here's some info from OMPI's README: - - The Fortran 90 MPI bindings can now be built in one of three sizes using --with-mpi-f90-size=SIZE (see description below). These sizes reflect the number of MPI functions included in the "mpi" Fortran 90 module and therefore which functions will be subject to strict type checking. All functions not included in the Fortran 90 module can still be invoked from F90 applications, but will fall back to Fortran-77 style checking (i.e., little/none). - trivial: Only includes F90-specific functions from MPI-2. This means overloaded versions of MPI_SIZEOF for all the MPI-supported F90 intrinsic types. - small (default): All the functions in "trivial" plus all MPI functions that take no choice buffers (meaning buffers that are specified by the user and are of type (void*) in the C bindings -- generally buffers specified for message passing). Hence, functions like MPI_COMM_RANK are included, but functions like MPI_SEND are not. - medium: All the functions in "small" plus all MPI functions that take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...). All one-choice-buffer functions have overloaded variants for each of the MPI-supported Fortran intrinsic types up to the number of dimensions specified by --with-f90-max-array-dim (default value is 4). Increasing the size of the F90 module (in order from trivial, small, and medium) will generally increase the length of time required to compile user MPI applications. Specifically, "trivial"- and "small"-sized F90 modules generally allow user MPI applications to be compiled fairly quickly but lose type safety for all MPI functions with choice buffers. "medium"-sized F90 modules generally take longer to compile user applications but provide greater type safety for MPI functions. Note that MPI functions with two choice buffers (e.g., MPI_GATHER) are not currently included in Open MPI's F90 interface. Calls to these functions will automatically fall through to Open MPI's F77 interface. A "large" size that includes the two choice buffer MPI functions is possible in future versions of Open MPI. - FWIW, we're arguing^H^H^H^H^H^H^Hdiscussing new Fortran 2003 bindings for MPI in the MPI-3 Forum right now. We have already addressed the problems discussed above (F03 now has an equivalent of (void*)), and hope to do a few more minor things as well. There's also discussion of the possibility of a Boost.MPI-like Fortran 2003 MPI library that would take advantage of many of the features of the language, but be a little farther away from the official MPI bindings (see www.boost-
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Gus- Thanks for the idea. One question: how do you position INCLUDE statements in a fortran program, because if I just straight substitute ' INCLUDE "mpif.h" ' for ' USE mpi ', I get a lot of crap telling me my other USE statements are not positioned correctly within the scope and nothing compiles. I have tried various positions, but I seem to be suffering from a lot of BS. Am I overlooking something very obvious? On Mon, Sep 22, 2008 at 5:42 PM, Gus Correa wrote: > Hi Brian and list > > I seldom used the "use mpi" syntax before. > I have a lot of code here written in Fortran 90, > but and mpif.h is included instead "use mpi". > The MPI function calls are the same in Fortran 77 and Fortran 90 syntax, > hence there is just one line of code to change, if one wants to go fully > F90. > All works well, though. > This style is a legacy from the times when the Fortran90 interface of MPI > was not fully developed, > and the mpi.mod was broken most of the time. > That is no longer the case, though. > > This mixed mode may be one way around your problem, although not ideal. > The main drawback of using the "include mpif.h" syntax > is that there is no parameter checking of the MPI function calls, > whereas the "use mpi" syntax provide some level of parameter checking > through the mpi.mod module. > If you are careful when you write your MPI calls, > and check if all parameters match the syntax requirements strictly, > this shouldn't be a problem, though. > (Nevertheless, a few days ago somebody was suffering here on the list with a > problem that was just > a missing "ierr" parameter in an MPI_Send call. Jeff found it out, after > several emails back and forth.) > > If not for anything else, just for the fun of it, to see how far the > compilation goes, > I would comment out "use mpi" and replace it by "include mpif.h". > > As for architecture and compiler, I have used with no problem OpenMPI (and > MPICH2 and MPICH-1) on various > x86 and x86_64 machines, both AMD and Intel, under different Linux flavors > (Fedora, CentOS, Red Hat), > in standalone machines (using SMP and shared memory), > and on a small cluster using Ethernet 100T , then using Gigabit Ethernet, > compiling it with gcc and ifort and with gcc and pgf90. > > Note that I don't have icc, I use gcc and g++. > Are the icc and ifort versions that you have the same? > I don't know if different versions may not mix well, but it is a > possibility. > > I tried to reproduce your problem by writing a simple hello_f90.f90 program, > with the "use mpi" syntax, > and compiling it with the OpenMPI mpif90. > However, the program compiled without any problem, > and I didn't need to point to the mpi.mod directory using the "-module" flag > either, > despite my having a "gfortran-openmpi" version of mpi.mod in > /usr/lib/openmpi/. > The program runs fine too, with 2 processes, 4 processes, etc. > > On your first message on this thread, your configure command declares > environment > variables for CC, CXX, F77, and FC without full paths. > I wonder if there is any chance that there are multiple versions of Intel > compilers on your > system, that somehow may be the cause for the confusion (perhaps as early as > the build time). > > Also, note that mpi.mod is not an include file. > It is located in the lib directory of openmpi. > There was some confusion about this before, with a discussion about "-I" > directories, etc, > but hopefully this was clarified already. > > Another thing to check is if there is any funny compiler configuration (say > in /opt/intel/fc/bla/bla/ifort.cfg). > > Yet another thing I would look at are the logs for OpenMPI configure, make, > and make install, > if you saved them, to see if the Fortran90 interface was built to > completion. > > Also, a suggestion is to compile with the verbose "-v" option, to see if it > spits out some > clue to what is going on. > I hope this helps. > > Gus Correa > (from the stamp-collecting side of science :) ) > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > >> Hi guys- >> >> Still no dice. The only mpi.mod files I have are the ones generated >> from my compile and build from source (and they are where they should >> be), so there's definitely no confusion amongst the modules. And >> specifying the fulls path to the correct mpi.mod module (like Gus >> suggested with the -module option) gives no change. I am running out >> of ideas and patience, as I'm sure you all are too! Perhaps openMPI >> just doesn't play nice with my compiler suite and hardware >> architecture...? Thanks for all the input! >> >> On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa >> wrote: >> >>> >>> Hi Brian and list >>
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
On Sep 22, 2008, at 6:21 PM, Doug Reeder wrote: I think that unless make all depends on make clean and make clean depends on Makefile, you have to manually run make clean and/or manually delete the module files. We do have most everything in the code base that matters depend on opal_config.h, which is generated by configure. I think it's unexpected behavior if you run configure a 2nd time (assumedly with different options) and don't have everything re-built properly. Sorry for the hassle Brian; I'll file a bug about this. I don't expect it'll be fixed in the 1.2 series and possibly not for v1.3.0, but certainly in some future release. -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Brian and list I seldom used the "use mpi" syntax before. I have a lot of code here written in Fortran 90, but and mpif.h is included instead "use mpi". The MPI function calls are the same in Fortran 77 and Fortran 90 syntax, hence there is just one line of code to change, if one wants to go fully F90. All works well, though. This style is a legacy from the times when the Fortran90 interface of MPI was not fully developed, and the mpi.mod was broken most of the time. That is no longer the case, though. This mixed mode may be one way around your problem, although not ideal. The main drawback of using the "include mpif.h" syntax is that there is no parameter checking of the MPI function calls, whereas the "use mpi" syntax provide some level of parameter checking through the mpi.mod module. If you are careful when you write your MPI calls, and check if all parameters match the syntax requirements strictly, this shouldn't be a problem, though. (Nevertheless, a few days ago somebody was suffering here on the list with a problem that was just a missing "ierr" parameter in an MPI_Send call. Jeff found it out, after several emails back and forth.) If not for anything else, just for the fun of it, to see how far the compilation goes, I would comment out "use mpi" and replace it by "include mpif.h". As for architecture and compiler, I have used with no problem OpenMPI (and MPICH2 and MPICH-1) on various x86 and x86_64 machines, both AMD and Intel, under different Linux flavors (Fedora, CentOS, Red Hat), in standalone machines (using SMP and shared memory), and on a small cluster using Ethernet 100T , then using Gigabit Ethernet, compiling it with gcc and ifort and with gcc and pgf90. Note that I don't have icc, I use gcc and g++. Are the icc and ifort versions that you have the same? I don't know if different versions may not mix well, but it is a possibility. I tried to reproduce your problem by writing a simple hello_f90.f90 program, with the "use mpi" syntax, and compiling it with the OpenMPI mpif90. However, the program compiled without any problem, and I didn't need to point to the mpi.mod directory using the "-module" flag either, despite my having a "gfortran-openmpi" version of mpi.mod in /usr/lib/openmpi/. The program runs fine too, with 2 processes, 4 processes, etc. On your first message on this thread, your configure command declares environment variables for CC, CXX, F77, and FC without full paths. I wonder if there is any chance that there are multiple versions of Intel compilers on your system, that somehow may be the cause for the confusion (perhaps as early as the build time). Also, note that mpi.mod is not an include file. It is located in the lib directory of openmpi. There was some confusion about this before, with a discussion about "-I" directories, etc, but hopefully this was clarified already. Another thing to check is if there is any funny compiler configuration (say in /opt/intel/fc/bla/bla/ifort.cfg). Yet another thing I would look at are the logs for OpenMPI configure, make, and make install, if you saved them, to see if the Fortran90 interface was built to completion. Also, a suggestion is to compile with the verbose "-v" option, to see if it spits out some clue to what is going on. I hope this helps. Gus Correa (from the stamp-collecting side of science :) ) -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: Hi guys- Still no dice. The only mpi.mod files I have are the ones generated from my compile and build from source (and they are where they should be), so there's definitely no confusion amongst the modules. And specifying the fulls path to the correct mpi.mod module (like Gus suggested with the -module option) gives no change. I am running out of ideas and patience, as I'm sure you all are too! Perhaps openMPI just doesn't play nice with my compiler suite and hardware architecture...? Thanks for all the input! On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa wrote: Hi Brian and list I read your original posting and Jeff's answers. Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, compiled with gfortran. Note that I don't even have gfortran installed! This is besides the MPI versions (MPICH2 and OpenMPI) I installed from scratch using combinations of ifort and pgi with gcc. It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. Something like this may be part of your problem. A "locate mpi.mod" should show what your system has. Have you tried to force the directory where mpi.mod is searched for? Something like this: /full/path/to/openmpi/bin/mpif90 -module /full/path/to/openmpi_m
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
I humbly bow before my MPI masters! Thank you guys! make clean && make all install seemed to fix it. The example code compiles and runs fine...but... when I compile my production code, I get: fortcom: Error: driver.f90: line 211: There is no matching specific subroutine for this generic subroutine call. [MPI_SEND] Seems odd that it would spit up on MPI_SEND, but has no problem with MPI_RECV... What do you guys think? And thanks again for your help and patience? On Mon, Sep 22, 2008 at 4:21 PM, Doug Reeder wrote: > Jeff, > > I think that unless make all depends on make clean and make clean depends on > Makefile, you have to manually run make clean and/or manually delete the > module files. > > Doug Reeder > On Sep 22, 2008, at 3:16 PM, Jeff Squyres wrote: > >> On Sep 22, 2008, at 6:08 PM, Brian Harker wrote: >> >>> Here's the config.log file...now that I look through it more >>> carefully, I see some errors that I didn't see when watching >>> ./configure scroll by...still don't know what to do though. :( >> >> Not to worry; there are many tests in configure that are designed to fail. >> So it's not a problem to see lots of failures in config.log. >> >> I see that it did use ifort for both the F77 and F90 compilers; that's >> what I wanted to check with configure output and config.log. >> >> Per Doug's comment, if OMPI is not re-compiling the Fortran module when >> you reconfigure with a new fortran compiler, that is likely a bug. Can you >> "make clean all install" and see if it works? If not, send all the output >> here (see http://www.open-mpi.org/community/help/ for instructions; please >> compress). >> >> -- >> Jeff Squyres >> Cisco Systems >> >> ___ >> users mailing list >> us...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/users > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Jeff, I think that unless make all depends on make clean and make clean depends on Makefile, you have to manually run make clean and/or manually delete the module files. Doug Reeder On Sep 22, 2008, at 3:16 PM, Jeff Squyres wrote: On Sep 22, 2008, at 6:08 PM, Brian Harker wrote: Here's the config.log file...now that I look through it more carefully, I see some errors that I didn't see when watching ./configure scroll by...still don't know what to do though. :( Not to worry; there are many tests in configure that are designed to fail. So it's not a problem to see lots of failures in config.log. I see that it did use ifort for both the F77 and F90 compilers; that's what I wanted to check with configure output and config.log. Per Doug's comment, if OMPI is not re-compiling the Fortran module when you reconfigure with a new fortran compiler, that is likely a bug. Can you "make clean all install" and see if it works? If not, send all the output here (see http://www.open-mpi.org/ community/help/ for instructions; please compress). -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
On Sep 22, 2008, at 6:08 PM, Brian Harker wrote: Here's the config.log file...now that I look through it more carefully, I see some errors that I didn't see when watching ./configure scroll by...still don't know what to do though. :( Not to worry; there are many tests in configure that are designed to fail. So it's not a problem to see lots of failures in config.log. I see that it did use ifort for both the F77 and F90 compilers; that's what I wanted to check with configure output and config.log. Per Doug's comment, if OMPI is not re-compiling the Fortran module when you reconfigure with a new fortran compiler, that is likely a bug. Can you "make clean all install" and see if it works? If not, send all the output here (see http://www.open-mpi.org/community/help/ for instructions; please compress). -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Brian, Try doing a make clean before doing the build with your new make file (from the new configure process). It looks like you are getting the leftover module files from the old makefile/compilers. Doug reeder On Sep 22, 2008, at 2:52 PM, Brian Harker wrote: Ok, here's something funny/weird/stupid: Looking at the actual mpi.mod module file in the $OPENMPI_HOME/lib directory, the very first line is: GFORTRAN module created from mpi.f90 on Fri Sep 19 14:01:27 2008 WTF!? I specified that I wanted to use the ifort/icc/icpc compiler suite when I installed (see my first post)! Why would it create the module with gfortran? This would seem to be the source of my troubles... On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa wrote: Hi Brian and list I read your original posting and Jeff's answers. Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, compiled with gfortran. Note that I don't even have gfortran installed! This is besides the MPI versions (MPICH2 and OpenMPI) I installed from scratch using combinations of ifort and pgi with gcc. It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. Something like this may be part of your problem. A "locate mpi.mod" should show what your system has. Have you tried to force the directory where mpi.mod is searched for? Something like this: /full/path/to/openmpi/bin/mpif90 -module /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 The ifort man pages has the "-module" syntax details. I hope this helps. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: Hi Gus- Thanks for the input. I have been using full path names to both the wrapper compilers and mpiexec from the first day I had two MPI implementations on my machine, depending on if I want to use MPICH or openMPI, but still the problem remains. ARGG! On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: Hello Brian and list My confusing experiences with multiple MPI implementations were fixed the day I decided to use full path names to the MPI compiler wrappers (mpicc, mpif77, etc) at compile time, and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, and to do this in a consistent fashion (using the tools from the same install to compile and to run the programs). Most Linux distributions come with built in MPI implementations (often times more than one), and so do commercial compilers and other tools. You end up with a mess of different MPI versions on your "native" PATH, as well as variety of bin, lib, and include directories containing different MPI stuff. The easy way around is to use full path names, particularly if you install yet another MPI implementation from scratch. Another way is to fix your PATH on your initialization files (.cshrc, etc) to point to your preferred implementation (put the appropriate bin directory ahead of everything else). Yet another is to install the "environment modules" package on your system and use it consistently. My two cents. Gus Correa -- --- -- Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA --- -- Brian Harker wrote: I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re- install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is fin
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Here's the config.log file...now that I look through it more carefully, I see some errors that I didn't see when watching ./configure scroll by...still don't know what to do though. :( Thanks! On Mon, Sep 22, 2008 at 3:54 PM, Jeff Squyres wrote: > Good question. Can you send the full stdout/stderr output from configure > and config.log? > > (please compress) > > > On Sep 22, 2008, at 5:52 PM, Brian Harker wrote: > >> Ok, here's something funny/weird/stupid: >> >> Looking at the actual mpi.mod module file in the $OPENMPI_HOME/lib >> directory, the very first line is: >> GFORTRAN module created from mpi.f90 on Fri Sep 19 14:01:27 2008 >> >> WTF!? I specified that I wanted to use the ifort/icc/icpc compiler >> suite when I installed (see my first post)! Why would it create the >> module with gfortran? This would seem to be the source of my >> troubles... >> >> >> >> On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa >> wrote: >>> >>> Hi Brian and list >>> >>> I read your original posting and Jeff's answers. >>> >>> Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a >>> mpi.mod, >>> compiled with gfortran. >>> Note that I don't even have gfortran installed! >>> This is besides the MPI versions (MPICH2 and OpenMPI) >>> I installed from scratch using combinations of ifort and pgi with gcc. >>> It may be that mpif90 is not picking the right mpi.mod, as Jeff >>> suggested. >>> Something like this may be part of your problem. >>> A "locate mpi.mod" should show what your system has. >>> >>> Have you tried to force the directory where mpi.mod is searched for? >>> Something like this: >>> >>> /full/path/to/openmpi/bin/mpif90 -module >>> /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 >>> >>> The ifort man pages has the "-module" syntax details. >>> >>> I hope this helps. >>> >>> Gus Correa >>> >>> -- >>> - >>> Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu >>> Lamont-Doherty Earth Observatory - Columbia University >>> P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA >>> - >>> >>> >>> Brian Harker wrote: >>> Hi Gus- Thanks for the input. I have been using full path names to both the wrapper compilers and mpiexec from the first day I had two MPI implementations on my machine, depending on if I want to use MPICH or openMPI, but still the problem remains. ARGG! On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: > > Hello Brian and list > > My confusing experiences with multiple MPI implementations > were fixed the day I decided to use full path names to the MPI compiler > wrappers (mpicc, mpif77, etc) at compile time, > and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, > and to do this in a consistent fashion (using the tools from the same > install to compile and to run the programs). > > Most Linux distributions come with built in MPI implementations (often > times > more than one), > and so do commercial compilers and other tools. > You end up with a mess of different MPI versions on your "native" PATH, > as well as variety of bin, lib, and include directories containing > different > MPI stuff. > The easy way around is to use full path names, particularly if you > install > yet another MPI implementation > from scratch. > Another way is to fix your PATH on your initialization files (.cshrc, > etc) > to point to your preferred implementation (put the appropriate bin > directory > ahead of everything else). > Yet another is to install the "environment modules" package on your > system > and use it consistently. > > My two cents. > > Gus Correa > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > > >> >> I built and installed both MPICH2 and openMPI from source, so no >> distribution packages or anything. MPICH2 has the modules located in >> /usr/local/include, which I assume would be found (since its in my >> path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, >> right? I can't imagine that if you tell it where to look for the >> correct modules, it would search through your path first before going >> to where you tell it to go. Or am I too optimistic? Thanks again for >> the input! >> >> On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres >> wrote: >> >> >>> >>> On Sep 22, 2008, at 10:10 AM
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Good question. Can you send the full stdout/stderr output from configure and config.log? (please compress) On Sep 22, 2008, at 5:52 PM, Brian Harker wrote: Ok, here's something funny/weird/stupid: Looking at the actual mpi.mod module file in the $OPENMPI_HOME/lib directory, the very first line is: GFORTRAN module created from mpi.f90 on Fri Sep 19 14:01:27 2008 WTF!? I specified that I wanted to use the ifort/icc/icpc compiler suite when I installed (see my first post)! Why would it create the module with gfortran? This would seem to be the source of my troubles... On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa wrote: Hi Brian and list I read your original posting and Jeff's answers. Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, compiled with gfortran. Note that I don't even have gfortran installed! This is besides the MPI versions (MPICH2 and OpenMPI) I installed from scratch using combinations of ifort and pgi with gcc. It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. Something like this may be part of your problem. A "locate mpi.mod" should show what your system has. Have you tried to force the directory where mpi.mod is searched for? Something like this: /full/path/to/openmpi/bin/mpif90 -module /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 The ifort man pages has the "-module" syntax details. I hope this helps. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: Hi Gus- Thanks for the input. I have been using full path names to both the wrapper compilers and mpiexec from the first day I had two MPI implementations on my machine, depending on if I want to use MPICH or openMPI, but still the problem remains. ARGG! On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: Hello Brian and list My confusing experiences with multiple MPI implementations were fixed the day I decided to use full path names to the MPI compiler wrappers (mpicc, mpif77, etc) at compile time, and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, and to do this in a consistent fashion (using the tools from the same install to compile and to run the programs). Most Linux distributions come with built in MPI implementations (often times more than one), and so do commercial compilers and other tools. You end up with a mess of different MPI versions on your "native" PATH, as well as variety of bin, lib, and include directories containing different MPI stuff. The easy way around is to use full path names, particularly if you install yet another MPI implementation from scratch. Another way is to fix your PATH on your initialization files (.cshrc, etc) to point to your preferred implementation (put the appropriate bin directory ahead of everything else). Yet another is to install the "environment modules" package on your system and use it consistently. My two cents. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re- install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is finding first? E.g., in your MPICH2 installation? Or is Open MPI installed by your distro, perchance? You might
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Ok, here's something funny/weird/stupid: Looking at the actual mpi.mod module file in the $OPENMPI_HOME/lib directory, the very first line is: GFORTRAN module created from mpi.f90 on Fri Sep 19 14:01:27 2008 WTF!? I specified that I wanted to use the ifort/icc/icpc compiler suite when I installed (see my first post)! Why would it create the module with gfortran? This would seem to be the source of my troubles... On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa wrote: > Hi Brian and list > > I read your original posting and Jeff's answers. > > Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, > compiled with gfortran. > Note that I don't even have gfortran installed! > This is besides the MPI versions (MPICH2 and OpenMPI) > I installed from scratch using combinations of ifort and pgi with gcc. > It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. > Something like this may be part of your problem. > A "locate mpi.mod" should show what your system has. > > Have you tried to force the directory where mpi.mod is searched for? > Something like this: > > /full/path/to/openmpi/bin/mpif90 -module > /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 > > The ifort man pages has the "-module" syntax details. > > I hope this helps. > > Gus Correa > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > >> Hi Gus- >> >> Thanks for the input. I have been using full path names to both the >> wrapper compilers and mpiexec from the first day I had two MPI >> implementations on my machine, depending on if I want to use MPICH or >> openMPI, but still the problem remains. ARGG! >> >> On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: >> >>> >>> Hello Brian and list >>> >>> My confusing experiences with multiple MPI implementations >>> were fixed the day I decided to use full path names to the MPI compiler >>> wrappers (mpicc, mpif77, etc) at compile time, >>> and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, >>> and to do this in a consistent fashion (using the tools from the same >>> install to compile and to run the programs). >>> >>> Most Linux distributions come with built in MPI implementations (often >>> times >>> more than one), >>> and so do commercial compilers and other tools. >>> You end up with a mess of different MPI versions on your "native" PATH, >>> as well as variety of bin, lib, and include directories containing >>> different >>> MPI stuff. >>> The easy way around is to use full path names, particularly if you >>> install >>> yet another MPI implementation >>> from scratch. >>> Another way is to fix your PATH on your initialization files (.cshrc, >>> etc) >>> to point to your preferred implementation (put the appropriate bin >>> directory >>> ahead of everything else). >>> Yet another is to install the "environment modules" package on your >>> system >>> and use it consistently. >>> >>> My two cents. >>> >>> Gus Correa >>> >>> -- >>> - >>> Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu >>> Lamont-Doherty Earth Observatory - Columbia University >>> P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA >>> - >>> >>> >>> Brian Harker wrote: >>> >>> I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: > > On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: > > > >> >> Thanks for the reply...crap, $HOME/openmpi/lib does contains all the >> various lilbmpi* files as well as mpi.mod, >> >> > > That should be correct. > > > >> >> but still get the same >> error at compile-time. Yes, I made sure to specifically build openMPI >> with ifort 10.1.012, and did run the --showme command right after >> installation to make sure the wrapper compiler was using ifort as >> well. >> >> > > Ok, good. > > > >> >> Before posting to this mailing list, I did uninstall and re-install >> openMPI several times to make su
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi guys- Still no dice. The only mpi.mod files I have are the ones generated from my compile and build from source (and they are where they should be), so there's definitely no confusion amongst the modules. And specifying the fulls path to the correct mpi.mod module (like Gus suggested with the -module option) gives no change. I am running out of ideas and patience, as I'm sure you all are too! Perhaps openMPI just doesn't play nice with my compiler suite and hardware architecture...? Thanks for all the input! On Mon, Sep 22, 2008 at 11:27 AM, Gus Correa wrote: > Hi Brian and list > > I read your original posting and Jeff's answers. > > Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, > compiled with gfortran. > Note that I don't even have gfortran installed! > This is besides the MPI versions (MPICH2 and OpenMPI) > I installed from scratch using combinations of ifort and pgi with gcc. > It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. > Something like this may be part of your problem. > A "locate mpi.mod" should show what your system has. > > Have you tried to force the directory where mpi.mod is searched for? > Something like this: > > /full/path/to/openmpi/bin/mpif90 -module > /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 > > The ifort man pages has the "-module" syntax details. > > I hope this helps. > > Gus Correa > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > >> Hi Gus- >> >> Thanks for the input. I have been using full path names to both the >> wrapper compilers and mpiexec from the first day I had two MPI >> implementations on my machine, depending on if I want to use MPICH or >> openMPI, but still the problem remains. ARGG! >> >> On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: >> >>> >>> Hello Brian and list >>> >>> My confusing experiences with multiple MPI implementations >>> were fixed the day I decided to use full path names to the MPI compiler >>> wrappers (mpicc, mpif77, etc) at compile time, >>> and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, >>> and to do this in a consistent fashion (using the tools from the same >>> install to compile and to run the programs). >>> >>> Most Linux distributions come with built in MPI implementations (often >>> times >>> more than one), >>> and so do commercial compilers and other tools. >>> You end up with a mess of different MPI versions on your "native" PATH, >>> as well as variety of bin, lib, and include directories containing >>> different >>> MPI stuff. >>> The easy way around is to use full path names, particularly if you >>> install >>> yet another MPI implementation >>> from scratch. >>> Another way is to fix your PATH on your initialization files (.cshrc, >>> etc) >>> to point to your preferred implementation (put the appropriate bin >>> directory >>> ahead of everything else). >>> Yet another is to install the "environment modules" package on your >>> system >>> and use it consistently. >>> >>> My two cents. >>> >>> Gus Correa >>> >>> -- >>> - >>> Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu >>> Lamont-Doherty Earth Observatory - Columbia University >>> P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA >>> - >>> >>> >>> Brian Harker wrote: >>> >>> I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: > > On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: > > > >> >> Thanks for the reply...crap, $HOME/openmpi/lib does contains all the >> various lilbmpi* files as well as mpi.mod, >> >> > > That should be correct. > > > >> >> but still get the same >> error at compile-time. Yes, I made sure to specifically build openMPI >> with ifort 10.1.012, and did run the --showme command right after >> installation to make sure the wrapper compiler was using ifort as >> well. >> >> > > Ok, good. > > > >> >> Before
Re: [OMPI users] Mpirun don't execute
Exactly what version of Open MPI are you using? You mentioned "1.3" -- did you download a nightly tarball at some point, or do you have an SVN checkout? Since you have a development copy of Open MPI, it is possible that your copy is simply broken (sorry; we *do* break the development head every once in a while...). Can you update? Note that Josh just made some FT fixes on the trunk today that aren't on the v1.3 branch yet; they'll likely take a day or three to get there. On Sep 22, 2008, at 5:03 PM, Santolo Felaco wrote: Hi, this is my openmpi-default-hostfile: 127.0.0.1 slots=2 If I invoke comand CTRL+C the application is not killed. With mpirun -np 1 uptime the comand is ever blocked. The comand is blocked with any comand, also comands not existent. Thanks. 2008/9/22 Jeff Squyres On Sep 19, 2008, at 6:50 PM, Santolo Felaco wrote: Hi, I try to be clearer: osa@libertas:~$ echo $LD_LIBRARY_PATH /usr/local/lib:/home/osa/blcr/lib osa@libertas:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ games:/home/osa/blcr/bin I compile the file with mpicc, then: osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 The comand is blocked. Don't run. CTRL+X does not end the program. Try ctrl-c -- that's usually the way to kill applications that appear to have been hung. This is ps output: osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 & [1] 6151 osa@libertas:~/prove/openmpi$ ps PID TTY TIME CMD 6135 pts/200:00:00 bash 6151 pts/200:00:00 mpirun 6153 pts/200:00:00 ssh 6161 pts/200:00:00 ps What is your program doing? Can you tell if it's getting past MPI_INIT, or even launching at all? Can you mpirun non-MPI applications, such as "hostname" and "uptime"? Are you launching this es1 application locally or remotely? From your command line and previous description, I *assume* that it's local, but I see an "ssh" in your ps output, possibly meaning that mpirun has launched the application remotely (e.g., if you specified a default hostfile or somesuch). -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users -- Jeff Squyres Cisco Systems
Re: [OMPI users] Mpirun don't execute
Hi, this is my openmpi-default-hostfile: 127.0.0.1 slots=2 If I invoke comand CTRL+C the application is not killed. With mpirun -np 1 uptime the comand is ever blocked. The comand is blocked with any comand, also comands not existent. Thanks. 2008/9/22 Jeff Squyres > On Sep 19, 2008, at 6:50 PM, Santolo Felaco wrote: > > Hi, I try to be clearer: >> osa@libertas:~$ echo $LD_LIBRARY_PATH >> /usr/local/lib:/home/osa/blcr/lib >> osa@libertas:~$ echo $PATH >> >> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/osa/blcr/bin >> >> I compile the file with mpicc, then: >> osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 >> >> The comand is blocked. Don't run. CTRL+X does not end the program. >> > > Try ctrl-c -- that's usually the way to kill applications that appear to > have been hung. > > This is ps output: >> >> osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 & >> [1] 6151 >> osa@libertas:~/prove/openmpi$ ps >> PID TTY TIME CMD >> 6135 pts/200:00:00 bash >> 6151 pts/200:00:00 mpirun >> 6153 pts/200:00:00 ssh >> 6161 pts/200:00:00 ps >> > > > What is your program doing? Can you tell if it's getting past MPI_INIT, or > even launching at all? Can you mpirun non-MPI applications, such as > "hostname" and "uptime"? > > Are you launching this es1 application locally or remotely? From your > command line and previous description, I *assume* that it's local, but I see > an "ssh" in your ps output, possibly meaning that mpirun has launched the > application remotely (e.g., if you specified a default hostfile or > somesuch). > > > -- > Jeff Squyres > Cisco Systems > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users >
Re: [OMPI users] BLCR not found
I have committed a patch (r19607) to clean up the BLCR configure logic. It should be in tonight's tarball of the trunk. I've requested that this fix be moved to v1.3, but that is going to take a day or so to process. This patch adds a new configure option '--with-blcr-libdir' which lets you specify the directory in which the BLCR libraries are installed. So something like the following may work for you: ./configure --with-ft=cr --enable-ft-thread --enable-mpi-threads \ --with-blcr=/home/osa/blcr/ --with-blcr-libdir=/home/osa/blcr/lib Let me know if that fixes your configure problem. Cheers, Josh On Sep 18, 2008, at 6:57 AM, Santolo Felaco wrote: Ok, Thanks. 2008/9/17 Josh Hursey It looks like the configure script is picking up the wrong lib- directory (/home/osa/blcr/lib64 instead of /home/osa/blcr/lib): gcc -o conftest -O3 -DNDEBUG -finline-functions -fno-strict- aliasing -pthread \ -I/home/osa/blcr/include -L/home/osa/blcr/lib64 \ conftest.c -lcr -lnsl -lutil -lm /usr/bin/ld: cannot find -lcr I'll try to reproduce and work up a patch. In the mean time you may check to make sure that the BLCR path is set correctly in your $PATH and $LD_LIBRARY_PATH. Josh On Sep 17, 2008, at 7:44 AM, Santolo Felaco wrote: This is the zipped file config.log 2008/9/17 Josh Hursey Can you send me a zip'ed up version of the config.log from your build? That will help in determining what went wrong with configure. Cheers, Josh On Sep 17, 2008, at 6:09 AM, Santolo Felaco wrote: Hi, I want to install openmpi-1.3. I have invoked ./configure --with- ft=cr --enable-ft-thread --enable-mpi-threads --with-blcr=/home/osa/ blcr/ --enable-progress-threads This is error message that show: BLCR support requested but not found. Perhaps you need to specify the location of the BLCR libraries. I have installed blcr in /home/osa/blcr, I report the list of directory blcr: .: bin include lib libexec man ./bin: cr_checkpoint cr_restart cr_run ./include: blcr_common.h blcr_errcodes.h blcr_ioctl.h blcr_proc.h libcr.h ./lib: blcr libcr_omit.la libcr_omit.so.0 libcr_run.la libcr_run.so.0 libcr.solibcr.so.0.4.1 libcr.la libcr_omit.so libcr_omit.so.0.4.1 libcr_run.so libcr_run.so.0.4.1 libcr.so.0 ./lib/blcr: 2.6.24-16-generic ./lib/blcr/2.6.24-16-generic: blcr_imports.ko blcr.ko blcr_vmadump.ko ./libexec: ./man: man1 ./man/man1: cr_checkpoint.1 cr_restart.1 cr_run.1 Help me, please ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] conflict among differenv MPIs
On Sep 22, 2008, at 2:48 PM, Shafagh Jafer wrote:
I am not using any of the files that exist in /usr/local/include,
this doesn't even show on my PATH and my mpicc -show tells that the
openmpi path is correct.
/usr/local/include is likely a default include path from the
compiler. So even if you don't reference it directly, the compiler
may still be using files from there. It *shouldn't*, if the same file
exists in /opt/openmpi*/include and /usr/local/include/*, but there
seems to be some confusion on your machine.
Note that include directories have nothing to do with your PATH.
I dont know what to do, I have contacted the technician to hide or
delete /usr/local/include...Millions of thanks for ur replies and
patience. I'll keep you updated!
Don't just move or hide /usr/local/include -- that will likely break
things. Just uninstall MPICH from /usr/local and re-install it
somewhere else.
Good luck.
--- On Mon, 9/22/08, Jeff Squyres wrote:
From: Jeff Squyres
Subject: Re: [OMPI users] conflict among differenv MPIs
To: "Open MPI Users"
Date: Monday, September 22, 2008, 11:28 AM
On Sep 22, 2008, at 2:12 PM, Shafagh Jafer wrote:
> I am gonna kill myself :( i dont know what the problem is... I 'm
> gonna explain the details again, please bare me and help me :(
>
> Ok yes I used mpic++. Actually I checked mpicxx -show and the path
> were correct. let me describe my problem again.
> When I run my code (after making sure that openmpi is installed
> correctly and all the env varibles are set properly), i get the
> following error which is when I make a call to the following
function:
> --
> int CommPhyMPI:: physicalGetSize() const {
> int size ;
> MPI_Comm_size(MPI_COMM_WORLD,&size);
> return size ;
> }
> ---
> The errors i get are the follwoing:
> =
> [DeepThought:31144] *** Process received signal ***
> [DeepThought:31144] Signal: Segmentation fault (11)
> [DeepThought:31144] Signal code: Address not mapped (1)
> [DeepThought:31144] Failing at address: 0xcf
> [DeepThought:31144] [ 0] /lib/tls/libpthread.so.0 [0xc16f80]
> [DeepThought:31144] [ 1] /nfs/sjafer/phd/openMPI/latest_cd+
> +_timewarp/cd++(physicalGetId__C10CommPhyMPI+0x14) [0x8305880]
This *likely* indicates that you are mixing MPI implementations.
> So I thought that maybe my problem is that when I include
"mpi.h" in
> my source code, it picks the wrong one. So in my source code instead
> of just saying include "mpi.h" I put the path too, so it looks
like
> => "include /opt/openmpi/1.2.7/include/mpi.h", and now when I
run my
> code aftre this change, aside from errors which I will paste below,
> i get a warning that shows mpi.h in mpicxx.h is the wrong one from
> usr/local/include and not from /opt/openmpi/...
> --
> In file included from /usr/local/include/mpidefs.h:49,
What is /usr/local/include/mpidefs.h? Is that part of your
application?
> from /usr/local/include/mpi.h:230,
This definitely indicates that you're including the wrong file.
I don't know what the exact cause of your problem is, but it seems
like you are somehow mixing multiple mpi.h files together. This can
definitely lead to segv's at run time.
As I think I indicated before, I think your best solution is likely to
uninstall MPICH from /usr/local and install it somewhere else (e.g., /
opt/mpich). Then the compiler won't automatically pick up header
files from MPICH (it shouldn't do that anyway, but there seems to be
some confusion on your system, so who knows?).
You should probably get your local system administrator involved; they
can actually see exactly what is happening on your system, diagnose
the default compiler include paths, etc. But I'd try moving the MPICH
install first.
--
Jeff Squyres
Cisco Systems
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
Re: [OMPI users] conflict among differenv MPIs
I am not using any of the files that exist in /usr/local/include, this doesn't
even show on my PATH and my mpicc -show tells that the openmpi path is correct.
I dont know what to do, I have contacted the technician to hide or delete
/usr/local/include...Millions of thanks for ur replies and patience. I'll keep
you updated!
--- On Mon, 9/22/08, Jeff Squyres wrote:
From: Jeff Squyres
Subject: Re: [OMPI users] conflict among differenv MPIs
To: "Open MPI Users"
List-Post: users@lists.open-mpi.org
Date: Monday, September 22, 2008, 11:28 AM
On Sep 22, 2008, at 2:12 PM, Shafagh Jafer wrote:
> I am gonna kill myself :( i dont know what the problem is... I 'm
> gonna explain the details again, please bare me and help me :(
>
> Ok yes I used mpic++. Actually I checked mpicxx -show and the path
> were correct. let me describe my problem again.
> When I run my code (after making sure that openmpi is installed
> correctly and all the env varibles are set properly), i get the
> following error which is when I make a call to the following function:
> --
> int CommPhyMPI:: physicalGetSize() const {
> int size ;
> MPI_Comm_size(MPI_COMM_WORLD,&size);
> return size ;
> }
> ---
> The errors i get are the follwoing:
> =
> [DeepThought:31144] *** Process received signal ***
> [DeepThought:31144] Signal: Segmentation fault (11)
> [DeepThought:31144] Signal code: Address not mapped (1)
> [DeepThought:31144] Failing at address: 0xcf
> [DeepThought:31144] [ 0] /lib/tls/libpthread.so.0 [0xc16f80]
> [DeepThought:31144] [ 1] /nfs/sjafer/phd/openMPI/latest_cd+
> +_timewarp/cd++(physicalGetId__C10CommPhyMPI+0x14) [0x8305880]
This *likely* indicates that you are mixing MPI implementations.
> So I thought that maybe my problem is that when I include
"mpi.h" in
> my source code, it picks the wrong one. So in my source code instead
> of just saying include "mpi.h" I put the path too, so it looks
like
> => "include /opt/openmpi/1.2.7/include/mpi.h", and now when I
run my
> code aftre this change, aside from errors which I will paste below,
> i get a warning that shows mpi.h in mpicxx.h is the wrong one from
> usr/local/include and not from /opt/openmpi/...
> --
> In file included from /usr/local/include/mpidefs.h:49,
What is /usr/local/include/mpidefs.h? Is that part of your application?
> from /usr/local/include/mpi.h:230,
This definitely indicates that you're including the wrong file.
I don't know what the exact cause of your problem is, but it seems
like you are somehow mixing multiple mpi.h files together. This can
definitely lead to segv's at run time.
As I think I indicated before, I think your best solution is likely to
uninstall MPICH from /usr/local and install it somewhere else (e.g., /
opt/mpich). Then the compiler won't automatically pick up header
files from MPICH (it shouldn't do that anyway, but there seems to be
some confusion on your system, so who knows?).
You should probably get your local system administrator involved; they
can actually see exactly what is happening on your system, diagnose
the default compiler include paths, etc. But I'd try moving the MPICH
install first.
--
Jeff Squyres
Cisco Systems
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] conflict among differenv MPIs
On Sep 22, 2008, at 2:12 PM, Shafagh Jafer wrote:
I am gonna kill myself :( i dont know what the problem is... I 'm
gonna explain the details again, please bare me and help me :(
Ok yes I used mpic++. Actually I checked mpicxx -show and the path
were correct. let me describe my problem again.
When I run my code (after making sure that openmpi is installed
correctly and all the env varibles are set properly), i get the
following error which is when I make a call to the following function:
--
int CommPhyMPI:: physicalGetSize() const {
int size ;
MPI_Comm_size(MPI_COMM_WORLD,&size);
return size ;
}
---
The errors i get are the follwoing:
=
[DeepThought:31144] *** Process received signal ***
[DeepThought:31144] Signal: Segmentation fault (11)
[DeepThought:31144] Signal code: Address not mapped (1)
[DeepThought:31144] Failing at address: 0xcf
[DeepThought:31144] [ 0] /lib/tls/libpthread.so.0 [0xc16f80]
[DeepThought:31144] [ 1] /nfs/sjafer/phd/openMPI/latest_cd+
+_timewarp/cd++(physicalGetId__C10CommPhyMPI+0x14) [0x8305880]
This *likely* indicates that you are mixing MPI implementations.
So I thought that maybe my problem is that when I include "mpi.h" in
my source code, it picks the wrong one. So in my source code instead
of just saying include "mpi.h" I put the path too, so it looks like
=> "include /opt/openmpi/1.2.7/include/mpi.h", and now when I run my
code aftre this change, aside from errors which I will paste below,
i get a warning that shows mpi.h in mpicxx.h is the wrong one from
usr/local/include and not from /opt/openmpi/...
--
In file included from /usr/local/include/mpidefs.h:49,
What is /usr/local/include/mpidefs.h? Is that part of your application?
from /usr/local/include/mpi.h:230,
This definitely indicates that you're including the wrong file.
I don't know what the exact cause of your problem is, but it seems
like you are somehow mixing multiple mpi.h files together. This can
definitely lead to segv's at run time.
As I think I indicated before, I think your best solution is likely to
uninstall MPICH from /usr/local and install it somewhere else (e.g., /
opt/mpich). Then the compiler won't automatically pick up header
files from MPICH (it shouldn't do that anyway, but there seems to be
some confusion on your system, so who knows?).
You should probably get your local system administrator involved; they
can actually see exactly what is happening on your system, diagnose
the default compiler include paths, etc. But I'd try moving the MPICH
install first.
--
Jeff Squyres
Cisco Systems
Re: [OMPI users] conflict among differenv MPIs
I am gonna kill myself :( i dont know what the problem is... I 'm gonna explain
the details again, please bare me and help me :(
Ok yes I used mpic++. Actually I checked mpicxx -show and the path were
correct. let me describe my problem again.
When I run my code (after making sure that openmpi is installed correctly and
all the env varibles are set properly), i get the following error which is when
I make a call to the following function:
--
int CommPhyMPI:: physicalGetSize() const {
int size ;
MPI_Comm_size(MPI_COMM_WORLD,&size);
return size ;
}
---
The errors i get are the follwoing:
=
[DeepThought:31144] *** Process received signal ***
[DeepThought:31144] Signal: Segmentation fault (11)
[DeepThought:31144] Signal code: Address not mapped (1)
[DeepThought:31144] Failing at address: 0xcf
[DeepThought:31144] [ 0] /lib/tls/libpthread.so.0 [0xc16f80]
[DeepThought:31144] [ 1]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(physicalGetId__C10CommPhyMPI+0x14)
[0x8305880]
[DeepThought:31144] [ 2]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(physicalCommGetId__Fv+0x43)
[0x82ff81b]
[DeepThought:31144] [ 3]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(openComm__16StandAloneLoader+0x1f)
[0x80fdf43]
[DeepThought:31144] [ 4]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(run__21ParallelMainSimulator+0x1640)
[0x81ea53c]
[DeepThought:31144] [ 5]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(main+0xde) [0x80a58ce]
[DeepThought:31144] [ 6] /lib/tls/libc.so.6(__libc_start_main+0xda) [0x1c979a]
[DeepThought:31144] [ 7]
/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/cd++(sinh+0x4d) [0x80a2221]
[DeepThought:31144] *** End of error message ***
mpirun noticed that job rank 0 with PID 31144 on node
DeepThought.sce.carleton.ca exited on signal 11 (Segmentation fault).
=
So I thought that maybe my problem is that when I include "mpi.h" in my source
code, it picks the wrong one. So in my source code instead of just saying
include "mpi.h" I put the path too, so it looks like => "include
/opt/openmpi/1.2.7/include/mpi.h", and now when I run my code aftre this
change, aside from errors which I will paste below, i get a warning that shows
mpi.h in mpicxx.h is the wrong one from usr/local/include and not from
/opt/openmpi/...
--
In file included from /usr/local/include/mpidefs.h:49,
from /usr/local/include/mpi.h:230,
from /opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:32,
from /opt/openmpi/1.2.7/include/mpi.h:1795,
from CommPhyMPI.cc:36:
/usr/local/include/mpio.h:79: warning: `MPI_FILE_NULL' redefined
/opt/openmpi/1.2.7/include/mpi.h:456: warning: this is the location of the
previous definition
In file included from
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:32,
from /opt/openmpi/1.2.7/include/mpi.h:1795,
from CommPhyMPI.cc:36:
/usr/local/include/mpi.h:263: warning: `MPI_STATUS_IGNORE' redefined
/opt/openmpi/1.2.7/include/mpi.h:458: warning: this is the location of the
previous definition
/usr/local/include/mpi.h:264: warning: `MPI_STATUSES_IGNORE' redefined
/opt/openmpi/1.2.7/include/mpi.h:459: warning: this is the location of the
previous definition
--
here are the errors:
In file included from /opt/openmpi/1.2.7/include/mpi.h:1795,
from CommPhyMPI.cc:36:
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:167:
openmpi/ompi/mpi/cxx/constants.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:168:
openmpi/ompi/mpi/cxx/functions.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:169:
openmpi/ompi/mpi/cxx/datatype.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:193:
openmpi/ompi/mpi/cxx/exception.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:194:
openmpi/ompi/mpi/cxx/op.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:195:
openmpi/ompi/mpi/cxx/status.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:196:
openmpi/ompi/mpi/cxx/request.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:197:
openmpi/ompi/mpi/cxx/group.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:198:
openmpi/ompi/mpi/cxx/comm.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:199:
openmpi/ompi/mpi/cxx/win.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:200:
openmpi/ompi/mpi/cxx/file.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:201:
openmpi/ompi/mpi/cxx/errhandler.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:202:
openmpi/ompi/mpi/cxx/intracomm.h: No such file or di
Re: [OMPI users] conflict among differenv MPIs
On Sep 22, 2008, at 1:24 PM, Shafagh Jafer wrote: I am confused now...should I use "/openmpi/mpic++ -E" or "/openmpi/ mpic++" to compile my entire code?? mpic++. I was showing you the -E functionality so that you could determine whether it really is picking up the wrong mpi.h or not. --- On Mon, 9/22/08, Jeff Squyres wrote: From: Jeff Squyres Subject: Re: [OMPI users] conflict among differenv MPIs To: "Open MPI Users" Date: Monday, September 22, 2008, 6:12 AM On Sep 22, 2008, at 8:48 AM, Robert Kubrick wrote: > Recompile your own version of openmpi in a local directory, set your > PATH to your local openmpi install. > > export PATH=/my/openmpi/install/include:/usr/local/include > > mpicxx -show mpicxx --showme should show you the exact command that Open MPI's wrapper compiler is using to compile your application. There should already be an explicit -I there for where OMPI's mpi.h resides. If that's the case, the compiler should look there *first* for mpi.h, not /usr/local/include. Consider following example: - I created include-test.c which just does an "#include ". - If I run this through the preprocessor, you can see that it's getting /usr/include/stdio.h: [6:09] svbu-mpi:~/tmp % cat include-test.c #include [6:09] svbu-mpi:~/tmp % gcc -E include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "/usr/include/stdio.h" 1 3 4 # 28 "/usr/include/stdio.h" 3 4 # 1 "/usr/include/features.h" 1 3 4 # 319 "/usr/include/features.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 320 "/usr/include/features.h" 2 3 4 - But now I make my-include-dir/stdio.h with a single line in it - Then I recompile with an explicit -I for that directory and you can see that the compiler picks up that stdio.h, not /usr/include/stdio.h [6:09] svbu-mpi:~/tmp % cat my-include-dir/stdio.h typedef int foo; [6:09] svbu-mpi:~/tmp % gcc -E -Imy-include-dir include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "my-include-dir/stdio.h" 1 typedef int foo; # 2 "include-test.c" 2 [6:10] svbu-mpi:~/tmp % Are you sure that OMPI's mpicxx.h is picking up MPICH's mpi.h? If so, how? Did you run it through the preprocessor (perhaps similar to above), or step through a debugger or something? -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Brian and list I read your original posting and Jeff's answers. Here on CentOS from Rocks Cluster I have a "native" OpenMPI, with a mpi.mod, compiled with gfortran. Note that I don't even have gfortran installed! This is besides the MPI versions (MPICH2 and OpenMPI) I installed from scratch using combinations of ifort and pgi with gcc. It may be that mpif90 is not picking the right mpi.mod, as Jeff suggested. Something like this may be part of your problem. A "locate mpi.mod" should show what your system has. Have you tried to force the directory where mpi.mod is searched for? Something like this: /full/path/to/openmpi/bin/mpif90 -module /full/path/to/openmpi_mpi.mod_directory/ hello_f90.f90 The ifort man pages has the "-module" syntax details. I hope this helps. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: Hi Gus- Thanks for the input. I have been using full path names to both the wrapper compilers and mpiexec from the first day I had two MPI implementations on my machine, depending on if I want to use MPICH or openMPI, but still the problem remains. ARGG! On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: Hello Brian and list My confusing experiences with multiple MPI implementations were fixed the day I decided to use full path names to the MPI compiler wrappers (mpicc, mpif77, etc) at compile time, and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, and to do this in a consistent fashion (using the tools from the same install to compile and to run the programs). Most Linux distributions come with built in MPI implementations (often times more than one), and so do commercial compilers and other tools. You end up with a mess of different MPI versions on your "native" PATH, as well as variety of bin, lib, and include directories containing different MPI stuff. The easy way around is to use full path names, particularly if you install yet another MPI implementation from scratch. Another way is to fix your PATH on your initialization files (.cshrc, etc) to point to your preferred implementation (put the appropriate bin directory ahead of everything else). Yet another is to install the "environment modules" package on your system and use it consistently. My two cents. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is finding first? E.g., in your MPICH2 installation? Or is Open MPI installed by your distro, perchance? You might want to try a "rpm -qa | grep openmpi" (or whatever your distro's equivalent is to check already-installed packages). -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] conflict among differenv MPIs
I am confused now...should I use "/openmpi/mpic++ -E" or "/openmpi/mpic++" to compile my entire code?? --- On Mon, 9/22/08, Jeff Squyres wrote: From: Jeff Squyres Subject: Re: [OMPI users] conflict among differenv MPIs To: "Open MPI Users" List-Post: users@lists.open-mpi.org Date: Monday, September 22, 2008, 6:12 AM On Sep 22, 2008, at 8:48 AM, Robert Kubrick wrote: > Recompile your own version of openmpi in a local directory, set your > PATH to your local openmpi install. > > export PATH=/my/openmpi/install/include:/usr/local/include > > mpicxx -show mpicxx --showme should show you the exact command that Open MPI's wrapper compiler is using to compile your application. There should already be an explicit -I there for where OMPI's mpi.h resides. If that's the case, the compiler should look there *first* for mpi.h, not /usr/local/include. Consider following example: - I created include-test.c which just does an "#include ". - If I run this through the preprocessor, you can see that it's getting /usr/include/stdio.h: [6:09] svbu-mpi:~/tmp % cat include-test.c #include [6:09] svbu-mpi:~/tmp % gcc -E include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "/usr/include/stdio.h" 1 3 4 # 28 "/usr/include/stdio.h" 3 4 # 1 "/usr/include/features.h" 1 3 4 # 319 "/usr/include/features.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 320 "/usr/include/features.h" 2 3 4 - But now I make my-include-dir/stdio.h with a single line in it - Then I recompile with an explicit -I for that directory and you can see that the compiler picks up that stdio.h, not /usr/include/stdio.h [6:09] svbu-mpi:~/tmp % cat my-include-dir/stdio.h typedef int foo; [6:09] svbu-mpi:~/tmp % gcc -E -Imy-include-dir include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "my-include-dir/stdio.h" 1 typedef int foo; # 2 "include-test.c" 2 [6:10] svbu-mpi:~/tmp % Are you sure that OMPI's mpicxx.h is picking up MPICH's mpi.h? If so, how? Did you run it through the preprocessor (perhaps similar to above), or step through a debugger or something? -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Checkpointing a restarted app fails
I believe this is now fixed in the trunk. I was able to reproduce with the current trunk and committed a fix a few minutes ago in r19601. So the fix should be in tonight's tarball (or you can grab it from SVN). I've made a request to have the patch applied to v1.3, but that may take a day or so to complete. Let me know if this fix eliminates your SIGPIPE issues. Thanks for the bug report :) Cheers, Josh On Sep 17, 2008, at 11:55 PM, Matthias Hovestadt wrote: Hi Josh! First of all, thanks a lot for replying. :-) When executing this checkpoint command, the running application directly aborts, even though I did not specify the "--term" option: -- mpirun noticed that process rank 1 with PID 14050 on node grid- demo-1.cit.tu-berlin.de exited on signal 13 (Broken pipe). -- ccs@grid-demo-1:~$ Interesting. This looks like a bug with the restart mechanism in Open MPI. This was working fine, but something must have changed in the trunk to break it. Do you perhaps know a SVN revision number of OMPI that is known to be working? If this issue is a regression failure, I would be glad to use the source from an old but working SVN state... A useful piece of debugging information for me would be a stack trace from the failed process. You should be able to get this from a core file it left or If you would set the following MCA variable in $HOME/.openmpi/mca-params.conf: opal_cr_debug_sigpipe=1 This will cause the Open MPI app to wait in a sleep loop when it detects a Broken Pipe signal. Then you should be able to attach a debugger and retrieve a stack trace. I created this file: ccs@grid-demo-1:~$ cat .openmpi/mca-params.conf opal_cr_debug_sigpipe=1 ccs@grid-demo-1:~$ Then I restarted the application from a checkpointed state and tried to checkpoint this restarted application. Unfortunately the restated application still terminates, despite of this para- meter. However, the output slightly changed : worker fetch area available 1 [grid-demo-1.cit.tu-berlin.de:26220] opal_cr: sigpipe_debug: Debug SIGPIPE [13]: PID (26220) -- mpirun noticed that process rank 0 with PID 26248 on node grid- demo-1.cit.tu-berlin.de exited on signal 0 (Unknown signal 0). -- 2 total processes killed (some possibly by mpirun during cleanup) ccs@grid-demo-1:~$ There is now this additional "opal_cr: sigpipe_debug" line, so he apparently evaluates the .openmpi/mca-params.conf I also tried to get a corefile by setting "ulimit -c 5", so that ulimit -a gives me the following output: ccs@grid-demo-1:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ccs@grid-demo-1:~$ Unfortunately, no corefile is generated, so that I do not know how to give you the requested stacktrace. Are there perhaps other debug parameters I could use? Best, Matthias ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Gus- Thanks for the input. I have been using full path names to both the wrapper compilers and mpiexec from the first day I had two MPI implementations on my machine, depending on if I want to use MPICH or openMPI, but still the problem remains. ARGG! On Mon, Sep 22, 2008 at 9:40 AM, Gus Correa wrote: > Hello Brian and list > > My confusing experiences with multiple MPI implementations > were fixed the day I decided to use full path names to the MPI compiler > wrappers (mpicc, mpif77, etc) at compile time, > and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, > and to do this in a consistent fashion (using the tools from the same > install to compile and to run the programs). > > Most Linux distributions come with built in MPI implementations (often times > more than one), > and so do commercial compilers and other tools. > You end up with a mess of different MPI versions on your "native" PATH, > as well as variety of bin, lib, and include directories containing different > MPI stuff. > The easy way around is to use full path names, particularly if you install > yet another MPI implementation > from scratch. > Another way is to fix your PATH on your initialization files (.cshrc, etc) > to point to your preferred implementation (put the appropriate bin directory > ahead of everything else). > Yet another is to install the "environment modules" package on your system > and use it consistently. > > My two cents. > > Gus Correa > > -- > - > Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu > Lamont-Doherty Earth Observatory - Columbia University > P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA > - > > > Brian Harker wrote: > >> I built and installed both MPICH2 and openMPI from source, so no >> distribution packages or anything. MPICH2 has the modules located in >> /usr/local/include, which I assume would be found (since its in my >> path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, >> right? I can't imagine that if you tell it where to look for the >> correct modules, it would search through your path first before going >> to where you tell it to go. Or am I too optimistic? Thanks again for >> the input! >> >> On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: >> >>> >>> On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: >>> >>> Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, >>> >>> That should be correct. >>> >>> but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. >>> >>> Ok, good. >>> >>> Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( >>> >>> Ok. Have you checked around your machine to ensure that there is no >>> other >>> mpi.mod that the compiler is finding first? E.g., in your MPICH2 >>> installation? Or is Open MPI installed by your distro, perchance? You >>> might want to try a "rpm -qa | grep openmpi" (or whatever your distro's >>> equivalent is to check already-installed packages). >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >>> ___ >>> users mailing list >>> us...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >>> >> >> >> >> > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hello Brian and list My confusing experiences with multiple MPI implementations were fixed the day I decided to use full path names to the MPI compiler wrappers (mpicc, mpif77, etc) at compile time, and to the MPI job launcher (mpirun, mpiexec, and so on) at run time, and to do this in a consistent fashion (using the tools from the same install to compile and to run the programs). Most Linux distributions come with built in MPI implementations (often times more than one), and so do commercial compilers and other tools. You end up with a mess of different MPI versions on your "native" PATH, as well as variety of bin, lib, and include directories containing different MPI stuff. The easy way around is to use full path names, particularly if you install yet another MPI implementation from scratch. Another way is to fix your PATH on your initialization files (.cshrc, etc) to point to your preferred implementation (put the appropriate bin directory ahead of everything else). Yet another is to install the "environment modules" package on your system and use it consistently. My two cents. Gus Correa -- - Gustavo J. Ponce Correa, PhD - Email: g...@ldeo.columbia.edu Lamont-Doherty Earth Observatory - Columbia University P.O. Box 1000 [61 Route 9W] - Palisades, NY, 10964-8000 - USA - Brian Harker wrote: I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is finding first? E.g., in your MPICH2 installation? Or is Open MPI installed by your distro, perchance? You might want to try a "rpm -qa | grep openmpi" (or whatever your distro's equivalent is to check already-installed packages). -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
I unfortunately don't know ifort's precedence rules for finding modules -- I actually don't even remember if -I is the right flag to find them. mpif90 should be adding whatever flags are necessary to find out mpi.mod, though -- but I'm wondering if MPICH's is being found first, since it's in /usr/local/lib. Check the ifort man page, I guess...? An easy way to test would be to rename /usr/local/lib/ mpi.mod to be /usr/local/lib/foo.mod, and then see if your compile works. If it does, it might be simplest to install MPICH into somewhere other than /usr/local. You might also want to check your distro anyway; some distros are shipping Open MPI these days and I don't know what options you need to select to get their version of Open MPI installed by default (or not). On Sep 22, 2008, at 11:14 AM, Brian Harker wrote: I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is finding first? E.g., in your MPICH2 installation? Or is Open MPI installed by your distro, perchance? You might want to try a "rpm -qa | grep openmpi" (or whatever your distro's equivalent is to check already-installed packages). -- Jeff Squyres Cisco Systems ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
I built and installed both MPICH2 and openMPI from source, so no distribution packages or anything. MPICH2 has the modules located in /usr/local/include, which I assume would be found (since its in my path), were it not for specifying -I$OPENMPI_HOME/lib at compile time, right? I can't imagine that if you tell it where to look for the correct modules, it would search through your path first before going to where you tell it to go. Or am I too optimistic? Thanks again for the input! On Mon, Sep 22, 2008 at 8:58 AM, Jeff Squyres wrote: > On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: > >> Thanks for the reply...crap, $HOME/openmpi/lib does contains all the >> various lilbmpi* files as well as mpi.mod, > > That should be correct. > >> but still get the same >> error at compile-time. Yes, I made sure to specifically build openMPI >> with ifort 10.1.012, and did run the --showme command right after >> installation to make sure the wrapper compiler was using ifort as >> well. > > Ok, good. > >> Before posting to this mailing list, I did uninstall and re-install >> openMPI several times to make sure I had a clean install. Still no >> luck. :( > > Ok. Have you checked around your machine to ensure that there is no other > mpi.mod that the compiler is finding first? E.g., in your MPICH2 > installation? Or is Open MPI installed by your distro, perchance? You > might want to try a "rpm -qa | grep openmpi" (or whatever your distro's > equivalent is to check already-installed packages). > > -- > Jeff Squyres > Cisco Systems > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford
Re: [OMPI users] Segmentation Fault--libc.so.6(__libc_start_main...
Aurelien's advice is good -- check and see exactly what the debugger is telling you. You might want to look at the corefile in the debugger and see exactly where it failed -- it may or may not be an MPI issue. Also -- Aurelien didn't directly say it, but don't worry about the OMPI_DECLSPEC stuff. You'll see earlier in mpi.h that OMPI_DECLSPEC is #define'd to be empty (it's for Windows compatibility). Keep in mind that although different MPI implementations provide source code compatibility for MPI applications, they are not binary- portable. So if you compile an MPI application with MPICH's wrapper compilers, it will not run properly under Open MPI's mpirun (and vice versa). You must entirely compile your application with Open MPI's wrapper compilers and then run it with Open MPI's mpirun. On Sep 21, 2008, at 12:35 PM, Aurélien Bouteiller wrote: Are you sure that you have matching versions of the MPI library and mpi.h file ? Open MPI and MPICH have different internal types for the opaque MPI objects (such as MPI_Comm). If you have mismatching mpi.h and mpi library, you'll transmit those as integer to the library while it is expecting pointers. This will obviously segfault very badly. Please make sure that you actually use the mpi.h from open MPI (by using Open MPI's mpicc) to compile your program when using Open MPI. Also make sure that you don't have another version of libmpi in your LD_LIBRARY_PATH that could be used instead of the one you used to compile. Aurelien Le 21 sept. 08 à 04:38, Shafagh Jafer a écrit : Ok. I noticed that whenever in my code, i use an MPI fucntion that has "OMPI_DECLSPEC" in front of it in mpi.h , I get this segfault error. Could some one please tell me what is "OMPI_DECLSPEC"?? is it a macro that I need to enable ?!? forexample, in MPICH the function getsize in mpi.h looks like the following: int MPI_Comm_size(MPI_Comm, int *); but the same function in OMPI apears as follows: OMPI_DECLSPEC int MPI_Comm_size(MPI_Comm comm, int *size); --- On Sat, 9/20/08, Shafagh Jafer wrote: From: Shafagh Jafer Subject: Re: [OMPI users] Segmentation Fault--libc.so. 6(__libc_start_main... To: "Open MPI Users" Date: Saturday, September 20, 2008, 9:50 PM My code was working perfect when I had it with MPICH now I have replaced that with OMPI. Could that be the problem?? Do I need to change any part of my source code if I migrate from MPICH-1.2.6 to OpenMPI-1.2.7?? Please let me know. --- On Sat, 9/20/08, Aurélien Bouteiller wrote: From: Aurélien Bouteiller Subject: Re: [OMPI users] Segmentation Fault--libc.so. 6(__libc_start_main... To: "Open MPI Users" Date: Saturday, September 20, 2008, 6:54 AM Shafagh, You have a segfault in your own code. Because Open MPI detects it, it forwards the error to you and pretty print it but Open MPI is not the source of the bug. From the stack trace, I suggest you gdb debug the PhysicalGetID function. Aurelien Le 19 sept. 08 à 22:22, Shafagh Jafer a écrit : > Hi every one, > I need urgent help plz :-( > I am getting the following error when i run my program. OpenMPI > compilation was all fine and went well, but now i dont understand > the source of this error: > > [node01:29264] *** Process received signal *** > [node01:29264] Signal: Segmentation fault (11) > [node01:29264] Signal code: Address not mapped (1) > [node01:29264] Failing at address: 0xcf > [node01:29264] [ 0] /lib/tls/libpthread.so.0 [0x7ccf80] > [node01:29264] [ 1] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (physicalGetId__C10CommPhyMPI+0x14) [0x8305880] > [node01:29264] [ 2] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (physicalCommGetId__Fv+0x43) [0x82ff81b] > [node01:29264] [ 3] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (openComm__16StandAloneLoader+0x1f) [0x80fdf43] > [node01:29264] [ 4] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (run__21ParallelMainSimulator+0x1640) [0x81ea53c] > [node01:29264] [ 5] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (main+0xde) [0x80a58ce] > [node01:29264] [ 6] /lib/tls/libc.so.6(__libc_start_main+0xda) > [0xe3d79a] > [node01:29264] [ 7] /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/ cd++ > (sinh+0x4d) [0x80a2221] > [node01:29264] *** End of error message *** > mpirun noticed that job rank 0 with PID 29264 on node node01 exited > on signal 11 (Segmentation fault). > === > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users -- * Dr. Aurélien Bouteiller * Sr. Research Associate at Innovative Computing Laboratory * University of Tennessee * 1122 Volunteer Boulevard, suite 350 * Knoxville, TN 37996 * 865 974 6321 ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.c
Re: [OMPI users] Segmentation Fault--libc.so.6(__libc_start_main...
On Sep 21, 2008, at 3:46 PM, Shafagh Jafer wrote:
Yes I am using openmpi mpicc and mpic++ to compile my code,
Are you 100% sure that you're using Open MPI's mpicc / mpic++? (and
not MPICH's) This could be a cause for error.
and I only have openmpi's lib directory in my LD_LIBRARY_PATH. to
make sure that I am including the mpi.h of openmpi, i added this
line to my source code
#include "/opt/openmpi/1.2.7/include/mpi.h"
instead of only saying
#include "mpi.h"
but now i get the following errors, which show that the wrapper
compiler is not adding "
-I${prefix}/include/openmpi" infron of the included files from cxx
folder.
In file included from /opt/openmpi/1.2.7/include/mpi.h:1795,
from CommPhyMPI.cc:36:
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:167:
CommMgrInterface.cc -o /nfs/sjafer/phd/openMPI/latest_cd++_timewarp/
warped/TimeWarp/src/obj/CommMgrInterface.o
openmpi/ompi/mpi/cxx/constants.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:168:
openmpi/ompi/mpi/cxx/functions.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:169:
openmpi/ompi/mpi/cxx/datatype.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:193:
openmpi/ompi/mpi/cxx/exception.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:194:
openmpi/ompi/mpi/cxx/op.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:195:
openmpi/ompi/mpi/cxx/status.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:196:
openmpi/ompi/mpi/cxx/request.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:197:
openmpi/ompi/mpi/cxx/group.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:198:
openmpi/ompi/mpi/cxx/comm.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:199:
openmpi/ompi/mpi/cxx/win.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:200:
openmpi/ompi/mpi/cxx/file.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:201:
openmpi/ompi/mpi/cxx/errhandler.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:202:
openmpi/ompi/mpi/cxx/intracomm.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:203:
openmpi/ompi/mpi/cxx/topology.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:204:
openmpi/ompi/mpi/cxx/intercomm.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:205:
openmpi/ompi/mpi/cxx/info.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:244:
openmpi/ompi/mpi/cxx/datatype_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:245:
openmpi/ompi/mpi/cxx/functions_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:246:
openmpi/ompi/mpi/cxx/request_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:247:
openmpi/ompi/mpi/cxx/comm_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:248:
openmpi/ompi/mpi/cxx/intracomm_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:249:
openmpi/ompi/mpi/cxx/topology_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:250:
openmpi/ompi/mpi/cxx/intercomm_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:251:
openmpi/ompi/mpi/cxx/group_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:252:
openmpi/ompi/mpi/cxx/op_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:253:
openmpi/ompi/mpi/cxx/errhandler_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:254:
openmpi/ompi/mpi/cxx/status_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:255:
openmpi/ompi/mpi/cxx/info_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:256:
openmpi/ompi/mpi/cxx/win_inln.h: No such file or directory
/opt/openmpi/1.2.7/include/openmpi/ompi/mpi/cxx/mpicxx.h:257:
openmpi/ompi/mpi/cxx/file_inln.h: No such file or directory
make[1]: *** [/nfs/sjafer/phd/openMPI/latest_cd++_timewarp/warped/
TimeWarp/src/obj/CommPhyMPI.o] Error 1
--- On Sun, 9/21/08, Aurélien Bouteiller
wrote:
From: Aurélien Bouteiller
Subject: Re: [OMPI users] Segmentation Fault--libc.so.
6(__libc_start_main...
To: "Open MPI Users"
Date: Sunday, September 21, 2008, 9:35 AM
Are you sure that you have matching versions of the MPI library and
mpi.h file ? Open M
Re: [OMPI users] Migrating from MPICH-1.2.6 to OpenMPI-1.2.7
Open MPI and MPICH are both implementations of the MPI standard. As such, correct MPI applications should be completely source-portable between Open MPI and any other MPI implementation (including MPICH). On Sep 21, 2008, at 12:46 AM, Shafagh Jafer wrote: Hello, I want to know if I need to make any modifications to my source code to replace MPICH-1.2.6 with Openmpi-1.2.7?? I mean are the function interfaces exactly the same in both MPISH and OMPI?? please let me know. Thanks. ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
On Sep 22, 2008, at 10:10 AM, Brian Harker wrote: Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, That should be correct. but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Ok, good. Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( Ok. Have you checked around your machine to ensure that there is no other mpi.mod that the compiler is finding first? E.g., in your MPICH2 installation? Or is Open MPI installed by your distro, perchance? You might want to try a "rpm -qa | grep openmpi" (or whatever your distro's equivalent is to check already-installed packages). -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
Hi Jeff- Thanks for the reply...crap, $HOME/openmpi/lib does contains all the various lilbmpi* files as well as mpi.mod, but still get the same error at compile-time. Yes, I made sure to specifically build openMPI with ifort 10.1.012, and did run the --showme command right after installation to make sure the wrapper compiler was using ifort as well. Before posting to this mailing list, I did uninstall and re-install openMPI several times to make sure I had a clean install. Still no luck. :( I do have MPICH2 installed, but I keep it isolated with the -I specifier option at compile-time. On Mon, Sep 22, 2008 at 7:04 AM, Jeff Squyres wrote: > On Sep 19, 2008, at 6:51 PM, Brian Harker wrote: > >> I have configured openMPI to work with the Intel C (icc) and C++ >> (icpc) compilers, as well as the Intel fortran (ifort) compiler, and >> built all the single choice buffer fortran 90 bindings: >> >> ./configure --prefix=$HOME/openmpi CC=icc CXX=icpc F77=ifort FC=ifort >> --enable-mpi-f90 --with-mpi-f90-size=medium > > That all looks correct. > >> which works fine. Ok. Onto make all install. Works fine too. Now >> when I try to compile the example hello_f90.f90 program, I get the >> following error: >> >>> $HOME/openmpi/bin/mpif90 hello_f90.f90 -I$HOME/openmpi/include > > FWIW, you shouldn't need that -I, but that *probably* shouldn't be causing > your problem here (note that OMPI's F90 module file is installed into > $prefix/lib, not $prefix/include). > >> fortcom: Error: hello_f90.f90, line 12: This module file was not >> generated by any release of this compiler.[MPI] >> use mpi >> ---^ > > Two things to check: > > 1. Are you using exactly the same ifort to build Open MPI as mpif90 is? I > assume it is, but it's worth checking. You can run the following to see > exactly what mpif90 will execute: > > $HOME/openmpi/bin/mpif90 hello_f90.f90 -I$HOME/openmpi/include --showme > > And then run it yourself, ensuring that your $PATH is set to get the exact > same ifort, etc. I'm *guessing* that this is all correct, but it's worth > checking. > > 2. Check to see if there is another mpi.mod installed somewhere in the > compiler search path that is not the mpi.mod that you expect. For example, > you might want to "rm -rf $HOME/openmpi" to ensure to have a 100% clean Open > MPI install. And look elsewhere on the machine for mpi.mod that may be > found in the compiler search patch before the Open MPI-installed mpi.mod is > found. > > -- > Jeff Squyres > Cisco Systems > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford
Re: [OMPI users] conflict among differenv MPIs
On Sep 22, 2008, at 8:48 AM, Robert Kubrick wrote: Recompile your own version of openmpi in a local directory, set your PATH to your local openmpi install. export PATH=/my/openmpi/install/include:/usr/local/include mpicxx -show mpicxx --showme should show you the exact command that Open MPI's wrapper compiler is using to compile your application. There should already be an explicit -I there for where OMPI's mpi.h resides. If that's the case, the compiler should look there *first* for mpi.h, not /usr/local/include. Consider following example: - I created include-test.c which just does an "#include ". - If I run this through the preprocessor, you can see that it's getting /usr/include/stdio.h: [6:09] svbu-mpi:~/tmp % cat include-test.c #include [6:09] svbu-mpi:~/tmp % gcc -E include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "/usr/include/stdio.h" 1 3 4 # 28 "/usr/include/stdio.h" 3 4 # 1 "/usr/include/features.h" 1 3 4 # 319 "/usr/include/features.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 320 "/usr/include/features.h" 2 3 4 - But now I make my-include-dir/stdio.h with a single line in it - Then I recompile with an explicit -I for that directory and you can see that the compiler picks up that stdio.h, not /usr/include/stdio.h [6:09] svbu-mpi:~/tmp % cat my-include-dir/stdio.h typedef int foo; [6:09] svbu-mpi:~/tmp % gcc -E -Imy-include-dir include-test.c | head # 1 "include-test.c" # 1 "" # 1 "" # 1 "include-test.c" # 1 "my-include-dir/stdio.h" 1 typedef int foo; # 2 "include-test.c" 2 [6:10] svbu-mpi:~/tmp % Are you sure that OMPI's mpicxx.h is picking up MPICH's mpi.h? If so, how? Did you run it through the preprocessor (perhaps similar to above), or step through a debugger or something? -- Jeff Squyres Cisco Systems
Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
On Sep 19, 2008, at 6:51 PM, Brian Harker wrote: I have configured openMPI to work with the Intel C (icc) and C++ (icpc) compilers, as well as the Intel fortran (ifort) compiler, and built all the single choice buffer fortran 90 bindings: ./configure --prefix=$HOME/openmpi CC=icc CXX=icpc F77=ifort FC=ifort --enable-mpi-f90 --with-mpi-f90-size=medium That all looks correct. which works fine. Ok. Onto make all install. Works fine too. Now when I try to compile the example hello_f90.f90 program, I get the following error: $HOME/openmpi/bin/mpif90 hello_f90.f90 -I$HOME/openmpi/include FWIW, you shouldn't need that -I, but that *probably* shouldn't be causing your problem here (note that OMPI's F90 module file is installed into $prefix/lib, not $prefix/include). fortcom: Error: hello_f90.f90, line 12: This module file was not generated by any release of this compiler.[MPI] use mpi ---^ Two things to check: 1. Are you using exactly the same ifort to build Open MPI as mpif90 is? I assume it is, but it's worth checking. You can run the following to see exactly what mpif90 will execute: $HOME/openmpi/bin/mpif90 hello_f90.f90 -I$HOME/openmpi/include --showme And then run it yourself, ensuring that your $PATH is set to get the exact same ifort, etc. I'm *guessing* that this is all correct, but it's worth checking. 2. Check to see if there is another mpi.mod installed somewhere in the compiler search path that is not the mpi.mod that you expect. For example, you might want to "rm -rf $HOME/openmpi" to ensure to have a 100% clean Open MPI install. And look elsewhere on the machine for mpi.mod that may be found in the compiler search patch before the Open MPI-installed mpi.mod is found. -- Jeff Squyres Cisco Systems
Re: [OMPI users] conflict among differenv MPIs
Recompile your own version of openmpi in a local directory, set your PATH to your local openmpi install. export PATH=/my/openmpi/install/include:/usr/local/include mpicxx -show On Sep 21, 2008, at 11:05 PM, Shafagh Jafer wrote: I have tried this, but didn't help :-( could any one help please??? --- On Sun, 9/21/08, Brian Harker wrote: From: Brian Harker Subject: Re: [OMPI users] conflict among differenv MPIs To: "Open MPI Users" Date: Sunday, September 21, 2008, 6:52 PM Just specify where each individual MPI distribution's stuff is on the command line when you compile with mpicc *.c -I$MPICH_HOME/include or mpicc *.c -I$OPENMPI_HOME/include where the "HOME" directories were specified with --prefix= when you installed. Hope this helps. This works for me. Hope this helps. Cheers! On Sun, Sep 21, 2008 at 7:37 PM, Shafagh Jafer wrote: > I have both openmpi and MPICH on my cluster, the problem is that mpi.h of > MPICH is in /usr/local/include and I dont have permission to rename or > remove it from there. In my source code I am including the mpi.h of openmpi > and this works fine, but then mpi.h itself includes mpicxx.h which it again > includes openmpi's mpi.h and this is my problem becase the system goes and > takes the mpi.h file of MPICH which is in /usr/local/include and thus i get > errors segfaults! I am using mpicc wrapper to compile my code and i think my > problem is due to having other mpi.h files. Am I right?? What should I do to > make /usr/local/include in-accesible from my code??? Please help me! > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Mpirun don't execute
On Sep 19, 2008, at 6:50 PM, Santolo Felaco wrote: Hi, I try to be clearer: osa@libertas:~$ echo $LD_LIBRARY_PATH /usr/local/lib:/home/osa/blcr/lib osa@libertas:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ games:/home/osa/blcr/bin I compile the file with mpicc, then: osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 The comand is blocked. Don't run. CTRL+X does not end the program. Try ctrl-c -- that's usually the way to kill applications that appear to have been hung. This is ps output: osa@libertas:~/prove/openmpi$ mpirun -np 2 es1 & [1] 6151 osa@libertas:~/prove/openmpi$ ps PID TTY TIME CMD 6135 pts/200:00:00 bash 6151 pts/200:00:00 mpirun 6153 pts/200:00:00 ssh 6161 pts/200:00:00 ps What is your program doing? Can you tell if it's getting past MPI_INIT, or even launching at all? Can you mpirun non-MPI applications, such as "hostname" and "uptime"? Are you launching this es1 application locally or remotely? From your command line and previous description, I *assume* that it's local, but I see an "ssh" in your ps output, possibly meaning that mpirun has launched the application remotely (e.g., if you specified a default hostfile or somesuch). -- Jeff Squyres Cisco Systems
Re: [OMPI users] Problem with MPI_Send and MPI_Recv
Hello Terry, I do not have an active firewall. I have typed on both computers: netstat -lnut I enclose you the results. I have also written on both computers: mpirun -np 2 --host 10.1.10.208,10.1.10.240 --mca mpi_preconnect_all 1 --prefix /usr/local -mca btl self,tcp -mca btl_tcp_if_include eth1 ./PruebaSumaParalela.out I enclose you the results. Thank you. Sofia - Original Message - From: "Terry Dontje" To: Sent: Friday, September 19, 2008 7:54 PM Subject: Re: [OMPI users] Problem with MPI_Send and MPI_Recv Hello Sofia, After further reflection I wonder if you have a firewall that is preventing connections to certain ports. --td Terry Dontje wrote: Hello Sofia, Ok, so I really wanted the stack of when you run with "-mca mpi_preconnect_all 1" I believe you'll see that one of the processes will be in init. However, the stack still probably will not help me help you. What needs to happen is to step through the code in dbx while the connection is trying to be established. I am hoping you might find the connect call fails or that we've been given an interface that somehow cannot reach the other node. However, when you specified "-mca btl_tcp_if_include eth1" that should have forced things to use the interface you need. So it really comes down to why are we not connecting to the eth1 address? Are we failing on routing to that address or is the connect failing because we are trying to use a port that we are not really allowed to use or is it something else? I don't think it is a routing problem since you are able to reach each node via ssh. Is there someone else on the list that might want to lend a hand here? I feel like I am missing something obvious going on here. --td Date: Fri, 19 Sep 2008 16:09:11 +0200 From: "Sofia Aparicio Secanellas" Subject: Re: [OMPI users] Problem with MPI_Send and MPI_Recv To: "Open MPI Users" Message-ID: <1BBF50FE29F743B5829CC3785F47CADD@aparicio1> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hello Terry, I have installed 1.2.7 and I obtain the same result. I will explain you what I have done. 1. On my computer edu@10.1.10.240 I have added a new user called sofia. This way I have sofia@10.1.10.208 and sofia@10.1.10.240. 2. I have downloaded the openmpi 1.2.7 from the openmpi website on both computers in /home/sofia/Desktop. 3. I have installed everything using "sudo ./configure", "sudo make" and "sudo make install". 4. To make ssh not ask me for a password. I have typed in sofia@10.1.10.208 "ssh-keygen -t dsa", "cd $HOME/.ssh" and "cp id_dsa.pub authorized_keys". I have copied the directory "/home/sofia/.ssh" from sofia@10.1.10.208 to /home/sofia/.ssh in sofia@10.1.10.240. The ssh command without password works on computer sofia@10.1.10.208 but computer sofia@10.1.10.208 ask me for a passphrase and for the password. Is it normal? 5. I have created a directory "/home/sofia/programasparalelos" on both computers and I have given permissions to the directory with "chmod 777". 6. I have copied on both computers in "/home/sofia/programasparalelos" the program "PruebaSumaParalela.c" (I have changed a little bit the program, I enclose you the new program) and I have compiled using "mpicc PruebaSumaParalela.c -o PruebaSumaParalela.out". 7. Now I run the program on both computersusing the command: mpirun -np2 --host 10.1.10.208,10.1.10.240 --prefix /usr/local ./PruebaSumaParalela.out When I run the program I obtain 3 PIDs executing on every computer, 2 of "./PruebaSumaParalela.out" and 1 of "mpirun -np2 --host 10.1.10.208,10.1.10.240 --prefix /usr/local ./PruebaSumaParalela.out". I enclose you the results obtained on every computer for every "./PruebaSumaParalela.out". Thank you very much. Sofia ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users No virus found in this incoming message Checked by PC Tools AntiVirus (4.0.0.26 - 10.100.007). http://www.pctools.com/free-antivirus/ No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.100.007). http://www.pctools.com/free-antivirus/ current thread: t@3083814576 [1] 0xe410(0x0, 0x8051584, 0xb7d1fc29, 0x0, 0x0, 0xb7ec48d0), at 0xe410 [2] sigprocmask(0x0, 0x8051584, 0x0, 0xbfa13c40, 0x0, 0xb7ee4458), at 0xb7d1fc29 [3] opal_evsignal_recalc(0x8051584, 0x4, 0x0, 0xb7ee4458, 0x8051568, 0x4), at 0xb7ec47f4 [4] opal_poll_dispatch(0x8051530, 0x8051568, 0xbfa13d40, 0xb7f668b4, 0x80482e8, 0x1), at 0xb7ec5870 [5] opal_event_base_loop(0x8051530, 0x2, 0x0, 0xb7ee4458, 0xb7ec2e69), at 0xb7ec2ae9 [6] opal_event_loop(0x2, 0xb7c301a8, 0x1a9b860, 0x0, 0x1a9dd9c, 0x0), at 0xb7ec2e89 [7] opal_progress(0x820ca00, 0x8049c00, 0x1, 0xbfa13e68, 0xb7fda408, 0xb7fda408), at 0xb7ebd606 [8] mca_pml_ob1_recv(0xbfa13e68, 0x1, 0x8049c00, 0x1, 0x1, 0x8049d40), at 0xb7c25e56 [9] PMPI_Recv(0xbfa13e68, 0x1, 0x8049c
