March 2020 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Multiple MPICH/fblaslapack Installs For Multiple Arches
by Satish Balay 22 Mar '20

22 Mar '20

As Jed mentioned - I use system blaslapack on linux/ Mac [no need for --download-fblaslapack] on these. And then I have a single install of MPICH in my PATH that I use for all my builds. You can get this with: ./configure --prefix=$HOME/soft/mpich-3.3.2 CFLAGS= COPTFLAGS= FFLAGS= FOPTFLAGS= CXXFLAGS= CXXOPTFLAGS= [and then add $HOME/soft/mpich-3.3.2/bin in PATH] I use ccache differently - not wrap MPI wrappers - but just gcc/g++ $ which gcc /usr/lib64/ccache/gcc If using in-pace install then PETSc configure does not rebuild packages unless the configure options to build that package has changed [or if its installed from git - gitcommit has changed] And its best not to change options to configure - when reusing PETSC_ARCH [however - changes within configure can change some of the default compiler flags or package options - that can result in a rebuild] Satish On Sun, 22 Mar 2020, Jacob Faibussowitsch wrote: > > Do you mean 32-bit/64-bit (pointers) or --with-64-bit-indices=0/1 ? [or do you have --known-64-bit-blas-indices in the mix?] > Sorry, I mean configuring petsc with —with-64-bit-indices=1 here. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > > On Mar 22, 2020, at 4:24 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > Do you mean 32-bit/64-bit (pointers) or --with-64-bit-indices=0/1 ? [or do you have --known-64-bit-blas-indices in the mix?] > > > > Satish > > > > On Sun, 22 Mar 2020, Jacob Faibussowitsch wrote: > > > >> Hello all, > >> > >> As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. > >> > >> My question(s): > >> What petsc ./configure options are necessary to change the configuration of each library w.r.t. petsc? i.e. can my 64-bit arches use my 32-bit MPICH/fblaslapack and vice-versa? Does this change when I have —with-debug on or off? If so, what other packages have a similar ability? Is there anywhere in ./configure —help where this kind of information would be documented? > >> > >> I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. > >> > >> Best regards, > >> > >> Jacob Faibussowitsch > >> (Jacob Fai - booss - oh - vitch) > >> Cell: (312) 694-3391 > >> > >> > >

1 0

Re: [petsc-dev] Multiple MPICH/fblaslapack Installs For Multiple Arches
by Jacob Faibussowitsch 22 Mar '20

22 Mar '20

