Re: [petsc-users] Fieldsplit with sub pc MUMPS in parallel

There is something wrong with your set up. 1 process total: nonzeros=140616, allocated nonzeros=140616 total: nonzeros=68940, allocated nonzeros=68940 total: nonzeros=3584, allocated nonzeros=3584 total: nonzeros=1000, allocated

Re: [petsc-users] Fwd: Fieldsplit with sub pc MUMPS in parallel

Dave, When I run your example with what I think are the same options I do get the same convergence independent of processes (with exact solvers) ./ex42 -stokes_pc_type fieldsplit -stokes_ksp_monitor -stokes_fieldsplit_u_pc_type lu -stokes_fieldsplit_p_pc_type lu

Re: [petsc-users] a question on DMPlexSetAnchors

On Tue, Jan 3, 2017 at 4:02 PM, Rochan Upadhyay wrote: > I think I sent my previous question (on Dec 28th) to the wrong place > (petsc-users-requ...@mcs.anl.gov). > Yes, this is the correct mailing list. > To repeat, > > I am having bit of a difficulty in understanding the

Re: [petsc-users] Fwd: Fieldsplit with sub pc MUMPS in parallel

> On Jan 4, 2017, at 4:06 PM, Dave May wrote: > > The issue is your fieldsplit_1 solve. You are applying mumps to an > approximate Schur complement - not the true Schur complement. Seemingly the > approximation is dependent on the communicator size. Yes, but why

Re: [petsc-users] VecSetSizes hangs in MPI

Thanks i had no idea how to debug and read those logs, that solved this issue at least (i was sending a message from root to everyone else, but trying to catch from everyone else including root) Until next time, many thanks, Manuel On Wed, Jan 4, 2017 at 3:23 PM, Matthew Knepley

Re: [petsc-users] VecSetSizes hangs in MPI

On Wed, Jan 4, 2017 at 5:21 PM, Manuel Valera wrote: > I did a PetscBarrier just before calling the vicariate routine and im > pretty sure im calling it from every processor, code looks like this: > >From the gdb trace. Proc 0: Is in some MPI routine you call yourself,

Re: [petsc-users] VecSetSizes hangs in MPI

I did a PetscBarrier just before calling the vicariate routine and im pretty sure im calling it from every processor, code looks like this: call PetscBarrier(PETSC_NULL_OBJECT,ierr) print*,'entering POInit from',rank !call exit() call PetscObjsInit() And output gives: entering POInit

Re: [petsc-users] VecSetSizes hangs in MPI

Are you certain ALL ranks in PETSC_COMM_WORLD call these function(s). These functions cannot be inside if statements like if (rank == 0){ VecCreateMPI(...) } On Wed, 4 Jan 2017 at 23:34, Manuel Valera wrote: > Thanks Dave for the quick answer, appreciate it, > > I just

Re: [petsc-users] VecSetSizes hangs in MPI

On Wed, Jan 4, 2017 at 4:21 PM, Manuel Valera wrote: > Hello all, happy new year, > > I'm working on parallelizing my code, it worked and provided some results > when i just called more than one processor, but created artifacts because i > didn't need one image of the

Re: [petsc-users] VecSetSizes hangs in MPI

> On Jan 4, 2017, at 4:21 PM, Manuel Valera wrote: > > Hello all, happy new year, > > I'm working on parallelizing my code, it worked and provided some results > when i just called more than one processor, but created artifacts because i > didn't need one image of the

Re: [petsc-users] VecSetSizes hangs in MPI

Thanks Dave for the quick answer, appreciate it, I just tried that and it didn't make a difference, any other suggestions ? Thanks, Manuel On Wed, Jan 4, 2017 at 2:29 PM, Dave May wrote: > You need to swap the order of your function calls. > Call VecSetSizes() before

Re: [petsc-users] VecSetSizes hangs in MPI

You need to swap the order of your function calls. Call VecSetSizes() before VecSetType() Thanks, Dave On Wed, 4 Jan 2017 at 23:21, Manuel Valera wrote: Hello all, happy new year, I'm working on parallelizing my code, it worked and provided some results when i just

