Re: [petsc-dev] asm / gasm

[adding Garth] On Thu, Jun 23, 2016 at 12:52 AM, Barry Smith wrote: > > Mark, > >I think there is a misunderstanding here. With GASM an individual block > problem is __solved__ (via a parallel KSP) in parallel by several > processes, with ASM each block is "owned" by and solved on a single

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Barry Smith writes: > Hmm, both of these links refer to C99 Standard Library they do not refer > to the C99 standard language. Anywhere that says the language standard? To my knowledge, variable length arrays (which are actually quite useful for numerical work, particularly as VLA-pointers)

Re: [petsc-dev] asm / gasm

> On Jun 22, 2016, at 10:20 PM, Mark Adams wrote: > >> >> No joke, Amneet found that PCASM with lots of small subdomains was spending >> a ton of time in view calls. > > (And, of course, Barry fixed it by adding this configure flag --- thanks > Barry!) > > Note that it does not matter wheth

Re: [petsc-dev] asm / gasm

> > > No joke, Amneet found that PCASM with lots of small subdomains was > spending a ton of time in view calls. > > > (And, of course, Barry fixed it by adding this configure flag --- thanks > Barry!) > > Note that it does not matter whether you *use* view or not. > Oh wow. So no view with ASM,

Re: [petsc-dev] asm / gasm

> On Jun 22, 2016, at 7:34 PM, Boyce Griffith wrote: > > > > On Jun 22, 2016, at 6:23 PM, Mark Adams > wrote: > >> >> >> On Wed, Jun 22, 2016 at 8:14 PM, Boyce Griffith > > wrote: >> >>> On Jun 22, 2016, at 2:06 PM, Barry Smith >>

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

On Wed, Jun 22, 2016 at 3:47 PM, Jeff Hammond wrote: > Serious question: > > What are your reasons for using a language that is 27 years old? Terrible > compilers that have not been compliant with the current ISO C for 16 > years? Because MPICH does it? > > Not serious question: > > Do you also

Re: [petsc-dev] asm / gasm

> On Jun 22, 2016, at 6:23 PM, Mark Adams wrote: > > > >> On Wed, Jun 22, 2016 at 8:14 PM, Boyce Griffith >> wrote: >> >>> On Jun 22, 2016, at 2:06 PM, Barry Smith wrote: >>> >>> >>> I suggest focusing on asm. Having blocks that span multiple processes >>> seems like over kill for a

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Barry Smith writes: > Hmm, both of these links refer to C99 Standard Library they do not refer > to the C99 standard language. Anywhere that says the language standard? Good question. It's getting dangerously close to beer o'clock for me but if you have a test, we could just try running that

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Hmm, both of these links refer to C99 Standard Library they do not refer to the C99 standard language. Anywhere that says the language standard? > On Jun 22, 2016, at 6:16 PM, Sean Farley wrote: > > Barry Smith writes: > >>> On Jun 22, 2016, at 5:58 PM, Sean Farley wrote: >>> >>> C Ber

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Barry Smith writes: >> On Jun 22, 2016, at 5:58 PM, Sean Farley wrote: >> >> C Bergström writes: >> >>> Sorry I can't help, but +1 troll on this... >>> >>> On Thu, Jun 23, 2016 at 6:47 AM, Jeff Hammond >>> wrote: Serious question: What are your reasons for using a language

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Google tells me https://msdn.microsoft.com/en-us/library/hh409293.aspx C99 Conformance Visual Studio 2015 fully implements the C99 Standard Library, with the exception of any library that needs to use petsc or other useful features not yet supported by the Visual C++ compiler (for example, is no

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

> On Jun 22, 2016, at 5:58 PM, Sean Farley wrote: > > C Bergström writes: > >> Sorry I can't help, but +1 troll on this... >> >> On Thu, Jun 23, 2016 at 6:47 AM, Jeff Hammond wrote: >>> Serious question: >>> >>> What are your reasons for using a language that is 27 years old? Terrible >>>

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

> On Jun 22, 2016, at 5:47 PM, Jeff Hammond wrote: > > Serious question: > > What are your reasons for using a language that is 27 years old? Terrible > compilers that have not been compliant with the current ISO C for 16 years? > Because MPICH does it? Serious answer: Microsoft sto

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

C Bergström writes: > Sorry I can't help, but +1 troll on this... > > On Thu, Jun 23, 2016 at 6:47 AM, Jeff Hammond wrote: >> Serious question: >> >> What are your reasons for using a language that is 27 years old? Terrible >> compilers that have not been compliant with the current ISO C for 16

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Sorry I can't help, but +1 troll on this... On Thu, Jun 23, 2016 at 6:47 AM, Jeff Hammond wrote: > Serious question: > > What are your reasons for using a language that is 27 years old? Terrible > compilers that have not been compliant with the current ISO C for 16 years? > Because MPICH does it

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

