[petsc-dev] suggest workflow:Ready-For-Merge label

What about having another label like workflow:Ready-For-Merge in GitLab so that one could stress that all conditions are met for the MR to be merged. It can sometimes take some time between meeting all conditions and the merge, and this would allow authors to mark it as done from their side for

[petsc-dev] Suggestion regarding CI issues

Issues related to CI testing often affect multiple independent MRs. There should be a single point where anybody can look whether it is already known or even already solved, to avoid duplicate discussions or even solutions. There is already a special issue #360 "CI Error Tracker". So I suggest

Re: [petsc-dev] nobody in Integration approval group

e groups were treated.. > > Satish > > On Mon, 30 Sep 2019, Hapla Vaclav via petsc-dev wrote: > >> >> >> On 30 Sep 2019, at 20:09, Balay, Satish >> mailto:ba...@mcs.anl.gov>> wrote: >> >> The approval rules haven't changed as far as I c

Re: [petsc-dev] nobody in Integration approval group

n give this a try at: https://gitlab.com/petsc/petsc/merge_requests/2124 OK, I can see you can approve, so it is just a visibility issue - I can't see who is in Integration and you can't see who is in Team. Thanks, Vaclav Satish On Mon, 30 Sep 2019, Hapla Vaclav via petsc-dev wrote: Somebody c

[petsc-dev] nobody in Integration approval group

Somebody changed the approval rules so that there is nobody in Integration. This is confusing and would block most MRs from merging (because they usually require at least one approval from Integration but there is nobody ATM). If it was a mistake, please fix it. If it was deliberate, please

Re: [petsc-dev] test harness: output of actually executed command for V=1 gone?

> On 20 Sep 2019, at 23:18, Scott Kruger wrote: > > > > > > On 9/20/19 2:49 PM, Jed Brown wrote: >> Hapla Vaclav via petsc-dev writes: >>> On 20 Sep 2019, at 19:59, Scott Kruger >>> mailto:kru...@txcorp.com>> wrote: >>> &g

Re: [petsc-dev] test harness: output of actually executed command for V=1 gone?

On 20 Sep 2019, at 19:59, Scott Kruger mailto:kru...@txcorp.com>> wrote: On 9/20/19 10:44 AM, Hapla Vaclav via petsc-dev wrote: I was used to copy the command actually run by test harness, change to example's directory and paste the command (just changing one .. to ., e.g. ../ex1 to

[petsc-dev] test harness: output of actually executed command for V=1 gone?

I was used to copy the command actually run by test harness, change to example's directory and paste the command (just changing one .. to ., e.g. ../ex1 to ./ex1). Is this output gone? Bad news. I think there should definitely be an option to quickly reproduce the test run to work on failing

Re: [petsc-dev] Master broken after changes to PetscSection headers

On 19 Sep 2019, at 11:25, Matthew Knepley via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: I pushed the fix to the branch. Can we remerge it? I think best way would be to create another MR. You should also add #include to petscdmlabel.h. This which will also satisfy Lisandro's point.

Re: [petsc-dev] Master broken after changes to PetscSection headers

There is no evidence of the pipeline been run. FWIW I commented on redundant include in convert.c in the thread https://gitlab.com/petsc/petsc/merge_requests/2065#note_218172010 but this was only due to my visual check. Vaclav On 19 Sep 2019, at 11:25, Matthew Knepley via petsc-dev

Re: [petsc-dev] Master broken after changes to PetscSection headers

Looks like it was not tested at all... https://gitlab.com/petsc/petsc/merge_requests/2065 Could there be a mechanism to prevent merging without testing? On 19 Sep 2019, at 11:18, Stefano Zampini via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: How come this was not caught by the tests? I

Re: [petsc-dev] section negative offsets

On 17 Sep 2019, at 14:48, Matthew Knepley mailto:knep...@gmail.com>> wrote: On Tue, Sep 17, 2019 at 8:34 AM Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: Can PetscSection offsets other than unset be negative? I.e. could the offset value of -1 be an indicator it

[petsc-dev] section negative offsets

Can PetscSection offsets other than unset be negative? I.e. could the offset value of -1 be an indicator it was not set and needs to be computed? Thanks, Vaclav

[petsc-dev] PETSC_HAVE_ZLIB gone with PR #1853

