March 2008 - petsc-dev - mailman3.cels.anl.gov

Re: This build is so broken
by Satish Balay 31 Mar '08

31 Mar '08

On Mon, 31 Mar 2008, Matthew Knepley wrote: > On Mon, Mar 31, 2008 at 10:12 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > Which part? The 'configure' one, or the 'make' one? > > Anyone who builds needs to pull BuildSystem and reconfigure, and then a bunch > of the make was broken. It is fixed now. now there are a bunch of memory leaks with 'make test'. will have to check this.. satish

1 0

Re: This build is so broken
by Matthew Knepley 31 Mar '08

31 Mar '08

On Mon, Mar 31, 2008 at 10:12 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Which part? The 'configure' one, or the 'make' one? Anyone who builds needs to pull BuildSystem and reconfigure, and then a bunch of the make was broken. It is fixed now. Matt > On 3/31/08, Matthew Knepley <knepley(a)gmail.com> wrote: > > I have spent the last hour trying to get my PETSc to work. This sucks. > > > > Matt > > > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which > > their experiments lead. > > -- Norbert Wiener > > > > > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: This build is so broken
by Lisandro Dalcin 31 Mar '08

31 Mar '08

Which part? The 'configure' one, or the 'make' one? On 3/31/08, Matthew Knepley <knepley(a)gmail.com> wrote: > I have spent the last hour trying to get my PETSc to work. This sucks. > > Matt > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: This build is so broken
by Matthew Knepley 31 Mar '08

31 Mar '08

I pushed fixes for all this crap. Matt On Mon, Mar 31, 2008 at 9:46 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > I have spent the last hour trying to get my PETSc to work. This sucks. > > Matt > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: Check it out
by Richard Katz 31 Mar '08

31 Mar '08

Here's another, about using PETSc for geodynamics: http://dx.doi.org/10.1016/j.pepi.2007.04.016 On 31 Mar 2008, at 15:03, Victor Eijkhout wrote: > > On 2008/03/09, at 7:36 PM, Matthew Knepley wrote: >> http://en.wikipedia.org/wiki/Portable%2C_Extensible_Toolkit_for_Scientific_… > > Wikipedia notes that you don't cite external references. For what > it's worth, here are two mentions of Petsc. Don't look to closely at > the one that I wrote. It's ooooold. > > http://wotug.ukc.ac.uk/parallel/nhse/NHSEreview/ILS/ILSfull.html > > http://www.netlib.org/utk/people/JackDongarra/la-sw.html > > Victor. > >> >> Matt >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which >> their experiments lead. >> -- Norbert Wiener >> > > -- > Victor Eijkhout, 512 471 5809 (w), 512 499 0504 (h) > Texas Advanced Computing Center, The University of Texas at Austin > > > > ___________________________________ Richard Foa Katz RCUK Academic Fellow, Univ Oxford http://www.earth.ox.ac.uk/~richardk

1 0

This build is so broken
by Matthew Knepley 31 Mar '08

31 Mar '08

I have spent the last hour trying to get my PETSc to work. This sucks. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: Check it out
by Victor Eijkhout 31 Mar '08

31 Mar '08

On 2008/03/09, at 7:36 PM, Matthew Knepley wrote: > http://en.wikipedia.org/wiki/Portable% > 2C_Extensible_Toolkit_for_Scientific_Computation Wikipedia notes that you don't cite external references. For what it's worth, here are two mentions of Petsc. Don't look to closely at the one that I wrote. It's ooooold. http://wotug.ukc.ac.uk/parallel/nhse/NHSEreview/ILS/ILSfull.html http://www.netlib.org/utk/people/JackDongarra/la-sw.html Victor. > > Matt > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener > -- Victor Eijkhout, 512 471 5809 (w), 512 499 0504 (h) Texas Advanced Computing Center, The University of Texas at Austin

1 0

Re: ML with OpenMPI
by Satish Balay 25 Mar '08

25 Mar '08

