July 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Problematic Merge of FieldSplit
by Dmitry Karpeev 06 Jul '12

06 Jul '12

I have the following problem with the prefix choice for the MatSchurComplement KSP introduced in this changeset ( http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0d4ccb990bb8) I'm talking about the "inner" KSP for A00, effecting inv(A00) in the definition S = A11 - A10 inv(A00) A01. We also have the "outer" inv(A00) KSP, which gets prefix "0". I recently set the "inner" inv(A00) KSP prefix to "0", simply by inheriting it from the "outer" solver. Now, it is completely reasonable to expect the inner and outer A00 KSPs to have different prefixes so that they can be configured differently. In fact, there was a recent petsc-users request related to this ( http://lists.mcs.anl.gov/pipermail/petsc-users/2012-June/014005.html) However, currently the inner A00 KSP inherits the prefix from the A11 KSP corresponding to the "1" field. With this prefix choice I end up configuring inv(A00) and inv(S) identically, which isn't what I want at all. I'm not sure what the right approach is, but the current one doesn't work for me. Note also that if A00 is treated with a recursive split, there may be numerous options for the A00 KSP. Do we want to repeat them for the inner and outer KSPs, if we want to configure them identically? It's automatic, if the two A00 KSPs share a prefix. Again, this takes away some flexibility, so maybe it's not the best solution, but I think retaining a simple option for using identical configurations is also highly desirable. Any ideas on how to handle this? Dmitry. On Tue, Jun 26, 2012 at 6:13 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > It turns out that 'hg rollback' during an 'hg rebase' does not do what I > thought it did. I think > everything is cleaned up with this push, but if you made FS changes in the > past month, please > check that it is doing what you want with prefixes, etc. > > Now, nested fieldsplits from the command line work, ala > > -ksp_type fgmres > -pc_type fieldsplit -pc_fieldsplit_type additive > -pc_fieldsplit_0_fields 0,1 > -fieldsplit_0_pc_type fieldsplit > -fieldsplit_0_pc_fieldsplit_type schur > -fieldsplit_0_pc_fieldsplitschur_factorization_type full > -fieldsplit_0_fieldsplit_velocity_ksp_type preonly > -fieldsplit_0_fieldsplit_velocity_pc_type lu > -fieldsplit_0_fieldsplit_pressure_ksp_rtol 1e-10 > -fieldsplit_0_fieldsplit_pressure_pc_type jacobi > -pc_fieldsplit_1_fields 2 > -fieldsplit_temperature_ksp_type preonly > -fieldsplit_temperature_pc_type lu > > A split with only one field gets the field name, and otherwise a split > number. > > 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

be careful passing parallel MPI_Comm to SETERRQ()
by Barry Smith 05 Jul '12

05 Jul '12

Consider the following code: ierr = ISSorted(iscol[i], &sorted); CHKERRQ(ierr); if (!sorted) SETERRQ1(((PetscObject)iscol[i])->comm, PETSC_ERR_SUP, "Column index set %D not sorted", i); ISSorted() is not a collective operation and just determines if the local part of the IS is sorted. Hence some processes in comm may return true and some may return false. In this situation you CANNOT call SETERRQ() with that collective comm. You must call it with PETSC_COMM_SELF You can ONLY CALL SETERRQ with a collective comm if you know with absolute certainty that all processes in the comm will be calling it. Barry

1 0

Re: [petsc-dev] who did this?
by Matthew Knepley 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 4:43 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 5, 2012 at 2:40 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > >> I just do regexp. >> > > Okay, are you missing these sort and grep parts? (regexen are so > fragile...) > I just get out the args+# procs and output file > > >> >> >>> I like the semantic information of having multiple tests using the same >>> base options and/or comparing to the same output (rather than normalizing >>> when you specify the tests). >>> >> >> Shell is not the place for that. Years of putting crapy shell into >> makefiles before having to pull it out >> should have taught us something. >> > > I agree, but if we can automatically parse those, we can replace them > wholesale with something better. > I think this is overkill. There were only 2 of these in Vec and 3 in SNES (I think) 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: [petsc-dev] who did this?
by Jed Brown 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 2:40 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > I just do regexp. > Okay, are you missing these sort and grep parts? (regexen are so fragile...) > > >> I like the semantic information of having multiple tests using the same >> base options and/or comparing to the same output (rather than normalizing >> when you specify the tests). >> > > Shell is not the place for that. Years of putting crapy shell into > makefiles before having to pull it out > should have taught us something. > I agree, but if we can automatically parse those, we can replace them wholesale with something better.

1 0

Re: [petsc-dev] who did this?
by Matthew Knepley 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 4:27 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 5, 2012 at 2:22 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > >> Are you just running make targets from Python or are you trying to parse >>> all the make tests into a richer (and more compact) Python representation? >>> >> >> The latter. > > > Right, so you need to interpret a little bit of shell, at least to the > extent of expanding some variables and determining which output file to > test against. Also, there are some examples that | sort or | grep -v, so > you may need to recognize that. > I just do regexp. > I like the semantic information of having multiple tests using the same > base options and/or comparing to the same output (rather than normalizing > when you specify the tests). > Shell is not the place for that. Years of putting crapy shell into makefiles before having to pull it out should have taught us something. 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: [petsc-dev] who did this?
by Jed Brown 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 2:22 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > Are you just running make targets from Python or are you trying to parse >> all the make tests into a richer (and more compact) Python representation? >> > > The latter. Right, so you need to interpret a little bit of shell, at least to the extent of expanding some variables and determining which output file to test against. Also, there are some examples that | sort or | grep -v, so you may need to recognize that. I like the semantic information of having multiple tests using the same base options and/or comparing to the same output (rather than normalizing when you specify the tests).

1 0

Re: [petsc-dev] who did this?
by Matthew Knepley 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 4:14 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 5, 2012 at 2:09 PM, Matthew Knepley <knepley(a)gmail.com>wrote: >> >> There is no way I am parsing shell code. The aim should be to eliminate >> all shell code > > > Are you just running make targets from Python or are you trying to parse > all the make tests into a richer (and more compact) Python representation? > The latter. 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: [petsc-dev] who did this?
by Jed Brown 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 2:09 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > There is no way I am parsing shell code. The aim should be to eliminate > all shell code Are you just running make targets from Python or are you trying to parse all the make tests into a richer (and more compact) Python representation?

1 0

Re: [petsc-dev] who did this?
by Matthew Knepley 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 3:54 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 5, 2012 at 12:06 PM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> I unrolled the shell loop so that the shell code can be processed by >> Python, and eventually converted to Python tests. > > > This might be useful for lexing the shell commands. > > http://docs.python.org/library/shlex.html > > Is it that hard for Python to interpret enumerated for loops? > There is no way I am parsing shell code. The aim should be to eliminate all shell code 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: [petsc-dev] who did this?
by Jed Brown 05 Jul '12

05 Jul '12

On Thu, Jul 5, 2012 at 12:06 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > I unrolled the shell loop so that the shell code can be processed by > Python, and eventually converted to Python tests. This might be useful for lexing the shell commands. http://docs.python.org/library/shlex.html Is it that hard for Python to interpret enumerated for loops?

1 0