January 2021 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files
by Jose E. Roman 05 Jan '21

05 Jan '21

slepc4py source is not yet included in SLEPc source, but this will be done soon. Jose > El 5 ene 2021, a las 8:30, Barry Smith <bsmith(a)petsc.dev> escribió: > > > Thanks. > > I'd like to move to also building the python bindings for both PETSc and SLEPc by default in the future. Gives better testing and makes it easier for users who shouldn't need to worry about adding obscure options to get the python bindings built. Users should be able to turn off python bindings as opposed to having to turn them on. > > Barry > > >> On Jan 5, 2021, at 1:05 AM, Pierre Jolivet <pierre(a)joliv.et> wrote: >> >> >> >>> On 5 Jan 2021, at 1:33 AM, Barry Smith <bsmith(a)petsc.dev> wrote: >>> >>> >>> For packages that are built after PETSc configure (and or install is done) slepc, hpddm etc we've traditional saved the output in its own file stashed away somewhere. >>> >>> For the CI this is driving me nuts because when they fail the output is essentially "lost" and thus it is impossible to determine what has gone wrong. >>> >>> I have started to directly output in the same stream as the PETSc compiles to make debugging much easier. Generally the packages are relatively small and don't have a huge amount of output when compiling correctly. I did it for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in slepc). >> >> I guess we could change the redirect rule here https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L5… >> But we’d need to check whether slepc4py is built with --download-slepc --download-slepc-configure-arguments="--download-slepc4py” (inside PETSc) or simply --download-slepc4py (inside SLEPc). >> >> I’m in favour of having a single file because it can be quite nightmarish to ask users for multiple .log files hidden in different folders, but I can understand if we stick with the current approach as well. >> >> Thanks, >> Pierre >> >>> Are there any large downsides to this plan? >>> >>> Barry >

1 0

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files
by Barry Smith 05 Jan '21

05 Jan '21

Thanks. I'd like to move to also building the python bindings for both PETSc and SLEPc by default in the future. Gives better testing and makes it easier for users who shouldn't need to worry about adding obscure options to get the python bindings built. Users should be able to turn off python bindings as opposed to having to turn them on. Barry > On Jan 5, 2021, at 1:05 AM, Pierre Jolivet <pierre(a)joliv.et> wrote: > > > >> On 5 Jan 2021, at 1:33 AM, Barry Smith <bsmith(a)petsc.dev <mailto:[email protected]>> wrote: >> >> >> For packages that are built after PETSc configure (and or install is done) slepc, hpddm etc we've traditional saved the output in its own file stashed away somewhere. >> >> For the CI this is driving me nuts because when they fail the output is essentially "lost" and thus it is impossible to determine what has gone wrong. >> >> I have started to directly output in the same stream as the PETSc compiles to make debugging much easier. Generally the packages are relatively small and don't have a huge amount of output when compiling correctly. I did it for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in slepc). > > I guess we could change the redirect rule here https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L53 <https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L53>? > But we’d need to check whether slepc4py is built with --download-slepc --download-slepc-configure-arguments="--download-slepc4py” (inside PETSc) or simply --download-slepc4py (inside SLEPc). > > I’m in favour of having a single file because it can be quite nightmarish to ask users for multiple .log files hidden in different folders, but I can understand if we stick with the current approach as well. > > Thanks, > Pierre > >> Are there any large downsides to this plan? >> >> Barry

1 0

Re: [petsc-dev] builds of PETSc based packages should not get their own secret files
by Pierre Jolivet 05 Jan '21

05 Jan '21

> On 5 Jan 2021, at 1:33 AM, Barry Smith <bsmith(a)petsc.dev> wrote: > > > For packages that are built after PETSc configure (and or install is done) slepc, hpddm etc we've traditional saved the output in its own file stashed away somewhere. > > For the CI this is driving me nuts because when they fail the output is essentially "lost" and thus it is impossible to determine what has gone wrong. > > I have started to directly output in the same stream as the PETSc compiles to make debugging much easier. Generally the packages are relatively small and don't have a huge amount of output when compiling correctly. I did it for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in slepc). I guess we could change the redirect rule here https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L53 <https://gitlab.com/slepc/slepc/-/blob/master/config/packages/slepc4py.py#L53>? But we’d need to check whether slepc4py is built with --download-slepc --download-slepc-configure-arguments="--download-slepc4py” (inside PETSc) or simply --download-slepc4py (inside SLEPc). I’m in favour of having a single file because it can be quite nightmarish to ask users for multiple .log files hidden in different folders, but I can understand if we stick with the current approach as well. Thanks, Pierre > Are there any large downsides to this plan? > > Barry > >