[petsc-users] VecSetSizes hangs in MPI

Hello all, happy new year, I'm working on parallelizing my code, it worked and provided some results when i just called more than one processor, but created artifacts because i didn't need one image of the whole program in each processor, conflicting with each other. Since the pressure solver is

Re: [petsc-users] Fwd: Fieldsplit with sub pc MUMPS in parallel

The issue is your fieldsplit_1 solve. You are applying mumps to an approximate Schur complement - not the true Schur complement. Seemingly the approximation is dependent on the communicator size. If you want to see iteration counts of 2, independent of mesh size and communicator size you need to

Re: [petsc-users] Fwd: Fieldsplit with sub pc MUMPS in parallel

> I do not understand this behavior : since MUMPS is a parallel direct solver, > shouldn't the solver converge in max 3 iterations whatever the number of > procs? Please add the following options -fieldsplit_0_ksp_type gmres -fieldsplit_0_ksp_pc_side right -fieldsplit_0_ksp_monitor

Re: [petsc-users] pc_gamg_threshol

The manual page gives a high-level description http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PC/PCGAMGSetThreshold.html the exact details can be found in the code here http://www.mcs.anl.gov/petsc/petsc-dev/src/ksp/pc/impls/gamg/util.c.html#PCGAMGFilterGraph I'm adding a

Re: [petsc-users] pc_gamg_threshol

* Any reference to what pc_gamg_treshold means and/or does? On Wed, 2017-01-04 at 18:13 -0300, Jeremy Theler wrote: > Hi! Any reference to what does -pc_gamg_threshold mean and/or? >

[petsc-users] pc_gamg_threshol

Hi! Any reference to what does -pc_gamg_threshold mean and/or? -- Jeremy Theler www.seamplex.com

Re: [petsc-users] TSPseudo overriding SNES iterations

Here is the code in TSCreate_Pseudo() ierr = TSGetSNES(ts,);CHKERRQ(ierr); ierr = SNESGetType(snes,);CHKERRQ(ierr); if (!stype) {ierr = SNESSetType(snes,SNESKSPONLY);CHKERRQ(ierr);} it doesn't really "override" things in SNES, it just sets a different default SNES solver.

Re: [petsc-users] TSPseudo overriding SNES iterations

Thanks for quick reply Barry, that did the trick. While I respect the belief of the anonymous distinguished developer, IMHO it would probably be better for things in TS to not override things in SNES unless necessary. On Jan 4, 2017 2:50 PM, Barry Smith wrote: Mark,

Re: [petsc-users] TSPseudo overriding SNES iterations

Mark, This happens because some distinguished PETSc developer believes that by definition Pseudo transient continuation should not do multiple Newton iterations per "time step". Thus this developer defaulted the nonlinear solver in TSPSEUDO to be KSPONLY which, since it only does a

[petsc-users] TSPseudo overriding SNES iterations