> Yes on all points regarding MPI and BLAS/Lapack. I recommend installing > a current MPICH and/or Open MPI system-wide, preferably hooked up to > ccache (see replies to this thread: > https://lists.mcs.anl.gov/pipermail/petsc-dev/2020-January/025505.html <https://lists.mcs.anl.gov/pipermail/petsc-dev/2020-January/025505.html>), > as well as BLAS/Lapack system-wide. It's the other packages that are > more likely to depend on int/scalar configuration, but even many of > those (HDF5, SuiteSparse, etc.) aren't built specially for PETSc. Is the home-brew MPICH, openblas, lapack sufficient here? Or is it recommended to build all three from source? Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 22, 2020, at 4:25 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Jacob Faibussowitsch <jacob.fai(a)gmail.com <mailto:[email protected]>> writes: > >> Hello all, >> >> As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. >> >> My question(s): >> What petsc ./configure options are necessary to change the >> configuration of each library w.r.t. petsc? i.e. can my 64-bit arches >> use my 32-bit MPICH/fblaslapack and vice-versa? > > Yes on all points regarding MPI and BLAS/Lapack. I recommend installing > a current MPICH and/or Open MPI system-wide, preferably hooked up to > ccache (see replies to this thread: > https://lists.mcs.anl.gov/pipermail/petsc-dev/2020-January/025505.html <https://lists.mcs.anl.gov/pipermail/petsc-dev/2020-January/025505.html>), > as well as BLAS/Lapack system-wide. It's the other packages that are > more likely to depend on int/scalar configuration, but even many of > those (HDF5, SuiteSparse, etc.) aren't built specially for PETSc. > >> Does this change when I have —with-debug on or off? If so, what other >> packages have a similar ability? Is there anywhere in ./configure >> —help where this kind of information would be documented? >> >> I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391

1 0

Re: [petsc-dev] Multiple MPICH/fblaslapack Installs For Multiple Arches
by Jed Brown 22 Mar '20

22 Mar '20

Jacob Faibussowitsch <jacob.fai(a)gmail.com> writes: > Hello all, > > As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. > > My question(s): > What petsc ./configure options are necessary to change the > configuration of each library w.r.t. petsc? i.e. can my 64-bit arches > use my 32-bit MPICH/fblaslapack and vice-versa? Yes on all points regarding MPI and BLAS/Lapack. I recommend installing a current MPICH and/or Open MPI system-wide, preferably hooked up to ccache (see replies to this thread: https://lists.mcs.anl.gov/pipermail/petsc-dev/2020-January/025505.html) as well as BLAS/Lapack system-wide. It's the other packages that are more likely to depend on int/scalar configuration, but even many of those (HDF5, SuiteSparse, etc.) aren't built specially for PETSc. > Does this change when I have —with-debug on or off? If so, what other > packages have a similar ability? Is there anywhere in ./configure > —help where this kind of information would be documented? > > I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391

1 0

Re: [petsc-dev] Multiple MPICH/fblaslapack Installs For Multiple Arches
by Jacob Faibussowitsch 22 Mar '20

22 Mar '20

> Do you mean 32-bit/64-bit (pointers) or --with-64-bit-indices=0/1 ? [or do you have --known-64-bit-blas-indices in the mix?] Sorry, I mean configuring petsc with —with-64-bit-indices=1 here. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 22, 2020, at 4:24 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > Do you mean 32-bit/64-bit (pointers) or --with-64-bit-indices=0/1 ? [or do you have --known-64-bit-blas-indices in the mix?] > > Satish > > On Sun, 22 Mar 2020, Jacob Faibussowitsch wrote: > >> Hello all, >> >> As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. >> >> My question(s): >> What petsc ./configure options are necessary to change the configuration of each library w.r.t. petsc? i.e. can my 64-bit arches use my 32-bit MPICH/fblaslapack and vice-versa? Does this change when I have —with-debug on or off? If so, what other packages have a similar ability? Is there anywhere in ./configure —help where this kind of information would be documented? >> >> I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >>

1 0

Re: [petsc-dev] Multiple MPICH/fblaslapack Installs For Multiple Arches
by Satish Balay 22 Mar '20

22 Mar '20

Do you mean 32-bit/64-bit (pointers) or --with-64-bit-indices=0/1 ? [or do you have --known-64-bit-blas-indices in the mix?] Satish On Sun, 22 Mar 2020, Jacob Faibussowitsch wrote: > Hello all, > > As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. > > My question(s): > What petsc ./configure options are necessary to change the configuration of each library w.r.t. petsc? i.e. can my 64-bit arches use my 32-bit MPICH/fblaslapack and vice-versa? Does this change when I have —with-debug on or off? If so, what other packages have a similar ability? Is there anywhere in ./configure —help where this kind of information would be documented? > > I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >

1 0

Multiple MPICH/fblaslapack Installs For Multiple Arches
by Jacob Faibussowitsch 22 Mar '20

22 Mar '20

Hello all, As part of development, I have several arch folders lying around in my PETSC_DIR namely a 32-bit OSX, 64-bit OSX, 32-bit linux with valgrind, 64-bit linux with valgrind, and a 32-bit up to date with current master. All of these have a —download-mpich —download-fblaslapack and hence their own copy of each (so that’s 5 copies of each, plus other duplicated packages im sure). At this stage, even getting the bare minimum of these arches ready for dev work after a rebase/git pull takes decades as package versions, or conf settings change, forcing a rebuild of the same packages multiple times. My question(s): What petsc ./configure options are necessary to change the configuration of each library w.r.t. petsc? i.e. can my 64-bit arches use my 32-bit MPICH/fblaslapack and vice-versa? Does this change when I have —with-debug on or off? If so, what other packages have a similar ability? Is there anywhere in ./configure —help where this kind of information would be documented? I suspect that this hasn’t been fully explored since its primarily a developer “problem” and not one the average user will run into/care about (since they usually aren’t building petsc multiple times). I’m sure everyone has their own ways of tackling this problem, I’d love to hear them. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391

1 0

Re: [petsc-dev] lazygit
by Patrick Sanan 21 Mar '20

21 Mar '20

This looks like it could be very helpful, thanks! I usually end up doing these sorts of things (especially partial staging) with GitX, which works well for me but only on OS X, and I'm not sure if anyone is actively developing it anymore. I installed from MacPorts and looks like it's available from lots of other package managers. Am Fr., 20. März 2020 um 22:08 Uhr schrieb Lisandro Dalcin < dalcinl(a)gmail.com>: > Folks, I recommend this terminal-based UI for git: > https://opensource.com/article/20/3/lazygit > > It is quite easy to do line-level stage, amend, rebase, fixup/squash, > cherry-pick, etc. all without leaving the terminal. > > In https://github.com/jesseduffield/lazygit/releases, you can download a > statically-linked binary (a bit heavy, ~ 15MB), just drop it in your ~/bin > or ~/.local/bin, and you are ready to go. > > Profit! > > > > -- > Lisandro Dalcin > ============ > Research Scientist > Extreme Computing Research Center (ECRC) > King Abdullah University of Science and Technology (KAUST) > http://ecrc.kaust.edu.sa/ >

1 0

Re: [petsc-dev] petsc release plan for march/2020
by Satish Balay 20 Mar '20

20 Mar '20

An update: https://gitlab.com/petsc/petsc/-/merge_requests?milestone_title=v3.13-relea… We have a week to go. And have about 47 MRs, with 12 marked as 'v3.13-release' milestone. Likely the milestone is not correctly set for some MRs - if so - please update the MR. And I see some MRs with significant code changes. Hopefully we can process them early [and not have large changes close to freeze date]. Satish On Fri, 13 Mar 2020, Satish Balay via petsc-dev wrote: > All, > > We are to make a petsc release by the end of March. > > For this release [3.13], will work with the following dates: > > - feature freeze: March 27 say 5PM EST > - release: March 29 > > Merges after freeze should contain only fixes that would normally be acceptable to maint workflow. > > I've changed the current milestone 'v3.13' to 'master' and created a new one 'v3.13-release' > > If you are working on a MR with the goal of merging before release - its best to use 'v3.13-release' tag with the MR. > > And it would be good to avoid merging large changes at the last minute. And not have merge requests stuck in need of reviews, testing and other necessary tasks. > > And I would think the testing/CI resources would get stressed in this timeframe - so it would be good to use them judiciously if possible. > > - if there are failures in stage-2 or 3 - and its no longer necessary to complete all the jobs - one can 'cancel' the pipeline. > - if a fix needs to be tested - one can first test with only the failed jobs (if this is known) - before doing a full test pipeline. i.e: > - start pipeline > - immediately cancel the pipeline > - now toggle only the jobs that need to be run > - [on success of the selected jobs] if one wants to run the full pipeleine - click 'retry' - and the remaining canceled jobs should now get scheduled. > > thanks, > Satish >

1 0

Re: [petsc-dev] Unions of IS and MatNest
by Lawrence Mitchell 20 Mar '20

20 Mar '20

On Fri, 20 Mar 2020 at 21:07, Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > > > On 19 Mar 2020, at 7:56 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Fri, Mar 13, 2020 at 11:20 AM Pierre Jolivet < > pierre.jolivet(a)enseeiht.fr> wrote: > >> >> >> On 13 Mar 2020, at 2:36 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> On Fri, Mar 13, 2020 at 3:19 AM Pierre Jolivet < >> pierre.jolivet(a)enseeiht.fr> wrote: >> >>> >>> >>> On 12 Mar 2020, at 11:40 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >>> >>> On Thu, Mar 12, 2020 at 5:59 PM Jed Brown <jed(a)jedbrown.org> wrote: >>> >>>> Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> writes: >>>> >>>> > Hello, >>>> > Has there been any follow-up on this >>>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html >>>> < >>>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html >>>> >? >>>> > Given a 3x3 MatNest A = [A_00,0,0 ; 0,A_11,0 ; 0,0,A_22], I’d like to >>>> setup a two-way fieldsplit coupling [A_00,0 ; 0,A_11] and [A_22] but I >>>> can’t figure out the proper options. >>>> >>>> Are you looking for a Schur split or additive/multiplicative? >>> >>> >>> Don’t know yet which will perform best, do you have a specific solution >>> in mind for one scenario or the other? >>> I was mostly wondering if it was possible in a general context, not >>> taking -pc_fieldsplit_type into account. >>> >>> -pc_fieldsplit_field_0 0,1 -pc_fieldsplit_field_1 2 -pc_fieldsplit_type >>> schur >>> >>> >>> These flags, used with my .cpp, yield: >>> [0]PETSC ERROR: Arguments are incompatible >>> [0]PETSC ERROR: To use Schur complement preconditioner you must have >>> exactly 2 fields >>> If I use -pc_fieldsplit_%d_fields <a,b,..> as advocated in the manual >>> (instead of -pc_fieldsplit_field_%d as you suggested), I get the same error. >>> >> >> Okay it is -pc_fieldsplit_%d_fields. When you use this, how many fields >> does it think you have? >> >> >> Three. >> In case it’s not clear, the MWE is at the bottom of my first email >> (nest.cpp). >> $ mpicxx nest.cpp -I$PETSC_DIR/$PETSC_ARCH/include -I$PETSC_DIR/include >> -L$PETSC_DIR/$PETSC_ARCH/lib -lpetsc >> $ ./a.out -pc_type fieldsplit -pc_fieldsplit_0_fields 0,1 >> -pc_fieldsplit_1_fields 2 -pc_fieldsplit_type schur >> […] >> [0]PETSC ERROR: Arguments are incompatible >> [0]PETSC ERROR: To use Schur complement preconditioner you must have >> exactly 2 fields >> […] >> Split info: >> Split number 0 Defined by IS >> Split number 1 Defined by IS >> Split number 2 Defined by IS >> […] >> > > I see now. If you call PCFieldsplitSetIS(), this overrides anything else. > We do not even try to discover the split. If you want > a split determined by command line arguments, you have to defer the split. > It looks like it can get splits from the MatNest, > so just do not call SetIS(). > > > So, I’ve commented the three PCFieldSplitSetIS. > $ ./a.out -pc_type fieldsplit -pc_fieldsplit_0_fields 0,1 > -pc_fieldsplit_1_fields 2 -pc_fieldsplit_block_size 3 > is starting to give me something meaningful in the KSPView, i.e.: > […] > Split number 0 Fields 0, 1 > […] > Split number 1 Fields 2 > But it’s surrounded by a bunch of errors such as: > [0]PETSC ERROR: Arguments are incompatible > [0]PETSC ERROR: Could not find index set > > Do I need some other command-line options? > If you have a flat 3x3 matnest, the index set matching will not find a subset that is anything other than a 1-field split. I have a patch lying around that i think fixes this. I can try and dig it out on Monday. Lawrence >

1 0

Re: [petsc-dev] Unions of IS and MatNest
by Pierre Jolivet 20 Mar '20

20 Mar '20

> On 19 Mar 2020, at 7:56 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Fri, Mar 13, 2020 at 11:20 AM Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: > > >> On 13 Mar 2020, at 2:36 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >> >> On Fri, Mar 13, 2020 at 3:19 AM Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> wrote: >> >> >>> On 12 Mar 2020, at 11:40 PM, Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> wrote: >>> >>> On Thu, Mar 12, 2020 at 5:59 PM Jed Brown <jed(a)jedbrown.org <mailto:[email protected]>> wrote: >>> Pierre Jolivet <pierre.jolivet(a)enseeiht.fr <mailto:[email protected]>> writes: >>> >>> > Hello, >>> > Has there been any follow-up on this https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html <https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html> <https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html <https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html>>? >>> > Given a 3x3 MatNest A = [A_00,0,0 ; 0,A_11,0 ; 0,0,A_22], I’d like to setup a two-way fieldsplit coupling [A_00,0 ; 0,A_11] and [A_22] but I can’t figure out the proper options. >>> >>> Are you looking for a Schur split or additive/multiplicative? >> >> Don’t know yet which will perform best, do you have a specific solution in mind for one scenario or the other? >> I was mostly wondering if it was possible in a general context, not taking -pc_fieldsplit_type into account. >> >>> -pc_fieldsplit_field_0 0,1 -pc_fieldsplit_field_1 2 -pc_fieldsplit_type schur >> >> These flags, used with my .cpp, yield: >> [0]PETSC ERROR: Arguments are incompatible >> [0]PETSC ERROR: To use Schur complement preconditioner you must have exactly 2 fields >> If I use -pc_fieldsplit_%d_fields <a,b,..> as advocated in the manual (instead of -pc_fieldsplit_field_%d as you suggested), I get the same error. >> >> Okay it is -pc_fieldsplit_%d_fields. When you use this, how many fields does it think you have? > > Three. > In case it’s not clear, the MWE is at the bottom of my first email (nest.cpp). > $ mpicxx nest.cpp -I$PETSC_DIR/$PETSC_ARCH/include -I$PETSC_DIR/include -L$PETSC_DIR/$PETSC_ARCH/lib -lpetsc > $ ./a.out -pc_type fieldsplit -pc_fieldsplit_0_fields 0,1 -pc_fieldsplit_1_fields 2 -pc_fieldsplit_type schur > […] > [0]PETSC ERROR: Arguments are incompatible > [0]PETSC ERROR: To use Schur complement preconditioner you must have exactly 2 fields > […] > Split info: > Split number 0 Defined by IS > Split number 1 Defined by IS > Split number 2 Defined by IS > […] > > I see now. If you call PCFieldsplitSetIS(), this overrides anything else. We do not even try to discover the split. If you want > a split determined by command line arguments, you have to defer the split. It looks like it can get splits from the MatNest, > so just do not call SetIS(). So, I’ve commented the three PCFieldSplitSetIS. $ ./a.out -pc_type fieldsplit -pc_fieldsplit_0_fields 0,1 -pc_fieldsplit_1_fields 2 -pc_fieldsplit_block_size 3 is starting to give me something meaningful in the KSPView, i.e.: […] Split number 0 Fields 0, 1 […] Split number 1 Fields 2 But it’s surrounded by a bunch of errors such as: [0]PETSC ERROR: Arguments are incompatible [0]PETSC ERROR: Could not find index set Do I need some other command-line options? Thanks, Pierre > Thanks, > > Matt > > Thanks, > Pierre > >> Matt >>> I believe. >>> >>> Matt >>> >>> > Jed, in this answer https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html <https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html><https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html <https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html>>, you recommend not to use MatNest. What would you recommend instead? >>> >>> See src/snes/examples/tutorials/ex28.c for my preferred approach. >> >> I’m not using DM, so in terms of Mat, I guess this example shows that I pretty much need to reimplement the field splitting myself? >> >> Thanks, >> Pierre >> >>> -- >>> 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 >>> >>> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> >> >> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> > > > -- > 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 > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0