1 0

builds of PETSc based packages should not get their own secret files
by Barry Smith 04 Jan '21

04 Jan '21

For packages that are built after PETSc configure (and or install is done) slepc, hpddm etc we've traditional saved the output in its own file stashed away somewhere. For the CI this is driving me nuts because when they fail the output is essentially "lost" and thus it is impossible to determine what has gone wrong. I have started to directly output in the same stream as the PETSc compiles to make debugging much easier. Generally the packages are relatively small and don't have a huge amount of output when compiling correctly. I did it for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in slepc). Are there any large downsides to this plan? Barry

1 0

Re: [petsc-dev] Testing seems broken in master
by Scott Kruger 04 Jan '21

04 Jan '21

Yes.ï¿½ There are test cases where a cast is done so for those. Scott On 1/4/21 10:29 AM, Satish Balay wrote: > hm - indices are integers and its not ignored (i.e %d) - only the %f and %e diff is ignored (by default) > > Satish > > On Mon, 4 Jan 2021, Scott Kruger wrote: > >> >> >> Is this just the 3rd problem? >> >> Regarding how you can end up with changes not being caught: >> The default (going all the way back to the old harness) is to not check >> numbers to avoid round-off errors giving false negatives (failures). >> Of course, sometimes you *want* to check the numbers; e.g., for indices.ï¿½ The >> solution for this is to add: >> >> ï¿½ï¿½ï¿½ï¿½ diff_args: -j >> >> Scott >> >> On 12/31/20 4:40 PM, Barry Smith wrote: >>> ï¿½ I think I have it "fixed" now in the branch, once it passes the pipeline I >>> will shepard it through the MR quickly. Sorry about this, even all our CI >>> testing can miss a great deal. >>> >>> ï¿½ Barry >>> >>> >>> >>>> On Dec 31, 2020, at 2:44 PM, Barry Smith <bsmith(a)petsc.dev >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> ï¿½ This is a different (3rd) problem. Funny it didn't bother anyone for two >>>> months. >>>> >>>> ï¿½ Fix is in barry/2020-12-29/fix-petscdiff-bracket but the pipeline keeps >>>> failing ts_tutorials_advection-diffusion-reaction-ex3_2 fails on different >>>> machines with slightly different counts. I don't see how this change could >>>> cause that! But gets old results on my machine. Very frustrating. >>>> Barry >>>> >>>>> On Dec 31, 2020, at 1:02 PM, Matthew Knepley <knepley(a)gmail.com >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> On Thu, Dec 31, 2020 at 1:48 PM Barry Smith <bsmith(a)petsc.dev >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> ï¿½ So the programs output changes and should no longer match that >>>>> in the output/* file yet the test harness does not error with a >>>>> statement that the two outputs do not match? >>>>> >>>>> ï¿½ ï¿½I noticed the gmakegentest.py is not being run before it runs >>>>> the test? Does this mean it is just running all the old stuff >>>>> which does match fine? >>>>> >>>>> ï¿½ ï¿½Then either how petscdiff is called by the test harness has >>>>> changed or petscdiff has changed and does not detect changes >>>>> anymore >>>>> >>>>> ï¿½ ï¿½BTW: I always use -f ./gmakefile.test test not just the gmakefile >>>>> >>>>> ï¿½ ï¿½All the PETSc changes are trivial and can be seen with a >>>>> simple diff, it is hard to believe they would cause this >>>>> behavior but I guess they must. >>>>> >>>>> ï¿½ ï¿½You can go to PETSC_ARCH/tests/snes/tests and run the ex13 >>>>> shell script directly. >>>>> >>>>> >>>>> It is the sed problem: >>>>> >>>>> master *$:/PETSc3/petsc/petsc-dev$ >>>>> /PETSc3/petsc/petsc-dev/lib/petsc/bin/petscdiff >>>>> /PETSc3/petsc/petsc-dev/src/snes/tests/output/ex13_bench.out >>>>> ex13_bench.tmp >>>>> >>>>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) >>>>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) >>>>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) >>>>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) >>>>> >>>>> The error was getting eaten. >>>>> >>>>> This is in current master. Is it fixed in a branch? >>>>> >>>>> ï¿½ ï¿½Matt >>>>> >>>>> ï¿½ Barry >>>>> >>>>> >>>>>> On Dec 31, 2020, at 12:38 PM, Matthew Knepley >>>>>> <knepley(a)gmail.com <mailto:[email protected]>> wrote: >>>>>> >>>>>> I justï¿½pulled master, and simple alterations to tests do not >>>>>> produce a failure: >>>>>> >>>>>> master *$:/PETSc3/petsc/petsc-dev$ PETSC_ARCH=arch-master-debug >>>>>> make -f ./gmakefile test search="snes_tests-ex13_bench" >>>>>> TIMEOUT=5000 EXTRA_OPTIONS="-dm_ >>>>>> refine 0" >>>>>> Using MAKEFLAGS: EXTRA_OPTIONS=-dm_refine 0 TIMEOUT=5000 >>>>>> search=snes_tests-ex13_bench >>>>>> ï¿½ ï¿½ ï¿½ ï¿½ TEST >>>>>> arch-master-debug/tests/counts/snes_tests-ex13_bench.counts >>>>>> ï¿½ok snes_tests-ex13_bench >>>>>> ï¿½ok diff-snes_tests-ex13_bench >>>>>> >>>>>> I check that the runs produce different output when done manually. >>>>>> >>>>>> Scott and Barry, could this be related to changed to testing? >>>>>> >>>>>> ï¿½ Thanks, >>>>>> >>>>>> ï¿½ ï¿½ ï¿½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 >>>>>> >>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>> <http://www.cse.buffalo.edu/%7Eknepley/> >>>>> >>>>> >>>>> -- >>>>> 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/%7Eknepley/> >> -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Testing seems broken in master
by Satish Balay 04 Jan '21

04 Jan '21

hm - indices are integers and its not ignored (i.e %d) - only the %f and %e diff is ignored (by default) Satish On Mon, 4 Jan 2021, Scott Kruger wrote: > > > > Is this just the 3rd problem? > > Regarding how you can end up with changes not being caught: > The default (going all the way back to the old harness) is to not check > numbers to avoid round-off errors giving false negatives (failures). > Of course, sometimes you *want* to check the numbers; e.g., for indices.ï¿½ The > solution for this is to add: > > ï¿½ï¿½ï¿½ï¿½ diff_args: -j > > Scott > > On 12/31/20 4:40 PM, Barry Smith wrote: > > > > ï¿½ I think I have it "fixed" now in the branch, once it passes the pipeline I > > will shepard it through the MR quickly. Sorry about this, even all our CI > > testing can miss a great deal. > > > > ï¿½ Barry > > > > > > > >> On Dec 31, 2020, at 2:44 PM, Barry Smith <bsmith(a)petsc.dev > >> <mailto:[email protected]>> wrote: > >> > >> > >> ï¿½ This is a different (3rd) problem. Funny it didn't bother anyone for two > >> months. > >> > >> ï¿½ Fix is in barry/2020-12-29/fix-petscdiff-bracket but the pipeline keeps > >> failing ts_tutorials_advection-diffusion-reaction-ex3_2 fails on different > >> machines with slightly different counts. I don't see how this change could > >> cause that! But gets old results on my machine. Very frustrating. > >> Barry > >> > >>> On Dec 31, 2020, at 1:02 PM, Matthew Knepley <knepley(a)gmail.com > >>> <mailto:[email protected]>> wrote: > >>> > >>> On Thu, Dec 31, 2020 at 1:48 PM Barry Smith <bsmith(a)petsc.dev > >>> <mailto:[email protected]>> wrote: > >>> > >>> > >>> ï¿½ So the programs output changes and should no longer match that > >>> in the output/* file yet the test harness does not error with a > >>> statement that the two outputs do not match? > >>> > >>> ï¿½ ï¿½I noticed the gmakegentest.py is not being run before it runs > >>> the test? Does this mean it is just running all the old stuff > >>> which does match fine? > >>> > >>> ï¿½ ï¿½Then either how petscdiff is called by the test harness has > >>> changed or petscdiff has changed and does not detect changes > >>> anymore > >>> > >>> ï¿½ ï¿½BTW: I always use -f ./gmakefile.test test not just the gmakefile > >>> > >>> ï¿½ ï¿½All the PETSc changes are trivial and can be seen with a > >>> simple diff, it is hard to believe they would cause this > >>> behavior but I guess they must. > >>> > >>> ï¿½ ï¿½You can go to PETSC_ARCH/tests/snes/tests and run the ex13 > >>> shell script directly. > >>> > >>> > >>> It is the sed problem: > >>> > >>> master *$:/PETSc3/petsc/petsc-dev$ > >>> /PETSc3/petsc/petsc-dev/lib/petsc/bin/petscdiff > >>> /PETSc3/petsc/petsc-dev/src/snes/tests/output/ex13_bench.out > >>> ex13_bench.tmp > >>> > >>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) > >>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) > >>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) > >>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) > >>> > >>> The error was getting eaten. > >>> > >>> This is in current master. Is it fixed in a branch? > >>> > >>> ï¿½ ï¿½Matt > >>> > >>> ï¿½ Barry > >>> > >>> > >>>> On Dec 31, 2020, at 12:38 PM, Matthew Knepley > >>>> <knepley(a)gmail.com <mailto:[email protected]>> wrote: > >>>> > >>>> I justï¿½pulled master, and simple alterations to tests do not > >>>> produce a failure: > >>>> > >>>> master *$:/PETSc3/petsc/petsc-dev$ PETSC_ARCH=arch-master-debug > >>>> make -f ./gmakefile test search="snes_tests-ex13_bench" > >>>> TIMEOUT=5000 EXTRA_OPTIONS="-dm_ > >>>> refine 0" > >>>> Using MAKEFLAGS: EXTRA_OPTIONS=-dm_refine 0 TIMEOUT=5000 > >>>> search=snes_tests-ex13_bench > >>>> ï¿½ ï¿½ ï¿½ ï¿½ TEST > >>>> arch-master-debug/tests/counts/snes_tests-ex13_bench.counts > >>>> ï¿½ok snes_tests-ex13_bench > >>>> ï¿½ok diff-snes_tests-ex13_bench > >>>> > >>>> I check that the runs produce different output when done manually. > >>>> > >>>> Scott and Barry, could this be related to changed to testing? > >>>> > >>>> ï¿½ Thanks, > >>>> > >>>> ï¿½ ï¿½ ï¿½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 > >>>> > >>>> https://www.cse.buffalo.edu/~knepley/ > >>>> <http://www.cse.buffalo.edu/%7Eknepley/> > >>> > >>> > >>> > >>> -- > >>> 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/%7Eknepley/> > >> > > > >

1 0

Re: [petsc-dev] Testing seems broken in master
by Scott Kruger 04 Jan '21

04 Jan '21

Is this just the 3rd problem? Regarding how you can end up with changes not being caught: The default (going all the way back to the old harness) is to not check numbers to avoid round-off errors giving false negatives (failures). Of course, sometimes you *want* to check the numbers; e.g., for indices.ï¿½ The solution for this is to add: ï¿½ï¿½ï¿½ï¿½ diff_args: -j Scott On 12/31/20 4:40 PM, Barry Smith wrote: > > ï¿½ I think I have it "fixed" now in the branch, once it passes the > pipeline I will shepard it through the MR quickly. Sorry about this, > even all our CI testing can miss a great deal. > > ï¿½ Barry > > > >> On Dec 31, 2020, at 2:44 PM, Barry Smith <bsmith(a)petsc.dev >> <mailto:[email protected]>> wrote: >> >> >> ï¿½ This is a different (3rd) problem. Funny it didn't bother anyone >> for two months. >> >> ï¿½ Fix is in barry/2020-12-29/fix-petscdiff-bracket but the pipeline >> keeps failing ts_tutorials_advection-diffusion-reaction-ex3_2 fails >> on different machines with slightly different counts. I don't see how >> this change could cause that! But gets old results on my machine. >> Very frustrating. >> Barry >> >>> On Dec 31, 2020, at 1:02 PM, Matthew Knepley <knepley(a)gmail.com >>> <mailto:[email protected]>> wrote: >>> >>> On Thu, Dec 31, 2020 at 1:48 PM Barry Smith <bsmith(a)petsc.dev >>> <mailto:[email protected]>> wrote: >>> >>> >>> ï¿½ So the programs output changes and should no longer match that >>> in the output/* file yet the test harness does not error with a >>> statement that the two outputs do not match? >>> >>> ï¿½ ï¿½I noticed the gmakegentest.py is not being run before it runs >>> the test? Does this mean it is just running all the old stuff >>> which does match fine? >>> >>> ï¿½ ï¿½Then either how petscdiff is called by the test harness has >>> changed or petscdiff has changed and does not detect changes >>> anymore >>> >>> ï¿½ ï¿½BTW: I always use -f ./gmakefile.test test not just the gmakefile >>> >>> ï¿½ ï¿½All the PETSc changes are trivial and can be seen with a >>> simple diff, it is hard to believe they would cause this >>> behavior but I guess they must. >>> >>> ï¿½ ï¿½You can go to PETSC_ARCH/tests/snes/tests and run the ex13 >>> shell script directly. >>> >>> >>> It is the sed problem: >>> >>> master *$:/PETSc3/petsc/petsc-dev$ >>> /PETSc3/petsc/petsc-dev/lib/petsc/bin/petscdiff >>> /PETSc3/petsc/petsc-dev/src/snes/tests/output/ex13_bench.out >>> ex13_bench.tmp >>> >>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) >>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) >>> sed: 1: "s/\033[1;31m//g": unbalanced brackets ([]) >>> sed: 1: "s/\033[0;39m\033[0;49m//g": unbalanced brackets ([]) >>> >>> The error was getting eaten. >>> >>> This is in current master. Is it fixed in a branch? >>> >>> ï¿½ ï¿½Matt >>> >>> ï¿½ Barry >>> >>> >>>> On Dec 31, 2020, at 12:38 PM, Matthew Knepley >>>> <knepley(a)gmail.com <mailto:[email protected]>> wrote: >>>> >>>> I justï¿½pulled master, and simple alterations to tests do not >>>> produce a failure: >>>> >>>> master *$:/PETSc3/petsc/petsc-dev$ PETSC_ARCH=arch-master-debug >>>> make -f ./gmakefile test search="snes_tests-ex13_bench" >>>> TIMEOUT=5000 EXTRA_OPTIONS="-dm_ >>>> refine 0" >>>> Using MAKEFLAGS: EXTRA_OPTIONS=-dm_refine 0 TIMEOUT=5000 >>>> search=snes_tests-ex13_bench >>>> ï¿½ ï¿½ ï¿½ ï¿½ TEST >>>> arch-master-debug/tests/counts/snes_tests-ex13_bench.counts >>>> ï¿½ok snes_tests-ex13_bench >>>> ï¿½ok diff-snes_tests-ex13_bench >>>> >>>> I check that the runs produce different output when done manually. >>>> >>>> Scott and Barry, could this be related to changed to testing? >>>> >>>> ï¿½ Thanks, >>>> >>>> ï¿½ ï¿½ ï¿½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 >>>> >>>> https://www.cse.buffalo.edu/~knepley/ >>>> <http://www.cse.buffalo.edu/%7Eknepley/> >>> >>> >>> >>> -- >>> 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/%7Eknepley/> >> > -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] [petsc-maint] Proposal to improve MatSetValuesBlocked
by Jed Brown 04 Jan '21

04 Jan '21

Mark Adams <mfadams(a)lbl.gov> writes: > Jed likes static inline functions as he said. I assume this is dispatched > with a switch statement. > > I would probably just use the model used for MatMult in BAIJ. > See src/mat/impls/baij/seq/baij.c. This just sets the matmult function to > point to specialized functions. Same, the static inline functions are just a way of creating these specialized functions without copy-pasta or macros.

1 0

Re: [petsc-dev] [petsc-maint] Proposal to improve MatSetValuesBlocked
by Mark Adams 04 Jan '21

04 Jan '21

Hi Frank, Jed likes static inline functions as he said. I assume this is dispatched with a switch statement. I would probably just use the model used for MatMult in BAIJ. See src/mat/impls/baij/seq/baij.c. This just sets the matmult function to point to specialized functions. So I'd look where BAIJ sets ops->multadd and do the same for matsetvaluesblocked. This would be called in src/mat/interface. I see this was already done for block size 4 from Fortran (matsetvaluesblocked4). That might be a good place to start. Others might have better ideas. I did not write any of this code. Thanks, Mark On Mon, Jan 4, 2021 at 7:48 AM Frank Bramkamp <bramkamp(a)nsc.liu.se> wrote: > Hi Mark, > > then just let me know how you want to implement the blocking/ switch > statements. > > I can also insert it manually in the code. It probably makes sense to > implement it for > row and column oriented BAIJ format, as well as for ADD_VALUES and insert > values. > > > I took some days off around new year. This week I am back again more > regularly. > > > Greetings, > Frank > >

1 0

Re: [petsc-dev] [petsc-maint] Proposal to improve MatSetValuesBlocked
by Frank Bramkamp 04 Jan '21

04 Jan '21

Hi Mark, then just let me know how you want to implement the blocking/ switch statements. I can also insert it manually in the code. It probably makes sense to implement it for row and column oriented BAIJ format, as well as for ADD_VALUES and insert values. I took some days off around new year. This week I am back again more regularly. Greetings, Frank

1 0