I have an unsteady problem I'm trying to solve for steady state. The regular time-accurate stepping works fine (uses around 5 Newton iterations with 100 krylov iterations each per time step) with beuler stepping. But when changing only TSType to pseudo it looks like SNES max iterations is

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, 4 Jan 2017, Satish Balay wrote: > So I guess your best bet is static libraries.. Or upgrade to intel-17 compilers. Satish --- [balay@el7 benchmarks]$ icc --version icc (ICC) 17.0.1 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. [balay@el7 benchmarks]$

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, 4 Jan 2017, Satish Balay wrote: > BTW - You have: > > Machine platform: > ('Linux', 'marclus4login3', '3.10.0-327.36.3.el7.x86_64', '#1 SMP Mon Oct 24 > 09:16:18 CDT 2016', 'x86_64', 'x86_64') > > > So glibc is updated - but not kernel - so its a partial update? [or > machine not

Re: [petsc-users] problems after glibc upgrade to 2.17-157

BTW - You have: Machine platform: ('Linux', 'marclus4login3', '3.10.0-327.36.3.el7.x86_64', '#1 SMP Mon Oct 24 09:16:18 CDT 2016', 'x86_64', 'x86_64') So glibc is updated - but not kernel - so its a partial update? [or machine not rebooted after a major upgrade (7.2 -> 7.3) ?] I wonder if

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, 4 Jan 2017, Matthew Knepley wrote: > On Wed, Jan 4, 2017 at 9:19 AM, Klaij, Christiaan wrote: > > > Attached is the log for > > > > > > LIBS="-L/cm/shared/apps/intel/compilers_and_libraries_2016. > > 3.210/linux/compiler/lib/intel64_lin -lifcore" > > > Something is

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, Jan 4, 2017 at 9:19 AM, Klaij, Christiaan wrote: > Attached is the log for > > > LIBS="-L/cm/shared/apps/intel/compilers_and_libraries_2016. > 3.210/linux/compiler/lib/intel64_lin -lifcore" > Something is strange with the quotes in this shell. Can you use this instead

Re: [petsc-users] problems after glibc upgrade to 2.17-157

By the way, petsc did compile and install metis and parmetis succesfully before the make error. However, running the newly compiled gpmetis program gives the same segmentation fault! So the original problem was not solved by recompiling, unfortunately. Chris

Re: [petsc-users] problems after glibc upgrade to 2.17-157

So how would I do that? Does LIBS= accept spaces in the string? Something like this perhaps: LIBS="-L/cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin -lifcore" But I'm starting to believe that my intel install is somehow broken. I'm getting these intel

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, Jan 4, 2017 at 7:37 AM, Klaij, Christiaan wrote: > I've tried with: > > > --LIBS=/cm/shared/apps/intel/compilers_and_libraries_2016. > 3.210/linux/compiler/lib/intel64_lin/libifcore.a -lstdc++\\ > This is likely connected to the problem below, but I would have to see

Re: [petsc-users] problems after glibc upgrade to 2.17-157

Our sysadmin says that SL7 does not provide the debug version of glibc. Chris dr. ir. Christiaan Klaij | CFD Researcher | Research & Development MARIN | T +31 317 49 33 44 | c.kl...@marin.nl | www.marin.nl

Re: [petsc-users] Leveraging IIoT & Moving to Zero Unplanned Downtime

Apologies, the email below was not meant to be sent to this list. David On Wed, Jan 4, 2017 at 7:39 AM, Thomas Leurent wrote: > Akselos News > View this email in your browser > > > Dear

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, Jan 4, 2017 at 4:32 AM, Klaij, Christiaan wrote: > Satish, > > I tried your suggestion: > > --with-clib-autodetect=0 --with-fortranlib-autodetect=0 > --with-cxxlib-autodetect=0 LIBS=LIBS=/path_to/libifcore.a > > I guess I don't really need "LIBS= " twice (?) so I've

Re: [petsc-users] problems after glibc upgrade to 2.17-157

On Wed, Jan 4, 2017 at 3:16 AM, Klaij, Christiaan wrote: > Well, a bit clearer perhaps. It seems the relevant ERROR is on > line 31039. So I did this case by hand using the compile and link > lines from the log, then run it in gdb: > > $ pwd >

[petsc-users] Leveraging IIoT & Moving to Zero Unplanned Downtime

Akselos News View this email in your browser (http://us6.campaign-archive2.com/?u=d98ce9bd21c800d407dce9d52=b388563fdf=911b65a822) Dear All, I invite you to read my new post (http://akselos.us6.list-manage1.com/track/click?u=d98ce9bd21c800d407dce9d52=4bf9f07fda=911b65a822) on how coupling the

Re: [petsc-users] problems after glibc upgrade to 2.17-157

Well, a bit clearer perhaps. It seems the relevant ERROR is on line 31039. So I did this case by hand using the compile and link lines from the log, then run it in gdb: $ pwd /tmp/petsc-Q0URwQ/config.setCompilers $ ls confdefs.h conffix.h conftest conftest.F conftest.o $ gdb GNU gdb (GDB) Red