Barry, you did a petscconf.h cleanup in BitBucket PR #1834 (merge commit 52556f0f). The problem is PETSC_HAVE_ZLIB is no longer set when ZLIB is installed. That effectively disables my tests with `requires: zlib` in src/mat/examples/tutorials/ex10.c src/ksp/ksp/examples/tutorials/ex27.c

Re: [petsc-dev] DMPlexInterpolate fortran stub redundant?

design where it could be called recursively. I got rid of that, but not the stub. OK, I will remove that. Thanks, Vaclav Matt > On Jul 29, 2019, at 10:28 AM, Hapla Vaclav via petsc-dev > mailto:petsc-dev@mcs.anl.gov>> wrote: > > I don't see why DMPlexInterpolate needs

[petsc-dev] DMPlexInterpolate fortran stub redundant?

I don't see why DMPlexInterpolate needs a custom Fortran stub https://bitbucket.org/petsc/petsc/src/master/src/dm/impls/plex/ftn-custom/zplexinterpolate.c It doesn't take any array arguments. Thanks, Vaclav

Re: [petsc-dev] PETSc blame digest (next) 2019-06-24

Just pushed a fix https://bitbucket.org/petsc/petsc/commits/0a6d9c2cc2968fda638d74ade0580a7c77d65884?at=hapla/hide-hdf5-headers-for-non-hdf5 Vaclav On 24 Jun 2019, at 14:28, PETSc checkBuilds mailto:petsc-checkbui...@mcs.anl.gov>> wrote: Dear PETSc developer, This email contains listings of

Re: [petsc-dev] is VecGetValuesSection correct?