We still use ancient compilers for our windows testing.. Satish On Wed, 22 Jun 2016, Jeff Hammond wrote: > Serious question: > > What are your reasons for using a language that is 27 years old? Terrible > compilers that have not been compliant with the current ISO C for 16 > years? Because MP

Re: [petsc-dev] asm / gasm

Mark, I think there is a misunderstanding here. With GASM an individual block problem is __solved__ (via a parallel KSP) in parallel by several processes, with ASM each block is "owned" by and solved on a single process. With both the "block" can come from any unknowns on any processe

Re: [petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Serious question: What are your reasons for using a language that is 27 years old? Terrible compilers that have not been compliant with the current ISO C for 16 years? Because MPICH does it? Not serious question: Do you also use hardware from 1989? Jeff On Wed, Jun 22, 2016 at 7:46 PM, Barry

Re: [petsc-dev] asm / gasm

On Wed, Jun 22, 2016 at 8:14 PM, Boyce Griffith wrote: > > On Jun 22, 2016, at 2:06 PM, Barry Smith wrote: > > > I suggest focusing on asm. Having blocks that span multiple processes > seems like over kill for a smoother ? (Major league overkill) in fact > doesn't one want multiple blocks per

Re: [petsc-dev] asm / gasm

On Wed, Jun 22, 2016 at 8:06 PM, Barry Smith wrote: > >I suggest focusing on asm. OK, I will switch gasm to asm, this does not work anyway. > Having blocks that span multiple processes seems like over kill for a > smoother ? No, because it is a pain to have the math convolved with the p

[petsc-dev] Problem with GAMG

Mark, If I use the hem coarsen type I get this error. Note that I am setting the -pc_gamg_sym_graph true flag I the debugger I do see that PCGAMGFilterGraph() has the sym flag set so it seems to me either 1) the symmetrizer doesn't actually make it symmetric or 2) the detector of lack

Re: [petsc-dev] asm / gasm

> On Jun 22, 2016, at 2:06 PM, Barry Smith wrote: > > > I suggest focusing on asm. Having blocks that span multiple processes seems > like over kill for a smoother ? (Major league overkill) in fact doesn't one > want multiple blocks per process, ie. pretty small blocks. And with lots of sm

Re: [petsc-dev] asm / gasm

I suggest focusing on asm. Having blocks that span multiple processes seems like over kill for a smoother ? (Major league overkill) in fact doesn't one want multiple blocks per process, ie. pretty small blocks. Barry > On Jun 22, 2016, at 7:51 AM, Mark Adams wrote: > > I'm trying to ge

[petsc-dev] NEVER put // into PETSc code. PETSc is C89, the only real C.

Re: [petsc-dev] Bug in MatZeroRows_MPIAIJ

> On Jun 22, 2016, at 1:24 AM, Lisandro Dalcin wrote: > > On 22 June 2016 at 00:30, Barry Smith wrote: >> Why not just remove the first if test (below) and just have the two >> conditions diag != 0.0 and drag == 0.0 >> >> if ((diag != 0.0) && (mat->A->rmap->N == mat->A->cmap->N)) { >>

Re: [petsc-dev] asm / gasm

On Wed, Jun 22, 2016 at 5:13 PM, Matthew Knepley wrote: > On Wed, Jun 22, 2016 at 5:51 AM, Mark Adams wrote: > >> I'm trying to get block smoothers to work for gamg. We (Garth) tried >> this and got this error: >> >> >> - Another option is use '-pc_gamg_use_agg_gasm true' and use >>> '-mg_leve

Re: [petsc-dev] asm / gasm

On Wed, Jun 22, 2016 at 5:51 AM, Mark Adams wrote: > I'm trying to get block smoothers to work for gamg. We (Garth) tried > this and got this error: > > > - Another option is use '-pc_gamg_use_agg_gasm true' and use >> '-mg_levels_pc_type gasm'. >> >> > Running in parallel, I get > > ** Ma

[petsc-dev] asm / gasm

I'm trying to get block smoothers to work for gamg. We (Garth) tried this and got this error: - Another option is use '-pc_gamg_use_agg_gasm true' and use > '-mg_levels_pc_type gasm'. > > Running in parallel, I get ** Max-trans not allowed because matrix is distributed First, what

Re: [petsc-dev] PetscSF regression in maint

False alarm, sorry about the noise. As Stefano pointed out in private email, I have to reconfigure. On 22 June 2016 at 13:51, Lisandro Dalcin wrote: > Trivial Python script creating a periodic 1d plex with 8 segments. The > script runs fine with tag v3.7.2, however it fails with current maint. >

[petsc-dev] PetscSF regression in maint

Trivial Python script creating a periodic 1d plex with 8 segments. The script runs fine with tag v3.7.2, however it fails with current maint. [dalcinl@kw14821 test-dmplex]$ cat mk-plex-1d.py import petsc4py, sys petsc4py.init(sys.argv) from petsc4py import PETSc import numpy as np nel = 8 if PE