I think our usage of ML is broken. We use "#include "ml_config.h"" in ml.c. However looks like ml requires HAVE_CONFIG_H defined for other things aswell. So the correct fix is to change the above line to: #define HAVE_CONFIG_H Satish On Tue, 25 Mar 2008, Lisandro Dalcin wrote: > OK. Now all is clear to me. Sorry about my confusion. So I have to > conclude that ML machinery for including headers is a bit broken, I > think. Many thanks for your explanation. > > > On 3/25/08, Jed Brown <jed(a)59a2.org> wrote: > > No, ML was built correctly. The build output has -DHAVE_CONFIG_H on every build > > line. What *is* happening is that the headers included by ksp/pc/impls/ml/ml.c > > were essentially for a non-MPI build because HAVE_CONFIG_H was not defined. > > That is, including ml_config.h defines the autoconf'd macros (like HAVE_MPI) and > > ml_common.h uses them to set ML-local macros (like ML_MPI) *only* if > > HAVE_CONFIG_H is defined. So when we include ml_include.h without defining > > HAVE_CONFIG_H, we see the interface for a default (non-MPI) build. This > > interface is (apparently) the same as an MPI build with MPICH2, but not with > > OpenMPI. Since the library was built with MPI, there was no dangerous type > > casting, and you were using it with MPI, there was no problem. When using > > OpenMPI, it sees a conflict between the ML's dummy MPI interface and OpenMPI's > > because ML and MPICH2 use MPI_Comm = int while OpenMPI uses an opaque pointer > > value. > > > > > > > Looking at ML configure script and generated makefiles, in them there > > > is a line saying> > > > > > > DEFS = -DHAVE_CONFIG_H > > > > > > Do you have that line? Next, this $(DEFS) is included in compiler > > > command definition. > > > > > > Additionally, I did > > > > > > $ nm -C libml.a | grep MPI > > > > > > and undefined references to the MPI functions appered as expected. > > > > > > > > > Sorry about my insinstence, but I believe we need to figure out what's > > > exactly going on. > > > > > > No problem. I agree it is important. Does my explanation above make sense to > > you? > > > > > > Jed > > > > > > >

1 0

Re: ML with OpenMPI
by Lisandro Dalcin 25 Mar '08

25 Mar '08

OK. Now all is clear to me. Sorry about my confusion. So I have to conclude that ML machinery for including headers is a bit broken, I think. Many thanks for your explanation. On 3/25/08, Jed Brown <jed(a)59a2.org> wrote: > No, ML was built correctly. The build output has -DHAVE_CONFIG_H on every build > line. What *is* happening is that the headers included by ksp/pc/impls/ml/ml.c > were essentially for a non-MPI build because HAVE_CONFIG_H was not defined. > That is, including ml_config.h defines the autoconf'd macros (like HAVE_MPI) and > ml_common.h uses them to set ML-local macros (like ML_MPI) *only* if > HAVE_CONFIG_H is defined. So when we include ml_include.h without defining > HAVE_CONFIG_H, we see the interface for a default (non-MPI) build. This > interface is (apparently) the same as an MPI build with MPICH2, but not with > OpenMPI. Since the library was built with MPI, there was no dangerous type > casting, and you were using it with MPI, there was no problem. When using > OpenMPI, it sees a conflict between the ML's dummy MPI interface and OpenMPI's > because ML and MPICH2 use MPI_Comm = int while OpenMPI uses an opaque pointer > value. > > > > Looking at ML configure script and generated makefiles, in them there > > is a line saying> > > > > DEFS = -DHAVE_CONFIG_H > > > > Do you have that line? Next, this $(DEFS) is included in compiler > > command definition. > > > > Additionally, I did > > > > $ nm -C libml.a | grep MPI > > > > and undefined references to the MPI functions appered as expected. > > > > > > Sorry about my insinstence, but I believe we need to figure out what's > > exactly going on. > > > No problem. I agree it is important. Does my explanation above make sense to > you? > > > Jed > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: ML with OpenMPI
by Jed Brown 25 Mar '08

25 Mar '08

On Tue 2008-03-25 12:11, Lisandro Dalcin wrote: > Well, then that would mean that I was using ML through PETSc in > PARALLEL runs with no MPI support !!! Do you believe that scenario is > possible? No, ML was built correctly. The build output has -DHAVE_CONFIG_H on every build line. What *is* happening is that the headers included by ksp/pc/impls/ml/ml.c were essentially for a non-MPI build because HAVE_CONFIG_H was not defined. That is, including ml_config.h defines the autoconf'd macros (like HAVE_MPI) and ml_common.h uses them to set ML-local macros (like ML_MPI) *only* if HAVE_CONFIG_H is defined. So when we include ml_include.h without defining HAVE_CONFIG_H, we see the interface for a default (non-MPI) build. This interface is (apparently) the same as an MPI build with MPICH2, but not with OpenMPI. Since the library was built with MPI, there was no dangerous type casting, and you were using it with MPI, there was no problem. When using OpenMPI, it sees a conflict between the ML's dummy MPI interface and OpenMPI's because ML and MPICH2 use MPI_Comm = int while OpenMPI uses an opaque pointer value. > Looking at ML configure script and generated makefiles, in them there > is a line saying> > > DEFS = -DHAVE_CONFIG_H > > Do you have that line? Next, this $(DEFS) is included in compiler > command definition. > > Additionally, I did > > $ nm -C libml.a | grep MPI > > and undefined references to the MPI functions appered as expected. > > > Sorry about my insinstence, but I believe we need to figure out what's > exactly going on. No problem. I agree it is important. Does my explanation above make sense to you? Jed

1 0