On 21 Jun 2019, at 13:58, Lawrence Mitchell mailto:we...@gmx.li>> wrote: Hi Vaclav, On 21 Jun 2019, at 12:14, Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: VecGetValuesSection() returns pointer values obtained as follows: VecGetArray(v, ); *values = [s

[petsc-dev] is VecGetValuesSection correct?

VecGetValuesSection() returns pointer values obtained as follows: VecGetArray(v, ); *values = [s->atlasOff[p]]; VecRestoreArray(v, ); It looks to me scary. VecGetArray manpage says: If the underlying vector data is not stored in a contiguous array this routine will copy the data to a contiguous

Re: [petsc-dev] PETSc blame digest (next) 2019-06-20

g HDF5 includes public, means all PETSc applications have the HDF5 includes open in them. Likely it should just get _Private Barry On Jun 20, 2019, at 9:01 AM, Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On 20 Jun 2019, at 15:56, Vaclav Hapla mailto:vaclav.ha...@

Re: [petsc-dev] PETSc blame digest (next) 2019-06-20

> On 20 Jun 2019, at 15:56, Vaclav Hapla wrote: > > > >> On 20 Jun 2019, at 15:52, Vaclav Hapla wrote: >> >> >> >>> On 20 Jun 2019, at 15:15, Hapla Vaclav wrote: >>> >>> >>> >>>> On 20

Re: [petsc-dev] PETSc blame digest (next) 2019-06-20

> On 20 Jun 2019, at 14:28, PETSc checkBuilds > wrote: > > > > Dear PETSc developer, > > This email contains listings of contributions attributed to you by > `git blame` that caused compiler errors or warnings in PETSc automated > testing. Follow the links to see the full log files.

Re: [petsc-dev] PETSc Meeting errata

ch Maintanance From 2019-06-18 09:00 Till 2019-06-21 13:00 (2019-06-11 08:58:35) We plan to upgrade Lustre stack. We hope to resolve some performance issues with SCRATCH. Thanks, Vaclav Best, Jakub On 6/14/19 12:31 PM, Hapla Vaclav via petsc-dev wrote: I take b

[petsc-dev] PETSc Meeting errata

I take back one thing I mentioned in my talk in Atlanta. I think I said that Lustre striping does not really influence the read performance. With my latest results in hand, I must point out this is not true. I might have been confused by some former Piz Daint Lustre performance issues and/or

[petsc-dev] PETSC_VIEWER_*_() vs PetscOptionsGetViewer()

Let me follow up discussion on creating/controlling viewers from options. Barry agrees to rename PetscOptionsGetViewer() to PetscViewerCreateFromOptions() in Issue #291. But now I can see a problem: it mixes Get and Create behavior, as it returns

Re: [petsc-dev] Is bitbucket less responsive than it use to be?

I have the same feeling. Some parts are fast, e.g. browsing through the Source. But browsing branches, traversing commits, changing between branches etc. is getting a pain. And it's like that in the campus with super fast connectivity, so I believe it's a server-side issue. Whereas GitHub

[petsc-dev] do PETSC_VIEWER_{HDF5,BINARY}_ need to exist?

Hello I just encountered their manpages and it's a mess. I think in case of file I/O, a user should be deliberate about filename and other settings. Sometimes less is more and I think this is the case. Why anybody should use PETSC_VIEWER_BINARY_(comm) and then set the filename with environment

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

> On 4 May 2019, at 20:49, Jed Brown wrote: > > "Smith, Barry F. via petsc-maint" writes: > >> Yes you have the history exactly right, butt keeping them as independent >> beasts seemed/seems impossible; except by doing something very cumbersome >> (like shoving all the PCXXX_YYY that

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

On 4 May 2019, at 00:27, Smith, Barry F. mailto:bsm...@mcs.anl.gov>> wrote: On May 3, 2019, at 4:22 PM, Hapla Vaclav mailto:vaclav.ha...@erdw.ethz.ch>> wrote: On 2 May 2019, at 23:41, Smith, Barry F. mailto:bsm...@mcs.anl.gov>> wrote: On May 2, 2019, at 2:00 PM, Hapla Vaclav

Re: [petsc-dev] PetscViewerASCIIPushSynchronized

> On 3 May 2019, at 17:34, Smith, Barry F. wrote: > > > I think this thing maybe over-designed. When I wrote it I was obsessed with > having a single Flush method that one calls on the viewer that handles any > type of flushing, yet efficiently. Hence the trickery. If we had a separate

Re: [petsc-dev] alternatives to alt files

On 3 May 2019, at 06:21, Karl Rupp via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: Hi, Scott and PETSc folks, Using alt files for testing is painful. Whenever you add, for example, a new variable to be output in a viewer it changes the output files and you need to regenerate the

[petsc-dev] PetscViewerASCIIPushSynchronized

Is PetscViewerASCIIPushSynchronized / PetscViewerASCIIPopSynchronized really needed? I just got a feedback it's really confusing. Why we cannot just switch to the "synchronized mode" with the first call to PetscViewerASCIISynchronizedPrintf, and then hold this mode until PetscViewerFlush,

Re: [petsc-dev] concern about manpage example listings

grep -v /BODY $$b > ltmp; \ echo "" >> ltmp; \ mv -f ltmp $$b; \ fi; \ done; \ fi; \ done; \ fi It has a hardwired limit of 10 (though it seems to produce 11 :-). Given how many bad examples we

[petsc-dev] concern about manpage example listings

Hello Why https://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/SNES/SNESSolve.html#SNESSolve https://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/SNES/SNESSetDM.html#SNESSetDM do not list ex62 and ex77 https://www.mcs.anl.gov/petsc/petsc-dev/src/snes/examples/tutorials/ex62.c.html

Re: [petsc-dev] something weird in manpages

es/tutorials/ex1.c.html Am Di., 16. Apr. 2019 um 11:23 Uhr schrieb Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>>: I have noticed that some special characters such as (=" in probably all manpages have become hyperlinks to KSPConvergedReason. This looks pretty weird. Vaclav

Re: [petsc-dev] something weird in manpages

npages: https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatLoad.html (look for PetscViewerFileSetName) Am Di., 16. Apr. 2019 um 11:23 Uhr schrieb Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>>: I have noticed that some special characters such as (=" in proba

[petsc-dev] something weird in manpages

I have noticed that some special characters such as (=" in probably all manpages have become hyperlinks to KSPConvergedReason. This looks pretty weird. Vaclav

Re: [petsc-dev] git repo branches housekeeping

> On 1 Apr 2019, at 20:54, Balay, Satish via petsc-dev > wrote: > > On Mon, 1 Apr 2019, Jed Brown wrote: > >> "Balay, Satish" writes: >> >>> On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: >>> "Smith, Barry F. via petsc-dev" writes: > This is, IMHO, a weakness of

Re: [petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication

On 11 Mar 2019, at 23:59, Jed Brown via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: One could imagine PETSc written so that all Mat operations like transpose and products return lazy representations, with a method that makes it explicit. Would eliminate all the Transpose variants in the

Re: [petsc-dev] Why do we use void* instead of PetscObject in PETSc?

Something related are functions like https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/SNES/SNESSetConvergenceTest.html https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/KSP/KSPMonitorSet.html which even have 3 parameters - the "evaluation" function, the context, and

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

> On 20 Dec 2018, at 01:06, Jed Brown wrote: > > Hapla Vaclav via petsc-dev writes: > >> So my overall idea (which I presented also at this year's User Meeting >> in London and nobody has objected yet), is that some FE codes could >> potentially use on

Re: [petsc-dev] Man pages usage of "Collective on XXX"

On 7 Feb 2019, at 15:10, Patrick Sanan via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: (Forgot to reply-all before) I'd propose to update the guidelines in the dev manual to say that unless otherwise specified, collectivity is wrt the communicator associated with the PETSc object in the

Re: [petsc-dev] Man pages usage of "Collective on XXX"

On 6 Feb 2019, at 21:08, Matthew Knepley via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On Wed, Feb 6, 2019 at 3:03 PM Dave May via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: * I notice that most man pages will say Collective on e.g.

Re: [petsc-dev] parallel partitioning of uninterpolated meshes not supported

Bump - is this question too complex or too stupid? :-) I'm now looking again on tests which are still failing in knepley/fix-plex-interpolate-sf-new. There are several ones failing with Parallel partitioning of uninterpolated meshes not supported So I'll just remove them for now. One test

Re: [petsc-dev] cray warning - reduction in alignment ignored

> PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > src/snes/examples/tutorials/network/power/power.h:} > PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > > Thanks > > Barry > > > > >> On Feb 1, 2019, at 11:47 AM, Hapla Vaclav via petsc-dev >>

[petsc-dev] cray warning - reduction in alignment ignored

I've got this with Cray compiler CC arch-daint-cray-opt/obj/dm/impls/network/network.o CC-1160 craycc: WARNING File = /scratch/snx3000/haplav/petsc/include/petsc/private/dmnetworkimpl.h, Line = 20 A reduction in alignment is ignored. } PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar));

[petsc-dev] parallel partitioning of uninterpolated meshes not supported

Matt, your commit https://bitbucket.org/petsc/petsc/commits/ffbd61634109cd55a4e1889a4f100c5a1bdbfef1 says Parallel partitioning of uninterpolated meshes not supported. So should I now take it as a not-yet-implemented feature? Does it really concern only this order of operations? 1) load

[petsc-dev] PETSc Meeting approximate date?

Hello Do you guys already have some idea about this year's PETSc Meeting dates? I'm thinking about going there but need to plan a bit. Thanks Vaclav

Re: [petsc-dev] setting viewer format from options

> On 18 Jan 2019, at 18:43, Jed Brown wrote: > > "Smith, Barry F. via petsc-dev" writes: > >> I'm very hesitant to have the -viewer_format supported by PETSc >> because it reintroduces the concept of "setting" the viewer format, >> as opposed to pushing and popping formats. I think it

Re: [petsc-dev] setting viewer format from options

y > to set the format and to push/pop it, they don't play well together. OK. I will respect this design decision. So I will decline my PR #1324. Vaclav > > Barry > > > > >> On Jan 17, 2019, at 4:49 AM, Hapla Vaclav wrote: >> >> >> >

Re: [petsc-dev] setting viewer format from options

> On 17 Jan 2019, at 00:47, Smith, Barry F. wrote: > > > >> On Jan 16, 2019, at 6:47 AM, Hapla Vaclav via petsc-dev >> wrote: >> >> I need to distinguish a PetscViewerFormat in DMLoad() and MatLoad(). > > Presumably this information wou

Re: [petsc-dev] setting viewer format from options

On 16 Jan 2019, at 15:41, Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On 16 Jan 2019, at 15:28, Jed Brown mailto:j...@jedbrown.org>> wrote: Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> writes: So is it wise to do that as Matt wrote?

Re: [petsc-dev] Segmentation faults in MatMatMult & MatTransposeMatMult

> On 16 Jan 2019, at 15:22, Jed Brown via petsc-dev > wrote: > > Matthew Knepley writes: > >> On Wed, Jan 16, 2019 at 9:01 AM Jed Brown via petsc-dev < >> petsc-dev@mcs.anl.gov> wrote: >> >>> Pierre Jolivet via petsc-dev writes: >>> OK, I was wrong about MATAIJ, as Jed already

Re: [petsc-dev] setting viewer format from options

On 16 Jan 2019, at 15:28, Jed Brown mailto:j...@jedbrown.org>> wrote: Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> writes: So is it wise to do that as Matt wrote? It would basically make PetscViewerSetFromOptions() non-reentrant. I think non-idempotent is the

Re: [petsc-dev] setting viewer format from options

> On 16 Jan 2019, at 14:42, Lawrence Mitchell wrote: > > > >> On 16 Jan 2019, at 13:21, Matthew Knepley via petsc-dev >> wrote: >> >> I think you just Push and do not Pop. Do we check for a non-empty stack? We >> silently ignore too many Pops. > If you don't pop, at least in the past,

[petsc-dev] setting viewer format from options

I need to distinguish a PetscViewerFormat in DMLoad() and MatLoad(). And it would be handy to be able to set it from options. So I wanted to add -viewer_format option into PetscViewerSetFromOptions(). But the problem is PetscViewerSetFormat() is deprecated and PetscViewerPushFormat() needs to

Re: [petsc-dev] git script for finding "outdated" branches in next

On 12 Jan 2019, at 19:55, Matthew Knepley via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On Fri, Jan 11, 2019 at 6:14 PM Balay, Satish via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: Currently I see: balay@sb /home/balay/petsc (master=) $ gitreadytomerge

Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2019-01-11

Satish, can you please do the same with my haplav/feature-hdf5-improve-attribute-io? Thanks Vaclav > On 11 Jan 2019, at 17:27, Balay, Satish via petsc-dev > wrote: > > Sorry - meant to say 'next' - not 'master' > > Satish > > On Fri, 11 Jan 2019, Satish Balay wrote: > >> merged latest >>

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

On 18 Dec 2018, at 14:30, Matthew Knepley mailto:knep...@gmail.com>> wrote: On Tue, Dec 18, 2018 at 8:28 AM Matthew Knepley mailto:knep...@gmail.com>> wrote: On Tue, Dec 18, 2018 at 6:54 AM Hapla Vaclav mailto:vaclav.ha...@erdw.ethz.ch>> wrote: On 17 Dec 2018, at 20:36, Matthew Knepley

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

On 17 Dec 2018, at 20:36, Matthew Knepley mailto:knep...@gmail.com>> wrote: On Mon, Dec 17, 2018 at 12:11 PM Lawrence Mitchell mailto:we...@gmx.li>> wrote: > On 17 Dec 2018, at 11:56, Hapla Vaclav > mailto:vaclav.ha...@erdw.ethz.ch>> wrote: > > Matt, great that your reminded this email. I

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

On 18 Dec 2018, at 12:16, Hapla Vaclav via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On 17 Dec 2018, at 18:11, Lawrence Mitchell mailto:we...@gmx.li>> wrote: On 17 Dec 2018, at 11:56, Hapla Vaclav mailto:vaclav.ha...@erdw.ethz.ch>> wrote: Matt, great that your r

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

> On 17 Dec 2018, at 18:11, Lawrence Mitchell wrote: > > >> On 17 Dec 2018, at 11:56, Hapla Vaclav wrote: >> >> Matt, great that your reminded this email. I actually completely missed it >> that time. >> >>> On 14 Dec 2018, at 19:54, Matthew Knepley via petsc-dev >>> wrote: > > [...]

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

Matt, great that your reminded this email. I actually completely missed it that time. On 14 Dec 2018, at 19:54, Matthew Knepley via petsc-dev mailto:petsc-dev@mcs.anl.gov>> wrote: On Fri, Jul 20, 2018 at 5:34 AM Lawrence Mitchell mailto:we...@gmx.li>> wrote: Dear petsc-dev, I'm once again

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

Cool, I will do that. Vaclav > On 7 Dec 2018, at 23:49, Smith, Barry F. wrote: > > > As I said, I'm convinced, I'm fine with removing the old code > > Barry > > >> On Dec 7, 2018, at 2:47 PM, Jed Brown wrote: >> >> "Smith, Barry F." writes: >> On Dec 7, 2018, at 2:25 PM, Jed

Re: [petsc-dev] MatDiagonalScale default implementation

Yes, this would a good option as well. Also nice it would be easy to distinguish "implicit" matrices, where people shouldn't expect e.g. MatGetRow() to work, as subtypes of shell... Vaclav On 7 Dec 2018, at 11:28, Stefano Zampini mailto:stefano.zamp...@gmail.com>> wrote: I think the best

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

> On 7 Dec 2018, at 10:35, Hapla Vaclav wrote: > > I wanted to add support for HDF5 attributes of groups (currently only > datasets). > > But I already feel like held back by supporting HDF5 older than 1.8.0. Do we > still need that? > > My arguments to get rid of that support: > 1) It

[petsc-dev] need for HDF5 < 1.8.0 support?

I wanted to add support for HDF5 attributes of groups (currently only datasets). But I already feel like held back by supporting HDF5 older than 1.8.0. Do we still need that? My arguments to get rid of that support: 1) It seems we already use some 1.8.0+ functions anyway (might be my fault,

Re: [petsc-dev] MatDiagonalScale default implementation

Yes, that means that a significant part of MatShell logic would become default implementations. But I would now do that only with MatDiagonalScale as a proof-of-concept - then we can progressively do the same with the others. At some point it could happen even with axpy - I think it would be

[petsc-dev] MatDiagonalScale default implementation

MatDiagonalScale_Shell, MatDiagonalScale_Normal, MatDiagonalScaleHermitian_Normal and perhaps some others are essentially the same. What about converting them into one MatDiagonalScale_Basic which would be the default implementation if no type-specific implementation is provided? I'm asking

Re: [petsc-dev] No rule to make target 'mfem-build'

... except that it somehow passes this MAKEFLAGS= to configure, resulting in the confusing message ... 1. 12. 2018 v 17:33, Stefano Zampini mailto:stefano.zamp...@gmail.com>>: Make reconfigure is equivalent to rerun the configure script Il giorno Sab 1 Dic 2018, 18:09 Hapla Vaclav

Re: [petsc-dev] No rule to make target 'mfem-build'

... but this is apparently not caused by your merge. Is it just normal behavior of make reconfigure? I didn't know about this, I always call the reconfigure script directly. Vaclav > 1. 12. 2018 v 16:04, Hapla Vaclav : > > Thanks, you're right. > > However, > > $ make reconfigure >

Re: [petsc-dev] No rule to make target 'mfem-build'

Thanks, you're right. However, $ make reconfigure === Configuring PETSc to compile on your system ===

[petsc-dev] No rule to make target 'mfem-build'

Hi Stefano After pulling latest master, I get the following at the end of make output: make[1]: *** No rule to make target 'mfem-build', needed by 'all-gnumake-local'. Stop. make[1]: Leaving directory '/scratch/petsc-dev-1' Now to check if the libraries are working do: make

Re: [petsc-dev] tests with multiple loops

Here I can use just one test with -test_custom_layout {{0 1}} so no pressure. Vaclav > 22. 11. 2018 v 14:26, Hapla Vaclav via petsc-dev : > > Scott, maybe a related issue. The following testset > > testset: > suffix: 4a_lsqr_hdf5 > nsize: {{1 2 4}} >

Re: [petsc-dev] tests with multiple loops

gt; > Fixed in scott/fix-forloops. Could you take a look and see if that works for > you? > > Thanks, > Scott > > > On 11/8/18 8:40 AM, Hapla Vaclav via petsc-dev wrote: >> Assume the following test >> test: >> suffix: 4_tet_test_orient >>

Re: [petsc-dev] proposed minor PetscPartitioner changes

Yes, MatPartitioning is a much more general thing and should stay in PETSc in long term. PetscPartitioner works just with DMPlex. My PETSCPARTITIONERMATPARTITIONING is a wrapper of MatPartitioner into PetscPartitioner so any MatPartitioning can already be used also for DMPlex. Hence, it also

[petsc-dev] MatLoad for HDF5/MAT files

Hello I would like to advertise pull request #1232 which brings the HDF5 matrix loader, done by Marek Pecha and me. https://bitbucket.org/petsc/petsc/pull-requests/1232/ Its impact is twofold: 1) It introduces a truly parallel reader where each rank reads its chunk of the matrix. 2) It can

[petsc-dev] tests with multiple loops

Assume the following test test: suffix: 4_tet_test_orient nsize: 2 args: -dim 3 -distribute 0 args: -rotate_interface_0 {{0 1 2 11 12 13}} args: -rotate_interface_1 {{0 1 2 11 12 13}} I was thinking that it should produce all combinations of -rotate_interface_0 and