Re: [petsc-users] Performance of the Telescope Multigrid Preconditioner

On Thu, Oct 6, 2016 at 7:33 PM, frank wrote: > Dear Dave, > Follow your advice, I solve the identical equation twice and time two > steps separately. The result is below: > > Test: 1024^3 grid points > Cores#reduction factorMG levels#time of 1st solve2nd time >

Re: [petsc-users] printing snes prefix with monitor

Ah, this support was added to KSP but not SNES. We will accept a pull request that adds the support for SNES (in your case you should also most definitely do the indenting Matt suggests). PetscErrorCode SNESMonitorDefault(SNES snes,PetscInt its,PetscReal fgnorm,PetscViewerAndFormat *vf) {

Re: [petsc-users] Question about using MatSNESMFWPSetComputeNormU

If you want to provide your own matrix-free application you use MatCreateShell() and MatShellSetOperation(mat, MATOP_MULT,yourfunction()) See for example src/snes/examples/tests/ex69.c (ignore the business about errorinmatmult) Barry > On Oct 6, 2016, at 9:23 AM, Choi Kyungjun

Re: [petsc-users] large PetscCommDuplicate overhead

Happy to (though Piz Daint goes down for an extended upgrade on Oct 17 so would need to be run before then)! On Thu, Oct 6, 2016 at 6:03 PM, Matthew Knepley wrote: > On Thu, Oct 6, 2016 at 10:55 AM, Barry Smith wrote: >> >> >>Matt, >> >> Thanks for

Re: [petsc-users] large PetscCommDuplicate overhead

Barry Smith writes: >Matt, > > Thanks for this information. It sure looks like there is something > seriously wrong with the MPI_Attr_get() on the cray for non-root > process. Does any PETSc developer have access to such a machine? Yes, we have a NERSC

Re: [petsc-users] large PetscCommDuplicate overhead

On Thu, Oct 6, 2016 at 10:55 AM, Barry Smith wrote: > >Matt, > > Thanks for this information. It sure looks like there is something > seriously wrong with the MPI_Attr_get() on the cray for non-root process. > Does any PETSc developer have access to such a machine? We

Re: [petsc-users] issue with NullSpaceRemove in parallel

Thanks Barry. That seems to have fixed it; I had a NAN somewhere in the RHS. On Wed, Oct 5, 2016 at 11:18 PM, Barry Smith wrote: > > The message "Scalar value must be same on all processes, argument # 2" > comes up often when a Nan or Inf as gotten into the computation.

Re: [petsc-users] large PetscCommDuplicate overhead

Matt, Thanks for this information. It sure looks like there is something seriously wrong with the MPI_Attr_get() on the cray for non-root process. Does any PETSc developer have access to such a machine? We need to write a test program that just calls MPI_Attr_get a bunch of times (no

Re: [petsc-users] Using Petsc with Finite Elements Domain Decomposition

It is almost surely some subtle memory corruption somewhere use http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind to track it down. > On Oct 6, 2016, at 4:22 AM, Ivano Barletta wrote: > > Hello everyone > > Recently I resumed the task of nesting Petsc into >

Re: [petsc-users] large PetscCommDuplicate overhead

Matthew and Barry, 1) I did a direct measurement of PetscCommDuplicate() time by tracing just that call (using CrayPat), and confirmed the sampling results. For 8 processes (n=8), tracing counted a total of 101 calls, taking ~0 time on the root process but taking 11.78 seconds (6.3% of 188 total

Re: [petsc-users] printing snes prefix with monitor

On Thu, Oct 6, 2016 at 9:51 AM, Blaise A Bourdin wrote: > Hi, > > I have a problem with 2 nested snes (i.e. SNESComputeFunction for snes1 > involves a SNESSolve for snes2). > Each snes has a different prefix. The problem is that the SESMonitor won’t > print the SNES prefix, so

[petsc-users] printing snes prefix with monitor

Hi, I have a problem with 2 nested snes (i.e. SNESComputeFunction for snes1 involves a SNESSolve for snes2). Each snes has a different prefix. The problem is that the SESMonitor won’t print the SNES prefix, so that making sense of output can be a bit tricky… Is there a simple way to have each

Re: [petsc-users] Using Petsc with Finite Elements Domain Decomposition

Hello everyone Recently I resumed the task of nesting Petsc into this fem ocean model, for the solution of a linear system I followed your suggestions and "almost" everything works. The problem raised during a run with 4 CPUs, when i got this error 3:[3]PETSC ERROR: -

Re: [petsc-users] petsc init in class constructor

Hello Stefano and Karl, Thanks a lot for your detailed replies. I understand now it is not a good idea to put petscinit in constructor. :-) Best reagards, Feng > On 06 Oct 2016, at 10:44, Stefano Zampini wrote: > > Sorry, > I realized I replied to Feng and not to

Re: [petsc-users] petsc init in class constructor

Sorry, I realized I replied to Feng and not to the list. Below is my previous email. Feng, Your class is fine as long as the constructor of your solver is called AFTER MPI_Init, and the destructor BEFORE MPI_Finalize. This means that you cannot have something like int main (int argc,

Re: [petsc-users] petsc init in class constructor

> > Long story short: I'd encourage you not to initialize PETSc in a constructor, > unless you know exactly what you are doing and can control the possible side > effects. > completely agree on that.

Re: [petsc-users] petsc init in class constructor

Hi, I would like to write a c++ class which solve a linear system with petsc (code as following). Petsc is used only in this class. So I call MPI_Init in main.cpp, but PetscInitialize and PetscFinalise are in constructor/destructor of class. I am wondering if this way is safe? class

[petsc-users] petsc init in class constructor

Hello everyone, I would like to write a c++ class which solve a linear system with petsc (code as following). Petsc is used only in this class. So I call MPI_Init in main.cpp, but PetscInitialize and PetscFinalise are in constructor/destructor of class. I am wondering if this way is safe?

Re: [petsc-users] using DMDA with python

Thanks alot for all of your suggestions. I think I have a better insight about the direction now. On Thu, Oct 6, 2016 at 2:03 AM, Dave May wrote: > > > On 5 October 2016 at 18:49, Matthew Knepley wrote: > >> On Wed, Oct 5, 2016 at 11:19 AM, E. Tadeu