May 2015 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Deprecated MPI functions
by Barry Smith 20 May '15

20 May '15

Great > On May 20, 2015, at 7:54 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> I have no problem with someone making a branch that goes through the >> code and replaces all deprecated versions with their replacements >> and then submits it to the code review process (which, of course, >> means putting the code in next and then putting it into master >> :-)). I don't have any particular interest in doing this >> non-productive work myself. > > We've had MPI_Type_create_resized (an MPI-2 feature) in 'next' for a > couple months now and to my knowledge, the only complaints have been > From the MPICH1 test. Meanwhile, building with current Open MPI spews > deprecation warnings. I'd be happy to make a branch that upgrades > everything to MPI-2.0 (upgrading MPIUNI is probably the most involved > part). It actually allows removal of lots of #ifdefs and workarounds -- > MPI_IN_PLACE is always defined, the type handling in SF is always valid, > MPI_Init_thread is always available, and the window code in vpscat.c is > always okay, etc.

1 0

Re: [petsc-dev] Deprecated MPI functions
by Jed Brown 20 May '15

20 May '15

Barry Smith <bsmith(a)mcs.anl.gov> writes: > I have no problem with someone making a branch that goes through the > code and replaces all deprecated versions with their replacements > and then submits it to the code review process (which, of course, > means putting the code in next and then putting it into master > :-)). I don't have any particular interest in doing this > non-productive work myself. We've had MPI_Type_create_resized (an MPI-2 feature) in 'next' for a couple months now and to my knowledge, the only complaints have been From the MPICH1 test. Meanwhile, building with current Open MPI spews deprecation warnings. I'd be happy to make a branch that upgrades everything to MPI-2.0 (upgrading MPIUNI is probably the most involved part). It actually allows removal of lots of #ifdefs and workarounds -- MPI_IN_PLACE is always defined, the type handling in SF is always valid, MPI_Init_thread is always available, and the window code in vpscat.c is always okay, etc.

1 0

Re: [petsc-dev] Generating debugging symbols for examples on OSX
by Dmitry Karpeyev 18 May '15

18 May '15

Thanks! On Mon, May 18, 2015 at 1:07 PM Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > make ex1 RM=true > > > > On May 18, 2015, at 12:57 PM, Dmitry Karpeyev <karpeev(a)mcs.anl.gov> > wrote: > > > > When I build examples, the .o gets automatically removed and dsymutil > isn't run on the executable (which probably wouldn't do any good without > the object file, anyway). As a result, I don't get any debugging symbols > in main() and other subroutines that live in exXXX.c. I can hack around > this, but what's the automatic way of doing this? I didn't see anything > relevant in ./configure --help. > > > > Thanks. > > Dmitry. > >

1 0

Re: [petsc-dev] Generating debugging symbols for examples on OSX
by Barry Smith 18 May '15

18 May '15

make ex1 RM=true > On May 18, 2015, at 12:57 PM, Dmitry Karpeyev <karpeev(a)mcs.anl.gov> wrote: > > When I build examples, the .o gets automatically removed and dsymutil isn't run on the executable (which probably wouldn't do any good without the object file, anyway). As a result, I don't get any debugging symbols in main() and other subroutines that live in exXXX.c. I can hack around this, but what's the automatic way of doing this? I didn't see anything relevant in ./configure --help. > > Thanks. > Dmitry.

1 0

Generating debugging symbols for examples on OSX
by Dmitry Karpeyev 18 May '15

18 May '15

When I build examples, the .o gets automatically removed and dsymutil isn't run on the executable (which probably wouldn't do any good without the object file, anyway). As a result, I don't get any debugging symbols in main() and other subroutines that live in exXXX.c. I can hack around this, but what's the automatic way of doing this? I didn't see anything relevant in ./configure --help. Thanks. Dmitry.

1 0

Re: [petsc-dev] PETSC_COMM_WORLD declaration
by Matthew Knepley 18 May '15

18 May '15

On Sun, May 17, 2015 at 11:30 PM, Marco Zocca <zocca.marco(a)gmail.com> wrote: > What does this declaration in petscsys.h do? > > What type and value does PETSC_COMM_WORLD expand to? > The type is MPI_Comm. If you mean what basic type, that is up to the MPI implementation. However, I think you can assume that it fits in a (void *). The value is obtained at runtime from MPI_Comm_dup or from user input. Thanks, Matt > #define PETSC_EXTERN extern PETSC_VISIBILITY_PUBLIC > > PETSC_EXTERN MPI_Comm PETSC_COMM_WORLD; > > > Thank you in advance, > Marco > -- 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

PETSC_COMM_WORLD declaration
by Marco Zocca 17 May '15

17 May '15

What does this declaration in petscsys.h do? What type and value does PETSC_COMM_WORLD expand to? #define PETSC_EXTERN extern PETSC_VISIBILITY_PUBLIC PETSC_EXTERN MPI_Comm PETSC_COMM_WORLD; Thank you in advance, Marco

1 0

Re: [petsc-dev] FFI trouble in instancing Vec's
by Matthew Knepley 16 May '15

16 May '15

On Sat, May 16, 2015 at 3:25 AM, Marco Zocca <zocca.marco(a)gmail.com> wrote: > I have wrapped a couple of elementary Vec allocation functions which > typecheck in the host language but are not seemingly accepted by the > library. > In the host language, I called "VecCreate" on communicator 1, then > used VecSet to set it to value 1.0 . > You have to give a valid MPI communicator, not a random integer. Thanks, Matt > What do errors #1 to #4 mean? > In particular, error #4 points to this line in rvector.c : > PetscValidHeaderSpecific(x,VEC_CLASSID,1); > > Which one is parameter #1 referred to by "Null Object" ? Does "Null > argument" in the line before refer to the same error as the Null > Object? And, how may I fix it? > > > [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [0]PETSC ERROR: Null argument, when expecting valid pointer > [0]PETSC ERROR: Null Object: Parameter # 1 > [0]PETSC ERROR: Petsc Release Version 3.5.3, Jan, 31, 2015 > [0]PETSC ERROR: Configure options --with-cc=gcc --with-cxx=g++ > --with-fc=gfortran --with-shared-libraries=1 --download-mpich > --download-fblaslapack > > [0]PETSC ERROR: #1 PetscCommDuplicate() line 140 in > /Users/ocramz/petsc-3.5.3/src/sys/objects/tagm.c > [0]PETSC ERROR: #2 PetscHeaderCreate_Private() line 59 in > /Users/ocramz/petsc-3.5.3/src/sys/objects/inherit.c > [0]PETSC ERROR: #3 VecCreate() line 37 in > /Users/ocramz/petsc-3.5.3/src/vec/vec/interface/veccreate.c > [0]PETSC ERROR: #4 VecSet() line 569 in > /Users/ocramz/petsc-3.5.3/src/vec/vec/interface/rvector.c > -- 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

FFI trouble in instancing Vec's
by Marco Zocca 16 May '15

16 May '15

I have wrapped a couple of elementary Vec allocation functions which typecheck in the host language but are not seemingly accepted by the library. In the host language, I called "VecCreate" on communicator 1, then used VecSet to set it to value 1.0 . What do errors #1 to #4 mean? In particular, error #4 points to this line in rvector.c : PetscValidHeaderSpecific(x,VEC_CLASSID,1); Which one is parameter #1 referred to by "Null Object" ? Does "Null argument" in the line before refer to the same error as the Null Object? And, how may I fix it? [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: Null argument, when expecting valid pointer [0]PETSC ERROR: Null Object: Parameter # 1 [0]PETSC ERROR: Petsc Release Version 3.5.3, Jan, 31, 2015 [0]PETSC ERROR: Configure options --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --with-shared-libraries=1 --download-mpich --download-fblaslapack [0]PETSC ERROR: #1 PetscCommDuplicate() line 140 in /Users/ocramz/petsc-3.5.3/src/sys/objects/tagm.c [0]PETSC ERROR: #2 PetscHeaderCreate_Private() line 59 in /Users/ocramz/petsc-3.5.3/src/sys/objects/inherit.c [0]PETSC ERROR: #3 VecCreate() line 37 in /Users/ocramz/petsc-3.5.3/src/vec/vec/interface/veccreate.c [0]PETSC ERROR: #4 VecSet() line 569 in /Users/ocramz/petsc-3.5.3/src/vec/vec/interface/rvector.c

1 0

Re: [petsc-dev] Fwd: [petsc-users] configure error on Titan with Intel
by Mark Adams 15 May '15

15 May '15

> > > > Also you can try --with-cxxlib-autodetect=1 - and see if it works. > > That worked, thanks. > Satish > > On Thu, 14 May 2015, Mark Adams wrote: > > > We have Titan working but we have a problem that we need lstdc++ to get > > PETSc to configure. Otherwise it fails to build fortran. This seems to > > only be needed for GNU. This is for PGI. If we remove this C++ works, > > otherwise there is a missing external. I guess I can just deploy two > > version, on for fortran and one for C++ (I have a C++ and a fortran code > > that I support). > > > > > > On Tue, May 12, 2015 at 9:36 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > Remind me again how much the US tax payers spend on this machine each > > > year. > > > > > > > > > Begin forwarded message: > > > > > > *From: *Mark Adams <mfadams(a)lbl.gov> > > > *Subject: **Re: [petsc-users] configure error on Titan with Intel* > > > *Date: *May 12, 2015 at 11:12:55 AM CDT > > > *To: *Barry Smith <bsmith(a)mcs.anl.gov> > > > *Cc: *Jed Brown <jed(a)jedbrown.org>, petsc-users < > petsc-users(a)mcs.anl.gov>, > > > "David Trebotich" <treb(a)lbl.gov>, "D'Azevedo, Ed F." < > dazevedoef(a)ornl.gov> > > > > > > > > > > > >> Notes: ./configure ran fine and detected -lhwloc in some standard > > >> system install location under normal circumstances it couldn't just > > >> disappear for a different example. > > >> > > >> > > > I configured in an interactive shell, so on a compute node. I tried to > > > 'make ex56' on a login node, as usual. So I am guessing that it would > have > > > worked if I had made it a compute node. They have an inconstancy, I'm > > > guessing. I can try it all on a compute node .... > > > > > > Mark > > > > > > > > >> > > >> > / > > >> > > > >> > On Fri, May 8, 2015 at 5:51 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > >> > Satish Balay <balay(a)mcs.anl.gov> writes: > > >> > > > >> > > Also - Perhaps with intel compilers - the recommended blas is > > >> > > something other than ACML? [like MKL?]. Something to check.. > > >> > > > >> > MKL (and anything built using the Intel compiler) has the "run > slower on > > >> > AMD" feature. For any given operation, ACML won't necessarily be > > >> > faster, but at least it's not intentionally crippled. For most of > what > > >> > PETSc does, any such MKL/ACML difference is irrelevant. > > >> > > > >> > <configure.log><make.log> > > >> > > >> > > > > > > > > > >

1 0