From cpraveen at gmail.com Mon Mar 2 07:13:44 2026 From: cpraveen at gmail.com (Praveen C) Date: Mon, 2 Mar 2026 18:43:44 +0530 Subject: [petsc-users] Preconditioners with block matrix Message-ID: Hello I am using PETSc with deal.II. My matrix is defined as PETScWrappers::BlockSparseMatrix which uses MATNEST. Is it possible to use PCILU (in serial) or PCHYPRE with such a matrix ? thanks praveen -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.semplice at uninsubria.it Mon Mar 2 09:09:45 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Mon, 2 Mar 2026 16:09:45 +0100 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? Message-ID: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> Dear all, ? ? the following output from -snes_test_jacobian_view lokks clear enough to pinpoint my mistake?(I must be putting jacobian elements in the wrong place), but it nevertheless left me suprised. 0 SNES Function norm 2.945516399303e-01 ? ---------- Testing Jacobian ------------- ? Testing hand-coded Jacobian, if (for double precision runs) ||J - Jfd||_F/||J||_F is ? ? O(1.e-8), the hand-coded Jacobian is probably correct. ? ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 ? Hand-coded Jacobian ---------- Mat Object: 4 MPI processes ? row 84:? ? ?(84, 60.)? ? ? (85, 0.) (3446, -80.) ? ? (3447, 0.) ? ? (6808, 20.) ? (6809, 0.) ? row 85:? ? ?(84, 0.00914434)? ? ? (85, 1.)? ? ? (3446, 0.) (3447, 0.)? ? ? (6808, 0.)? ? ? (6809, 0.) ? ?Finite difference Jacobian ---------- Mat Object: 4 MPI processes ? type: mpiaij ? row 84:? ?(84, 60.) (1806, -80.) (3528, 20.) ? row 85:? ?(85, 0.999971) ? Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- Mat Object: 4 MPI processes ? type: mpiaij row 84: ? row 85:? ?(84, 0.00914434)? ? (85, 2.9293e-05) The difference of the two matrices shoudl be nonzero in row 84 for all elements 1806, 3528, 3446, 6808. Is it intended that the difference is shown only for matrix elements that are present in both the hand-coded and the FD jacobian? I would have expected an output like row 84: (1806,80.)? ?(3446,-80.), etc (This was on PETSc Release Version 3.24.2) Thanks ? ? Matteo -- Prof. Matteo Semplice Universit? degli Studi dell?Insubria Dipartimento di Scienza e Alta Tecnologia ? DiSAT Professore Associato Via Valleggio, 11 ? 22100 Como (CO) ? Italia tel.: +39 031 2386316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at petsc.dev Mon Mar 2 13:53:55 2026 From: bsmith at petsc.dev (Barry Smith) Date: Mon, 2 Mar 2026 14:53:55 -0500 Subject: [petsc-users] Preconditioners with block matrix In-Reply-To: References: Message-ID: > On Mar 2, 2026, at 8:13?AM, Praveen C wrote: > > Hello > > I am using PETSc with deal.II. My matrix is defined as PETScWrappers::BlockSparseMatrix which uses MATNEST. > > Is it possible to use PCILU (in serial) or PCHYPRE with such a matrix ? Hypre has its own matrix format which we map to using MatConvert(mat, MATHYPRE) so it depends on whether the converter is general enough to convert from Nest. Likely the converter needs to be written (it would be straight to write such a convert. Similarly PCILU is likely hardwired for AIJ and BAIJ so would need a converter. In general MatNest is used to capture some nested structure of the matrix. This nested structure is taken advantage of in assembling (building) the matrix and then later in preconditioning the matrix. Hypre and ILU in general do not/cannot take advantage of that structure so are not likely to be the best solvers in general when using MatNest. That said, we should provide converters so that you can trivially do what you request. Barry > > thanks > praveen From bsmith at petsc.dev Mon Mar 2 13:59:57 2026 From: bsmith at petsc.dev (Barry Smith) Date: Mon, 2 Mar 2026 14:59:57 -0500 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> Message-ID: <7D37BD2D-85D4-41D6-83F6-0DDC5970BF8E@petsc.dev> At first glance the output is surprising. I believe your understanding is correct and something is going very wrong to produce the output you report. Is there any way you can share the code that produces this output (if you send it to petsc-maint at mcs.anl.gov the code will never be shared outside the PETSc developers who monitor that email). Barry > On Mar 2, 2026, at 10:09?AM, Matteo Semplice via petsc-users wrote: > > Dear all, > > the following output from -snes_test_jacobian_view lokks clear enough to pinpoint my mistake (I must be putting jacobian elements in the wrong place), but it nevertheless left me suprised. > > 0 SNES Function norm 2.945516399303e-01 > ---------- Testing Jacobian ------------- > Testing hand-coded Jacobian, if (for double precision runs) ||J - Jfd||_F/||J||_F is > O(1.e-8), the hand-coded Jacobian is probably correct. > ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 > Hand-coded Jacobian ---------- > Mat Object: 4 MPI processes > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) > row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > Finite difference Jacobian ---------- > Mat Object: 4 MPI processes > type: mpiaij > row 84: (84, 60.) (1806, -80.) (3528, 20.) > row 85: (85, 0.999971) > > Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- > Mat Object: 4 MPI processes > type: mpiaij > row 84: > row 85: (84, 0.00914434) (85, 2.9293e-05) > The difference of the two matrices shoudl be nonzero in row 84 for all elements 1806, 3528, 3446, 6808. Is it intended that the difference is shown only for matrix elements that are present in both the hand-coded and the FD jacobian? > > I would have expected an output like > > row 84: (1806,80.) (3446,-80.), etc > > (This was on PETSc Release Version 3.24.2) > > Thanks > > Matteo > > -- > Prof. Matteo Semplice > Universit? degli Studi dell?Insubria > Dipartimento di Scienza e Alta Tecnologia ? DiSAT > Professore Associato > Via Valleggio, 11 ? 22100 Como (CO) ? Italia > tel.: +39 031 2386316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.zampini at gmail.com Mon Mar 2 14:32:31 2026 From: stefano.zampini at gmail.com (Stefano Zampini) Date: Mon, 2 Mar 2026 21:32:31 +0100 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> Message-ID: Maybe you are using a DMDA, with one matrix coming from it and the other not? DMDA changes the View to dump in natural ordering. Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via petsc-users < petsc-users at mcs.anl.gov> ha scritto: > Dear all, > > the following output from -snes_test_jacobian_view lokks clear enough > to pinpoint my mistake (I must be putting jacobian elements in the wrong > place), but it nevertheless left me suprised. > 0 SNES Function norm 2.945516399303e-01 > ---------- Testing Jacobian ------------- > Testing hand-coded Jacobian, if (for double precision runs) ||J - > Jfd||_F/||J||_F is > O(1.e-8), the hand-coded Jacobian is probably correct. > ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 > Hand-coded Jacobian ---------- > Mat Object: 4 MPI processes > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) > (6808, 20.) (6809, 0.) > row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, > 0.) (6808, 0.) (6809, 0.) > > Finite difference Jacobian ---------- > Mat Object: 4 MPI processes > type: mpiaij > row 84: (84, 60.) (1806, -80.) (3528, 20.) > row 85: (85, 0.999971) > > Hand-coded minus finite-difference Jacobian with tolerance 1e-05 > ---------- > Mat Object: 4 MPI processes > type: mpiaij > row 84: > row 85: (84, 0.00914434) (85, 2.9293e-05) > > The difference of the two matrices shoudl be nonzero in row 84 for all > elements 1806, 3528, 3446, 6808. Is it intended that the difference is > shown only for matrix elements that are present in both the hand-coded and > the FD jacobian? > > I would have expected an output like > > row 84: (1806,80.) (3446,-80.), etc > > (This was on PETSc Release Version 3.24.2) > > Thanks > > Matteo > > -- > Prof. Matteo Semplice > Universit? degli Studi dell?Insubria > Dipartimento di Scienza e Alta Tecnologia ? DiSAT > Professore Associato > Via Valleggio, 11 ? 22100 Como (CO) ? Italia > tel.: +39 031 2386316 > > -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.semplice at uninsubria.it Mon Mar 2 17:00:52 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Tue, 3 Mar 2026 00:00:52 +0100 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> Message-ID: <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> It's indeed a DMDA (with 2 dofs per point), but the code is run with -snes_test_jacobian -snes_test_jacobian_view Would the hand-coded and the f.d. jacobian be different matrix type in this case? Matteo Il 02/03/26 21:32, Stefano Zampini ha scritto: > Maybe you are using a DMDA, with one matrix coming from it and the > other not? DMDA changes the View to dump in natural ordering. > > Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via > petsc-users ha scritto: > > Dear all, > > ? ? the following output from -snes_test_jacobian_view lokks clear > enough to pinpoint my mistake?(I must be putting jacobian elements > in the wrong place), but it nevertheless left me suprised. > > 0 SNES Function norm 2.945516399303e-01 > ? ---------- Testing Jacobian ------------- > ? Testing hand-coded Jacobian, if (for double precision runs) ||J > - Jfd||_F/||J||_F is > ? ? O(1.e-8), the hand-coded Jacobian is probably correct. > ? ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 > ? Hand-coded Jacobian ---------- > Mat Object: 4 MPI processes > ? row 84:? ? ?(84, 60.)? ? ? (85, 0.) (3446, -80.) ? ? (3447, 0.) > ? ? (6808, 20.) ? (6809, 0.) > ? row 85:? ? ?(84, 0.00914434)? ? ? (85, 1.)? ? ? (3446, 0.)? ? ? > (3447, 0.)? ? ? (6808, 0.)? ? ? (6809, 0.) > > ? ?Finite difference Jacobian ---------- > Mat Object: 4 MPI processes > ? type: mpiaij > ? row 84:? ?(84, 60.) (1806, -80.) (3528, 20.) > ? row 85:? ?(85, 0.999971) > > ? Hand-coded minus finite-difference Jacobian with tolerance 1e-05 > ---------- > Mat Object: 4 MPI processes > ? type: mpiaij > row 84: > ? row 85:? ?(84, 0.00914434)? ? (85, 2.9293e-05) > > The difference of the two matrices shoudl be nonzero in row 84 for > all elements 1806, 3528, 3446, 6808. Is it intended that the > difference is shown only for matrix elements that are present in > both the hand-coded and the FD jacobian? > > I would have expected an output like > > row 84: (1806,80.)? ?(3446,-80.), etc > > (This was on PETSc Release Version 3.24.2) > > Thanks > > ? ? Matteo > > -- > Prof. Matteo Semplice > Universit? degli Studi dell?Insubria > Dipartimento di Scienza e Alta Tecnologia ? DiSAT > Professore Associato > Via Valleggio, 11 ? 22100 Como (CO) ? Italia > tel.: +39 031 2386316 > > > > -- > Stefano -- --- Professore Associato in Analisi Numerica Dipartimento di Scienza e Alta Tecnologia Universit? degli Studi dell'Insubria Via Valleggio, 11 - Como -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at petsc.dev Mon Mar 2 20:28:08 2026 From: bsmith at petsc.dev (Barry Smith) Date: Mon, 2 Mar 2026 21:28:08 -0500 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> Message-ID: Stefano hit the nail on the head! The matrices are of the same type it is just that MatView() for DMDA AIJ matrices MatView_MPI_DA() causes them to printed out in ?natural ordering? related to the grid instead of PETSc parallel ordering. It is perhaps a case of Barry being too clever for his own good. SNESTestJacobian() has the code: ``` PetscCall(MatGetType(A, &mattype)); PetscCall(MatGetSize(A, &M, &N)); PetscCall(MatGetLocalSize(A, &m, &n)); PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); PetscCall(MatSetType(B, mattype)); PetscCall(MatSetSizes(B, m, n, M, N)); PetscCall(MatSetBlockSizesFromMats(B, A, A)); PetscCall(MatSetUp(B)); PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); PetscCall(SNESComputeJacobianDefault(snes, x, B, B, functx)); ``` It does not use MatDuplicate() hence the B (finite difference matrix) does not inherit the MatView_MPI_DA() function. Could you please try the following. Edit src/snes/interface/snes.c and locate the routine SNESTestJacobian() and replace the block of code that creates the B matrix above with ``` PetscCall(MatDuplicate(B, MAT_DO_NOT_COPY_VALUES, &D)); ``` Then run make all in the PETSc home directory. Then rerun your program. The plan is now both matrices will be displayed in the same ordering (natural ordering on the multidimensional grid) and so the three matrices displayed should make sense. Barry > On Mar 2, 2026, at 6:00?PM, Matteo Semplice via petsc-users wrote: > > It's indeed a DMDA (with 2 dofs per point), but the code is run with > > -snes_test_jacobian -snes_test_jacobian_view > > Would the hand-coded and the f.d. jacobian be different matrix type in this case? > > Matteo > > Il 02/03/26 21:32, Stefano Zampini ha scritto: >> Maybe you are using a DMDA, with one matrix coming from it and the other not? DMDA changes the View to dump in natural ordering. >> >> Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via petsc-users > ha scritto: >>> Dear all, >>> >>> the following output from -snes_test_jacobian_view lokks clear enough to pinpoint my mistake (I must be putting jacobian elements in the wrong place), but it nevertheless left me suprised. >>> >>> 0 SNES Function norm 2.945516399303e-01 >>> ---------- Testing Jacobian ------------- >>> Testing hand-coded Jacobian, if (for double precision runs) ||J - Jfd||_F/||J||_F is >>> O(1.e-8), the hand-coded Jacobian is probably correct. >>> ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 >>> Hand-coded Jacobian ---------- >>> Mat Object: 4 MPI processes >>> row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) >>> row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) >>> >>> Finite difference Jacobian ---------- >>> Mat Object: 4 MPI processes >>> type: mpiaij >>> row 84: (84, 60.) (1806, -80.) (3528, 20.) >>> row 85: (85, 0.999971) >>> >>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>> Mat Object: 4 MPI processes >>> type: mpiaij >>> row 84: >>> row 85: (84, 0.00914434) (85, 2.9293e-05) >>> The difference of the two matrices shoudl be nonzero in row 84 for all elements 1806, 3528, 3446, 6808. Is it intended that the difference is shown only for matrix elements that are present in both the hand-coded and the FD jacobian? >>> >>> I would have expected an output like >>> >>> row 84: (1806,80.) (3446,-80.), etc >>> >>> (This was on PETSc Release Version 3.24.2) >>> >>> Thanks >>> >>> Matteo >>> >>> -- >>> Prof. Matteo Semplice >>> Universit? degli Studi dell?Insubria >>> Dipartimento di Scienza e Alta Tecnologia ? DiSAT >>> Professore Associato >>> Via Valleggio, 11 ? 22100 Como (CO) ? Italia >>> tel.: +39 031 2386316 >> >> >> >> -- >> Stefano > -- > --- > Professore Associato in Analisi Numerica > Dipartimento di Scienza e Alta Tecnologia > Universit? degli Studi dell'Insubria > Via Valleggio, 11 - Como -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.semplice at uninsubria.it Tue Mar 3 02:44:42 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Tue, 3 Mar 2026 09:44:42 +0100 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> Message-ID: <91c8e351-4c42-49c6-911c-bae79eae1236@uninsubria.it> Dear Barry, ? ? indeed your suggestion fixes things! (I assume that you meant?PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B));) Now I get a consistent output. Hand-coded Jac: ???row 84: ????(84, 60.) ?????(85, 0.) ?????(3446, -80.) ?????(3447, 0.) ?????(6808, 20.) ?????(6809, 0.) ???row 85: ????(84, 0.00914434) ?????(85, 1.) ?????(3446, 0.) ?????(3447, 0.) ?????(6808, 0.) ?????(6809, 0.) Finite-difference Jac: ? ?row 84: ????(84, 60.) ?????(85, 0.) ?????(3446, -80.) ?????(3447, 0.) ?????(6808, 20.) ?????(6809, 0.) ???row 85: ????(84, 0.) ?????(85, 0.999971) ?????(3446, 0.) ?????(3447, 0.) ?????(6808, 0.) ?????(6809, 0.) Difference of the two matrices: ? ?row 84: ????(84, 0.) ?????(85, 0.) ?????(3446, 0.) ?????(3447, 0.) ?????(6808, 0.) ?????(6809, 0.) ???row 85: ????(84, 0.00914434) ?????(85, 2.9293e-05) ?????(3446, 0.) ?????(3447, 0.) ?????(6808, 0.) ?????(6809, 0.) I have applied your suggestion on the top of the release branch and I had to fix also the creation of matrix C. Here below is the complete diff, in case you want to apply it to the official repository: diff --git a/src/snes/interface/snes.c b/src/snes/interface/snes.c index f66c23a1417..eee3d070d4c 100644 --- a/src/snes/interface/snes.c +++ b/src/snes/interface/snes.c @@ -2768,8 +2768,6 @@PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm ??Vec ??????????????x = snes->vec_sol, f; ??PetscReal ????????nrm, gnorm; ??PetscReal ????????threshold = 1.e-5; - ?MatType ??????????mattype; - ?PetscInt ?????????m, n, M, N; ??void ????????????*functx; ??PetscBool ????????complete_print = PETSC_FALSE, threshold_print = PETSC_FALSE, flg, istranspose; ??PetscBool ????????silent = diffNorm != PETSC_NULLPTR ? PETSC_TRUE : PETSC_FALSE; @@ -2832,14 +2830,7 @@PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm ??????PetscCall(MatComputeOperator(jacobian, MATAIJ, &A)); ????} - ???PetscCall(MatGetType(A, &mattype)); - ???PetscCall(MatGetSize(A, &M, &N)); - ???PetscCall(MatGetLocalSize(A, &m, &n)); - ???PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); - ???PetscCall(MatSetType(B, mattype)); - ???PetscCall(MatSetSizes(B, m, n, M, N)); - ???PetscCall(MatSetBlockSizesFromMats(B, A, A)); - ???PetscCall(MatSetUp(B)); + ???PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B)); ????PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); ????PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); @@ -2865,11 +2856,7 @@PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm ??????const PetscInt ???*bcols; ??????const PetscScalar *bvals; - ?????PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &C)); - ?????PetscCall(MatSetType(C, mattype)); - ?????PetscCall(MatSetSizes(C, m, n, M, N)); - ?????PetscCall(MatSetBlockSizesFromMats(C, A, A)); - ?????PetscCall(MatSetUp(C)); + ?????PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &C)); ??????PetscCall(MatSetOption(C, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); ??????PetscCall(MatAYPX(B, -1.0, A, DIFFERENT_NONZERO_PATTERN)); Thanks a lot! Matteo On 03/03/2026 03:28, Barry Smith wrote: > ? ?Stefano hit the nail on the head! > > ? ?The matrices are of the same type it is just that MatView() for > DMDA AIJ matrices MatView_MPI_DA() ?causes them to printed out in > ?natural ordering? related to the grid instead of PETSc parallel > ordering. ?It is perhaps a case of Barry being too clever for his own > good. > > ? ?SNESTestJacobian() has the code: > > ``` > ? ? PetscCall(MatGetType(A, &mattype)); > ? ? PetscCall(MatGetSize(A, &M, &N)); > ? ? PetscCall(MatGetLocalSize(A, &m, &n)); > ? ? PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); > ? ? PetscCall(MatSetType(B, mattype)); > ? ? PetscCall(MatSetSizes(B, m, n, M, N)); > ? ? PetscCall(MatSetBlockSizesFromMats(B, A, A)); > ? ? PetscCall(MatSetUp(B)); > ? ? PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, > PETSC_FALSE)); > > ? ? PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); > ? ? PetscCall(SNESComputeJacobianDefault(snes, x, B, B, functx)); > ``` > > ? ? It does not use MatDuplicate() hence the B (finite difference > matrix) does not inherit the MatView_MPI_DA() ?function. > > ? ? Could you please try the following. Edit src/snes/interface/snes.c > and locate the routine?SNESTestJacobian() ?and replace the block of > code ?that creates the B matrix above with > > ``` > ? ?PetscCall(MatDuplicate(B, MAT_DO_NOT_COPY_VALUES, &D)); > ``` > > ? ?Then run make all in the PETSc home directory. Then rerun your > program. The plan is now both matrices will be displayed in the same > ordering (natural ordering on the multidimensional grid) and so the > three matrices displayed should make sense. > > ? ?Barry > > > > >> On Mar 2, 2026, at 6:00?PM, Matteo Semplice via petsc-users >> wrote: >> >> It's indeed a DMDA (with 2 dofs per point), but the code is run with >> >> -snes_test_jacobian -snes_test_jacobian_view >> >> Would the hand-coded and the f.d. jacobian be different matrix type >> in this case? >> >> Matteo >> >> Il 02/03/26 21:32, Stefano Zampini ha scritto: >>> Maybe you are using a DMDA, with one matrix coming from it and the >>> other not? DMDA changes the View to dump in natural ordering. >>> >>> Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via >>> petsc-users ha scritto: >>> >>> Dear all, >>> >>> ? ? the following output from -snes_test_jacobian_view lokks >>> clear enough to pinpoint my mistake?(I must be putting jacobian >>> elements in the wrong place), but it nevertheless left me suprised. >>> >>> 0 SNES Function norm 2.945516399303e-01 >>> ? ---------- Testing Jacobian ------------- >>> ? Testing hand-coded Jacobian, if (for double precision runs) >>> ||J - Jfd||_F/||J||_F is >>> ? ? O(1.e-8), the hand-coded Jacobian is probably correct. >>> ? ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 >>> ? Hand-coded Jacobian ---------- >>> Mat Object: 4 MPI processes >>> ? row 84:? ? ?(84, 60.)? ? ? (85, 0.) (3446, -80.) (3447, 0.) >>> (6808, 20.) ? (6809, 0.) >>> ? row 85:? ? ?(84, 0.00914434)? ? ? (85, 1.)? ? ? (3446, 0.)? ? >>> ? (3447, 0.) (6808, 0.)? ? ? (6809, 0.) >>> >>> ? ?Finite difference Jacobian ---------- >>> Mat Object: 4 MPI processes >>> ? type: mpiaij >>> ? row 84:? ?(84, 60.) (1806, -80.) (3528, 20.) >>> ? row 85:? ?(85, 0.999971) >>> >>> ? Hand-coded minus finite-difference Jacobian with tolerance >>> 1e-05 ---------- >>> Mat Object: 4 MPI processes >>> ? type: mpiaij >>> row 84: >>> ? row 85:? ?(84, 0.00914434)? ? (85, 2.9293e-05) >>> >>> The difference of the two matrices shoudl be nonzero in row 84 >>> for all elements 1806, 3528, 3446, 6808. Is it intended that the >>> difference is shown only for matrix elements that are present in >>> both the hand-coded and the FD jacobian? >>> >>> I would have expected an output like >>> >>> row 84: (1806,80.)? ?(3446,-80.), etc >>> >>> (This was on PETSc Release Version 3.24.2) >>> >>> Thanks >>> >>> ? ? Matteo >>> >>> -- >>> Prof. Matteo Semplice >>> Universit? degli Studi dell?Insubria >>> Dipartimento di Scienza e Alta Tecnologia ? DiSAT >>> Professore Associato >>> Via Valleggio, 11 ? 22100 Como (CO) ? Italia >>> tel.: +39 031 2386316 >>> >>> >>> >>> -- >>> Stefano >> -- >> --- >> Professore Associato in Analisi Numerica >> Dipartimento di Scienza e Alta Tecnologia >> Universit? degli Studi dell'Insubria >> Via Valleggio, 11 - Como > -- Prof. Matteo Semplice Universit? degli Studi dell?Insubria Dipartimento di Scienza e Alta Tecnologia ? DiSAT Professore Associato Via Valleggio, 11 ? 22100 Como (CO) ? Italia tel.: +39 031 2386316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at petsc.dev Tue Mar 3 20:18:42 2026 From: bsmith at petsc.dev (Barry Smith) Date: Tue, 3 Mar 2026 21:18:42 -0500 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: <91c8e351-4c42-49c6-911c-bae79eae1236@uninsubria.it> References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> <91c8e351-4c42-49c6-911c-bae79eae1236@uninsubria.it> Message-ID: Thanks for reporting the problem and testing the fix. I have an MR to fix the problem https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/9089__;!!G_uCfscf7eWS!eEV8qwswkuey4UbIA8lPwEEaMow7mb2c6x8wS7vX2_w6pOX1i03GbPjLkft1PHGZE8wCsxFcCM3LZGaPUogP5WA$ Barry > On Mar 3, 2026, at 3:44?AM, Matteo Semplice via petsc-users wrote: > > Dear Barry, > > indeed your suggestion fixes things! (I assume that you meant PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B));) > > Now I get a consistent output. > > Hand-coded Jac: > > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) > row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > > Finite-difference Jac: > > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) > row 85: (84, 0.) (85, 0.999971) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > Difference of the two matrices: > row 84: (84, 0.) (85, 0.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > row 85: (84, 0.00914434) (85, 2.9293e-05) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > > I have applied your suggestion on the top of the release branch and I had to fix also the creation of matrix C. Here below is the complete diff, in case you want to apply it to the official repository: > > diff --git a/src/snes/interface/snes.c b/src/snes/interface/snes.c > index f66c23a1417..eee3d070d4c 100644 > --- a/src/snes/interface/snes.c > +++ b/src/snes/interface/snes.c > @@ -2768,8 +2768,6 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > Vec x = snes->vec_sol, f; > PetscReal nrm, gnorm; > PetscReal threshold = 1.e-5; > - MatType mattype; > - PetscInt m, n, M, N; > void *functx; > PetscBool complete_print = PETSC_FALSE, threshold_print = PETSC_FALSE, flg, istranspose; > PetscBool silent = diffNorm != PETSC_NULLPTR ? PETSC_TRUE : PETSC_FALSE; > @@ -2832,14 +2830,7 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > PetscCall(MatComputeOperator(jacobian, MATAIJ, &A)); > } > > - PetscCall(MatGetType(A, &mattype)); > - PetscCall(MatGetSize(A, &M, &N)); > - PetscCall(MatGetLocalSize(A, &m, &n)); > - PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); > - PetscCall(MatSetType(B, mattype)); > - PetscCall(MatSetSizes(B, m, n, M, N)); > - PetscCall(MatSetBlockSizesFromMats(B, A, A)); > - PetscCall(MatSetUp(B)); > + PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B)); > PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); > > PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); > @@ -2865,11 +2856,7 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > const PetscInt *bcols; > const PetscScalar *bvals; > > - PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &C)); > - PetscCall(MatSetType(C, mattype)); > - PetscCall(MatSetSizes(C, m, n, M, N)); > - PetscCall(MatSetBlockSizesFromMats(C, A, A)); > - PetscCall(MatSetUp(C)); > + PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &C)); > PetscCall(MatSetOption(C, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); > > PetscCall(MatAYPX(B, -1.0, A, DIFFERENT_NONZERO_PATTERN)); > > > > Thanks a lot! > > Matteo > > On 03/03/2026 03:28, Barry Smith wrote: >> Stefano hit the nail on the head! >> >> The matrices are of the same type it is just that MatView() for DMDA AIJ matrices MatView_MPI_DA() causes them to printed out in ?natural ordering? related to the grid instead of PETSc parallel ordering. It is perhaps a case of Barry being too clever for his own good. >> >> SNESTestJacobian() has the code: >> >> ``` >> PetscCall(MatGetType(A, &mattype)); >> PetscCall(MatGetSize(A, &M, &N)); >> PetscCall(MatGetLocalSize(A, &m, &n)); >> PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); >> PetscCall(MatSetType(B, mattype)); >> PetscCall(MatSetSizes(B, m, n, M, N)); >> PetscCall(MatSetBlockSizesFromMats(B, A, A)); >> PetscCall(MatSetUp(B)); >> PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); >> >> PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); >> PetscCall(SNESComputeJacobianDefault(snes, x, B, B, functx)); >> ``` >> >> It does not use MatDuplicate() hence the B (finite difference matrix) does not inherit the MatView_MPI_DA() function. >> >> Could you please try the following. Edit src/snes/interface/snes.c and locate the routine SNESTestJacobian() and replace the block of code that creates the B matrix above with >> >> ``` >> PetscCall(MatDuplicate(B, MAT_DO_NOT_COPY_VALUES, &D)); >> ``` >> >> Then run make all in the PETSc home directory. Then rerun your program. The plan is now both matrices will be displayed in the same ordering (natural ordering on the multidimensional grid) and so the three matrices displayed should make sense. >> >> Barry >> >> >> >> >>> On Mar 2, 2026, at 6:00?PM, Matteo Semplice via petsc-users wrote: >>> >>> It's indeed a DMDA (with 2 dofs per point), but the code is run with >>> >>> -snes_test_jacobian -snes_test_jacobian_view >>> >>> Would the hand-coded and the f.d. jacobian be different matrix type in this case? >>> >>> Matteo >>> >>> Il 02/03/26 21:32, Stefano Zampini ha scritto: >>>> Maybe you are using a DMDA, with one matrix coming from it and the other not? DMDA changes the View to dump in natural ordering. >>>> >>>> Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via petsc-users > ha scritto: >>>>> Dear all, >>>>> >>>>> the following output from -snes_test_jacobian_view lokks clear enough to pinpoint my mistake (I must be putting jacobian elements in the wrong place), but it nevertheless left me suprised. >>>>> >>>>> 0 SNES Function norm 2.945516399303e-01 >>>>> ---------- Testing Jacobian ------------- >>>>> Testing hand-coded Jacobian, if (for double precision runs) ||J - Jfd||_F/||J||_F is >>>>> O(1.e-8), the hand-coded Jacobian is probably correct. >>>>> ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 >>>>> Hand-coded Jacobian ---------- >>>>> Mat Object: 4 MPI processes >>>>> row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) >>>>> row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) >>>>> >>>>> Finite difference Jacobian ---------- >>>>> Mat Object: 4 MPI processes >>>>> type: mpiaij >>>>> row 84: (84, 60.) (1806, -80.) (3528, 20.) >>>>> row 85: (85, 0.999971) >>>>> >>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>>>> Mat Object: 4 MPI processes >>>>> type: mpiaij >>>>> row 84: >>>>> row 85: (84, 0.00914434) (85, 2.9293e-05) >>>>> The difference of the two matrices shoudl be nonzero in row 84 for all elements 1806, 3528, 3446, 6808. Is it intended that the difference is shown only for matrix elements that are present in both the hand-coded and the FD jacobian? >>>>> >>>>> I would have expected an output like >>>>> >>>>> row 84: (1806,80.) (3446,-80.), etc >>>>> >>>>> (This was on PETSc Release Version 3.24.2) >>>>> >>>>> Thanks >>>>> >>>>> Matteo >>>>> >>>>> -- >>>>> Prof. Matteo Semplice >>>>> Universit? degli Studi dell?Insubria >>>>> Dipartimento di Scienza e Alta Tecnologia ? DiSAT >>>>> Professore Associato >>>>> Via Valleggio, 11 ? 22100 Como (CO) ? Italia >>>>> tel.: +39 031 2386316 >>>> >>>> >>>> >>>> -- >>>> Stefano >>> -- >>> --- >>> Professore Associato in Analisi Numerica >>> Dipartimento di Scienza e Alta Tecnologia >>> Universit? degli Studi dell'Insubria >>> Via Valleggio, 11 - Como >> > -- > Prof. Matteo Semplice > Universit? degli Studi dell?Insubria > Dipartimento di Scienza e Alta Tecnologia ? DiSAT > Professore Associato > Via Valleggio, 11 ? 22100 Como (CO) ? Italia > tel.: +39 031 2386316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at petsc.dev Tue Mar 3 20:18:42 2026 From: bsmith at petsc.dev (Barry Smith) Date: Tue, 3 Mar 2026 21:18:42 -0500 Subject: [petsc-users] how is snes_test_jacobian_view computing the matrix difference? In-Reply-To: <91c8e351-4c42-49c6-911c-bae79eae1236@uninsubria.it> References: <3397dcee-383d-4999-a36b-e601227c7df1@uninsubria.it> <2e490fac-809a-4182-96af-2b20d2824ef8@uninsubria.it> <91c8e351-4c42-49c6-911c-bae79eae1236@uninsubria.it> Message-ID: Thanks for reporting the problem and testing the fix. I have an MR to fix the problem https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/9089__;!!G_uCfscf7eWS!daEZLbQOlvamUChfl-_r_qReVaAz-U9ld0kzN5nQ9KjIdQuRZxpOe8HcsyYoV4Pn3qLau0zIS99FMgtCo2mNz4A$ Barry > On Mar 3, 2026, at 3:44?AM, Matteo Semplice via petsc-users wrote: > > Dear Barry, > > indeed your suggestion fixes things! (I assume that you meant PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B));) > > Now I get a consistent output. > > Hand-coded Jac: > > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) > row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > > Finite-difference Jac: > > row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) > row 85: (84, 0.) (85, 0.999971) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > Difference of the two matrices: > row 84: (84, 0.) (85, 0.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > row 85: (84, 0.00914434) (85, 2.9293e-05) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) > > > I have applied your suggestion on the top of the release branch and I had to fix also the creation of matrix C. Here below is the complete diff, in case you want to apply it to the official repository: > > diff --git a/src/snes/interface/snes.c b/src/snes/interface/snes.c > index f66c23a1417..eee3d070d4c 100644 > --- a/src/snes/interface/snes.c > +++ b/src/snes/interface/snes.c > @@ -2768,8 +2768,6 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > Vec x = snes->vec_sol, f; > PetscReal nrm, gnorm; > PetscReal threshold = 1.e-5; > - MatType mattype; > - PetscInt m, n, M, N; > void *functx; > PetscBool complete_print = PETSC_FALSE, threshold_print = PETSC_FALSE, flg, istranspose; > PetscBool silent = diffNorm != PETSC_NULLPTR ? PETSC_TRUE : PETSC_FALSE; > @@ -2832,14 +2830,7 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > PetscCall(MatComputeOperator(jacobian, MATAIJ, &A)); > } > > - PetscCall(MatGetType(A, &mattype)); > - PetscCall(MatGetSize(A, &M, &N)); > - PetscCall(MatGetLocalSize(A, &m, &n)); > - PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); > - PetscCall(MatSetType(B, mattype)); > - PetscCall(MatSetSizes(B, m, n, M, N)); > - PetscCall(MatSetBlockSizesFromMats(B, A, A)); > - PetscCall(MatSetUp(B)); > + PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &B)); > PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); > > PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); > @@ -2865,11 +2856,7 @@ PetscErrorCode SNESTestJacobian(SNES snes, PetscReal *Jnorm, PetscReal *diffNorm > const PetscInt *bcols; > const PetscScalar *bvals; > > - PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &C)); > - PetscCall(MatSetType(C, mattype)); > - PetscCall(MatSetSizes(C, m, n, M, N)); > - PetscCall(MatSetBlockSizesFromMats(C, A, A)); > - PetscCall(MatSetUp(C)); > + PetscCall(MatDuplicate(A, MAT_DO_NOT_COPY_VALUES, &C)); > PetscCall(MatSetOption(C, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); > > PetscCall(MatAYPX(B, -1.0, A, DIFFERENT_NONZERO_PATTERN)); > > > > Thanks a lot! > > Matteo > > On 03/03/2026 03:28, Barry Smith wrote: >> Stefano hit the nail on the head! >> >> The matrices are of the same type it is just that MatView() for DMDA AIJ matrices MatView_MPI_DA() causes them to printed out in ?natural ordering? related to the grid instead of PETSc parallel ordering. It is perhaps a case of Barry being too clever for his own good. >> >> SNESTestJacobian() has the code: >> >> ``` >> PetscCall(MatGetType(A, &mattype)); >> PetscCall(MatGetSize(A, &M, &N)); >> PetscCall(MatGetLocalSize(A, &m, &n)); >> PetscCall(MatCreate(PetscObjectComm((PetscObject)A), &B)); >> PetscCall(MatSetType(B, mattype)); >> PetscCall(MatSetSizes(B, m, n, M, N)); >> PetscCall(MatSetBlockSizesFromMats(B, A, A)); >> PetscCall(MatSetUp(B)); >> PetscCall(MatSetOption(B, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE)); >> >> PetscCall(SNESGetFunction(snes, NULL, NULL, &functx)); >> PetscCall(SNESComputeJacobianDefault(snes, x, B, B, functx)); >> ``` >> >> It does not use MatDuplicate() hence the B (finite difference matrix) does not inherit the MatView_MPI_DA() function. >> >> Could you please try the following. Edit src/snes/interface/snes.c and locate the routine SNESTestJacobian() and replace the block of code that creates the B matrix above with >> >> ``` >> PetscCall(MatDuplicate(B, MAT_DO_NOT_COPY_VALUES, &D)); >> ``` >> >> Then run make all in the PETSc home directory. Then rerun your program. The plan is now both matrices will be displayed in the same ordering (natural ordering on the multidimensional grid) and so the three matrices displayed should make sense. >> >> Barry >> >> >> >> >>> On Mar 2, 2026, at 6:00?PM, Matteo Semplice via petsc-users wrote: >>> >>> It's indeed a DMDA (with 2 dofs per point), but the code is run with >>> >>> -snes_test_jacobian -snes_test_jacobian_view >>> >>> Would the hand-coded and the f.d. jacobian be different matrix type in this case? >>> >>> Matteo >>> >>> Il 02/03/26 21:32, Stefano Zampini ha scritto: >>>> Maybe you are using a DMDA, with one matrix coming from it and the other not? DMDA changes the View to dump in natural ordering. >>>> >>>> Il giorno lun 2 mar 2026 alle ore 18:10 Matteo Semplice via petsc-users > ha scritto: >>>>> Dear all, >>>>> >>>>> the following output from -snes_test_jacobian_view lokks clear enough to pinpoint my mistake (I must be putting jacobian elements in the wrong place), but it nevertheless left me suprised. >>>>> >>>>> 0 SNES Function norm 2.945516399303e-01 >>>>> ---------- Testing Jacobian ------------- >>>>> Testing hand-coded Jacobian, if (for double precision runs) ||J - Jfd||_F/||J||_F is >>>>> O(1.e-8), the hand-coded Jacobian is probably correct. >>>>> ||J - Jfd||_F/||J||_F = 0.000121529, ||J - Jfd||_F = 0.395752 >>>>> Hand-coded Jacobian ---------- >>>>> Mat Object: 4 MPI processes >>>>> row 84: (84, 60.) (85, 0.) (3446, -80.) (3447, 0.) (6808, 20.) (6809, 0.) >>>>> row 85: (84, 0.00914434) (85, 1.) (3446, 0.) (3447, 0.) (6808, 0.) (6809, 0.) >>>>> >>>>> Finite difference Jacobian ---------- >>>>> Mat Object: 4 MPI processes >>>>> type: mpiaij >>>>> row 84: (84, 60.) (1806, -80.) (3528, 20.) >>>>> row 85: (85, 0.999971) >>>>> >>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>>>> Mat Object: 4 MPI processes >>>>> type: mpiaij >>>>> row 84: >>>>> row 85: (84, 0.00914434) (85, 2.9293e-05) >>>>> The difference of the two matrices shoudl be nonzero in row 84 for all elements 1806, 3528, 3446, 6808. Is it intended that the difference is shown only for matrix elements that are present in both the hand-coded and the FD jacobian? >>>>> >>>>> I would have expected an output like >>>>> >>>>> row 84: (1806,80.) (3446,-80.), etc >>>>> >>>>> (This was on PETSc Release Version 3.24.2) >>>>> >>>>> Thanks >>>>> >>>>> Matteo >>>>> >>>>> -- >>>>> Prof. Matteo Semplice >>>>> Universit? degli Studi dell?Insubria >>>>> Dipartimento di Scienza e Alta Tecnologia ? DiSAT >>>>> Professore Associato >>>>> Via Valleggio, 11 ? 22100 Como (CO) ? Italia >>>>> tel.: +39 031 2386316 >>>> >>>> >>>> >>>> -- >>>> Stefano >>> -- >>> --- >>> Professore Associato in Analisi Numerica >>> Dipartimento di Scienza e Alta Tecnologia >>> Universit? degli Studi dell'Insubria >>> Via Valleggio, 11 - Como >> > -- > Prof. Matteo Semplice > Universit? degli Studi dell?Insubria > Dipartimento di Scienza e Alta Tecnologia ? DiSAT > Professore Associato > Via Valleggio, 11 ? 22100 Como (CO) ? Italia > tel.: +39 031 2386316 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpraveen at gmail.com Tue Mar 3 20:22:30 2026 From: cpraveen at gmail.com (Praveen C) Date: Wed, 4 Mar 2026 07:52:30 +0530 Subject: [petsc-users] Preconditioners with block matrix In-Reply-To: References: Message-ID: <6EEE598B-4D6B-4863-A1F1-0FED59AC46F0@gmail.com> Thank you very much for explaining the current status of this. If this is implemented, will the conversion have a significant overhead ? In a time dependent computation, if the preconditioner has to be recomputed each time, and also the conversion will happen everytime, will the conversion time be something to worry about ? regards praveen > On 3 Mar 2026, at 1:23?AM, Barry Smith wrote: > > > >> On Mar 2, 2026, at 8:13?AM, Praveen C wrote: >> >> Hello >> >> I am using PETSc with deal.II. My matrix is defined as PETScWrappers::BlockSparseMatrix which uses MATNEST. >> >> Is it possible to use PCILU (in serial) or PCHYPRE with such a matrix ? > > Hypre has its own matrix format which we map to using MatConvert(mat, MATHYPRE) so it depends on whether the converter is general enough to convert from Nest. Likely the converter needs to be written (it would be straight to write such a convert. > > Similarly PCILU is likely hardwired for AIJ and BAIJ so would need a converter. > > In general MatNest is used to capture some nested structure of the matrix. This nested structure is taken advantage of in assembling (building) the matrix and then later in preconditioning the matrix. Hypre and ILU in general do not/cannot take advantage of that structure so are not likely to be the best solvers in general when using MatNest. > > That said, we should provide converters so that you can trivially do what you request. > > Barry > >> >> thanks >> praveen > From m.molinos at upm.es Fri Mar 6 05:35:31 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Fri, 6 Mar 2026 12:35:31 +0100 Subject: [petsc-users] VecConcatenate vs VecCreateNest for coupled problems Message-ID: <321D66A5-A845-4FC4-B3F6-1CD4FF80CD42@upm.es> Dear all, I am solving a nonlinear system with SNES that comes from the stationary conditions of a scalar functional (L): \frac{\partial L}{\partial F} = 0, \frac{\partial L}{\partial \sigma_q} = 0 where (F) has size 3 and (\sigma_q) contains (N) particle variables, so the global unknown vector has size (3*N_rank + N). And, locally, each rank has a local vector (3+N_local). I am currently using SNES with GMRES to solve the problem since I can not compute the Jacobian analytically. I have a couple of questions: I originally constructed the solution vector as a single contiguous vector (effectively [F | sigma]) with VecConcatenate, but I recently switched to VecCreateNest to represent the block structure. However, the solver seems to perform better with VecConcatenate. Is this expected when using GMRES, if no block preconditioner is used? The system has a known null space associated with the (sigma) variables. Since I am not assembling the Jacobian explicitly, what is the recommended way to provide this null space to the solver? Should it still be attached to the operator with MatSetNullSpace when using -snes_mf? Any advice or best practices would be very helpful. Best regards, Miguel ? Miguel Molinos Escuela de Ingenieros de Caminos, Canales y Puertos Dep. Mec?nica Medios Continuos y Teor?a de Estructuras Prof. Aranguren, 3 - Ciudad Universitaria. Planta 9. 28040, Madrid ? m.molinos at upm.es ? +34 910 67 44 28 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: upm.png Type: image/png Size: 9335 bytes Desc: not available URL: From matthieu.noel at inria.fr Tue Mar 10 03:29:28 2026 From: matthieu.noel at inria.fr (Matthieu Noel) Date: Tue, 10 Mar 2026 09:29:28 +0100 Subject: [petsc-users] Request for Assistance with Parallel Matrix Solving Using petsc4py in EasyFEA Message-ID: Dear PETSc users, My name is Matthieu Noel, and I am a research software engineer at INRIA. During my PhD thesis, I developed *EasyFEA*, an open-source finite element analysis tool documented here: https://urldefense.us/v3/__https://easyfea.readthedocs.io/en/stable/__;!!G_uCfscf7eWS!flSI4RbIKcgCgsNyOejSxJzr9vPWftTgzTVo2hSxHxa1AjYCAMppGknY5M5EGs9muBjuX4s8jfd0PCpQUkoOjKZWz9tvihE$ . I am currently working on *Issue #26* (https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/issues/26__;!!G_uCfscf7eWS!flSI4RbIKcgCgsNyOejSxJzr9vPWftTgzTVo2hSxHxa1AjYCAMppGknY5M5EGs9muBjuX4s8jfd0PCpQUkoOjKZWmhF-Su0$ ), where I aim to use *petsc4py* to solve a simple stationary thermal problem in parallel. The main challenge is *constructing and solving the parallel matrix system* (|Ax = b|). Current Status: * *Mesh partitioning* has been successfully performed using *GMSH*. * EasyFEA provides the *assembled matrix system* (|Ax = b|) with applied boundary conditions. * My current implementation using *petsc4py* runs without errors, but the results obtained are incorrect. I suspect the problem lies in how the *parallel matrix and vectors are assembled or solved*, particularly in handling *ghost DOFs* and ensuring proper communication between MPI ranks. I would be extremely grateful for any guidance, resources, or examples you could share to help me address this issue. My current development branch is available here: https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/tree/26_mpi__;!!G_uCfscf7eWS!flSI4RbIKcgCgsNyOejSxJzr9vPWftTgzTVo2hSxHxa1AjYCAMppGknY5M5EGs9muBjuX4s8jfd0PCpQUkoOjKZWW8q1-8I$ . The PETSc function can be found at this link: https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/blob/26_mpi/EasyFEA/Simulations/Solvers.py*L649-L767__;Iw!!G_uCfscf7eWS!flSI4RbIKcgCgsNyOejSxJzr9vPWftTgzTVo2hSxHxa1AjYCAMppGknY5M5EGs9muBjuX4s8jfd0PCpQUkoOjKZWlmD8DH8$ I am currently running the script in the attached files. Thank you in advance for your time and expertise. Best regards, Matthieu Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DbhO7xbQSISvapJk.png Type: image/png Size: 213174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Thermal1.py Type: text/x-python-script Size: 2559 bytes Desc: not available URL: From bsmith at petsc.dev Wed Mar 11 15:56:43 2026 From: bsmith at petsc.dev (Barry Smith) Date: Wed, 11 Mar 2026 16:56:43 -0400 Subject: [petsc-users] Request for Assistance with Parallel Matrix Solving Using petsc4py in EasyFEA In-Reply-To: References: Message-ID: Does it compute the ?correct? result with one MPI process? > On Mar 10, 2026, at 4:29?AM, Matthieu Noel wrote: > > Dear PETSc users, > > My name is Matthieu Noel, and I am a research software engineer at INRIA. > > During my PhD thesis, I developed EasyFEA, an open-source finite element analysis tool documented here: https://urldefense.us/v3/__https://easyfea.readthedocs.io/en/stable/__;!!G_uCfscf7eWS!amVjI34KAEi2OPKDSvbAf_KFPOQhJrRXO699hc77p7t_jxsDTydSHMdI9UyytIKID9qvprkJ7WKI-kGnJEmhU_Q$ . > > I am currently working on Issue #26 (https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/issues/26__;!!G_uCfscf7eWS!amVjI34KAEi2OPKDSvbAf_KFPOQhJrRXO699hc77p7t_jxsDTydSHMdI9UyytIKID9qvprkJ7WKI-kGnGJrxEcw$ ), where I aim to use petsc4py to solve a simple stationary thermal problem in parallel. > > The main challenge is constructing and solving the parallel matrix system (Ax = b). > > Current Status: > > Mesh partitioning has been successfully performed using GMSH. > EasyFEA provides the assembled matrix system (Ax = b) with applied boundary conditions. > My current implementation using petsc4py runs without errors, but the results obtained are incorrect. > > I suspect the problem lies in how the parallel matrix and vectors are assembled or solved, particularly in handling ghost DOFs and ensuring proper communication between MPI ranks. > > I would be extremely grateful for any guidance, resources, or examples you could share to help me address this issue. > My current development branch is available here: https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/tree/26_mpi__;!!G_uCfscf7eWS!amVjI34KAEi2OPKDSvbAf_KFPOQhJrRXO699hc77p7t_jxsDTydSHMdI9UyytIKID9qvprkJ7WKI-kGn21mLc64$ . > > The PETSc function can be found at this link: https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/blob/26_mpi/EasyFEA/Simulations/Solvers.py*L649-L767__;Iw!!G_uCfscf7eWS!amVjI34KAEi2OPKDSvbAf_KFPOQhJrRXO699hc77p7t_jxsDTydSHMdI9UyytIKID9qvprkJ7WKI-kGn3ULFHJE$ > I am currently running the script in the attached files. > > > Thank you in advance for your time and expertise. > > > Best regards, > Matthieu Noel > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Sun Mar 15 09:29:58 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Sun, 15 Mar 2026 14:29:58 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView Message-ID: Hello, Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: ---- 0.531360000000 0.066670000000 0.197333333327 0.066670000000 0.535360000000 -0.003333333327 0.197333333327 -0.003333333327 0.527413333333 ---- (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: ---- Mat Object: 1 MPI process type: seqaij row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): ---- ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 Hand-coded Jacobian ---------- Mat Object: 1 MPI process type: seqaij row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) Finite difference Jacobian ---------- Mat Object: 1 MPI process type: seqaij row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- Mat Object: 1 MPI process type: seqaij row 0: (0, 2.66554e-05) row 1: (1, 2.66554e-05) row 2: (2, 2.6558e-05) ---- The main code is in Fortran, using double precision variables, in case it is relevant. Thank you. Noam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Sun Mar 15 10:19:33 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Sun, 15 Mar 2026 15:19:33 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: A bit more information: Looking at the solution of the system of equations, knowing the exact RHS vector: --- [-0.00197, 0.00203, -0.00197] --- SNES gives the solution: --- 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 --- which is indeed (closer to) the solution for the jacobian shown in MatView (the "lower precision" one). The "exact" solution would be: --- 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 --- which is already different form the second decimal digit. *** Requesting a low precision to have SNES do a few iterations, shows that the built jacobian seems to deviate more and more form the computed one after some iterations, e.g.: Computed (printed from in-code): --- 0.536488494840 0.066474939660 0.198813816284 0.066474939660 0.529482312614 -0.002835445071 0.198813816284 -0.002835445071 0.530589055263 --- MatView: --- row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) --- Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. Thank you. Noam On Sunday, March 15th, 2026 at 3:29 PM, Noam T. wrote: > Hello, > > Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. > > In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: > > ---- > 0.531360000000 0.066670000000 0.197333333327 > 0.066670000000 0.535360000000 -0.003333333327 > 0.197333333327 -0.003333333327 0.527413333333 > ---- > > (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). > > This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: > > ---- > > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- > > Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. > > Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): > > ---- > ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 > Hand-coded Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) > Finite difference Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) > row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) > row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) > Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 2.66554e-05) > row 1: (1, 2.66554e-05) > row 2: (2, 2.6558e-05) ---- > > The main code is in Fortran, using double precision variables, in case it is relevant. > > Thank you. > > Noam -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Sun Mar 15 11:10:58 2026 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 15 Mar 2026 12:10:58 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Sun, Mar 15, 2026 at 10:30?AM Noam T. via petsc-users < petsc-users at mcs.anl.gov> wrote: > Hello, > > Looking at the assembly of the Jacobian using MatView, I noticed values > were somewhat different from the computed ones in the jacobian function > (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 > quadrature points, so the exact Jacobian matrix can be computed > analytically. > > In the jacobian function, after looping through all quadrature points, > printing the matrix to stdout shows: > > ---- > 0.531360000000 0.066670000000 0.197333333327 > 0.066670000000 0.535360000000 -0.003333333327 > 0.197333333327 -0.003333333327 0.527413333333 > ---- > > (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly > four/five nonzero digits, as shown above. The rest of the elements have a > periodic 3 ending (a couple of digits at the end are off, but that's fine). > > This same matrix is the one added to the global jacobian during the > quadrature loop, with "DMPlexMatSetClosure". After looping, calling > "MatAssemblyBegin/End", then MatView: > > ---- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) > ---- > This looks like a change in the precision of output (which here seems to be 6 digits), and not in the internal representation. Thanks, Matt > Values are close, but definitely not the same as computed. Are these > values from "MatView" the ones actually stored in the matrix? It seems > there is some precision loss in the process. > > Interestingly, computing the jacobian through finite differences, shows > the same result for the "hand-coded" jacobian, whereas the finite > differences ones is the "exact" one (same as first one above): > > ---- > ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 > Hand-coded Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) > Finite difference Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) > row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) > row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) > Hand-coded minus finite-difference Jacobian with tolerance 1e-05 > ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 2.66554e-05) > row 1: (1, 2.66554e-05) > row 2: (2, 2.6558e-05) > ---- > > The main code is in Fortran, using double precision variables, in case it > is relevant. > > Thank you. > > Noam > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bCJxKi_fK-R4qOPIue1cGVfbUvleHUrCejE8OHc3uYgb5tFWMvumeRKgYa27f7q6xulACFMRRdrwtRXkP-2A$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Sun Mar 15 11:12:01 2026 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 15 Mar 2026 12:12:01 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users < petsc-users at mcs.anl.gov> wrote: > A bit more information: > > Looking at the solution of the system of equations, knowing the exact RHS > vector: > --- > [-0.00197, 0.00203, -0.00197] > --- > > SNES gives the solution: > --- > 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 > --- > > which is indeed (closer to) the solution for the jacobian shown in MatView > (the "lower precision" one). The "exact" solution would be: > --- > 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 > --- > > which is already different form the second decimal digit. > Are you using an exact solution method, like LU? Thanks, Matt > > *** > Requesting a low precision to have SNES do a few iterations, shows that > the built jacobian seems to deviate more and more form the computed one > after some iterations, e.g.: > > Computed (printed from in-code): > --- > 0.536488494840 0.066474939660 0.198813816284 > 0.066474939660 0.529482312614 -0.002835445071 > 0.198813816284 -0.002835445071 0.530589055263 > --- > > MatView: > --- > row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) > row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) > row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) > --- > > Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. > > Thank you. > Noam > > > On Sunday, March 15th, 2026 at 3:29 PM, Noam T. > wrote: > > Hello, > > Looking at the assembly of the Jacobian using MatView, I noticed values > were somewhat different from the computed ones in the jacobian function > (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 > quadrature points, so the exact Jacobian matrix can be computed > analytically. > > In the jacobian function, after looping through all quadrature points, > printing the matrix to stdout shows: > > ---- > 0.531360000000 0.066670000000 0.197333333327 > 0.066670000000 0.535360000000 -0.003333333327 > 0.197333333327 -0.003333333327 0.527413333333 > ---- > > (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly > four/five nonzero digits, as shown above. The rest of the elements have a > periodic 3 ending (a couple of digits at the end are off, but that's fine). > > This same matrix is the one added to the global jacobian during the > quadrature loop, with "DMPlexMatSetClosure". After looping, calling > "MatAssemblyBegin/End", then MatView: > > ---- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) > ---- > > Values are close, but definitely not the same as computed. Are these > values from "MatView" the ones actually stored in the matrix? It seems > there is some precision loss in the process. > > Interestingly, computing the jacobian through finite differences, shows > the same result for the "hand-coded" jacobian, whereas the finite > differences ones is the "exact" one (same as first one above): > > ---- > ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 > Hand-coded Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) > row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) > row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) > Finite difference Jacobian ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) > row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) > row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) > Hand-coded minus finite-difference Jacobian with tolerance 1e-05 > ---------- > Mat Object: 1 MPI process > type: seqaij > row 0: (0, 2.66554e-05) > row 1: (1, 2.66554e-05) > row 2: (2, 2.6558e-05) > ---- > > The main code is in Fortran, using double precision variables, in case it > is relevant. > > Thank you. > > Noam > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aG7692I0cAJ6_5ASPxacsW2kfd1x_zlBDB_pNqHAWEF8Xp_sDoXgg6uSoo0rZxD62Wd5jE29HQ8JqdWSNidk$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Sun Mar 15 11:58:02 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Sun, 15 Mar 2026 16:58:02 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: The results above of the SNES output were using the flags -ksp_type fgmres -pc_type lu Thanks On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley wrote: > On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users wrote: > >> A bit more information: >> >> Looking at the solution of the system of equations, knowing the exact RHS vector: >> --- >> [-0.00197, 0.00203, -0.00197] >> --- >> >> SNES gives the solution: >> --- >> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >> --- >> >> which is indeed (closer to) the solution for the jacobian shown in MatView (the "lower precision" one). The "exact" solution would be: >> --- >> >> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >> --- >> >> which is already different form the second decimal digit. > > Are you using an exact solution method, like LU? > > Thanks, > > Matt > >> *** >> Requesting a low precision to have SNES do a few iterations, shows that the built jacobian seems to deviate more and more form the computed one after some iterations, e.g.: >> >> Computed (printed from in-code): >> --- >> 0.536488494840 0.066474939660 0.198813816284 >> 0.066474939660 0.529482312614 -0.002835445071 >> 0.198813816284 -0.002835445071 0.530589055263 >> --- >> >> MatView: >> --- >> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) --- >> >> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >> >> Thank you. >> Noam >> >> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. wrote: >> >>> Hello, >>> >>> Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. >>> >>> In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: >>> >>> ---- >>> 0.531360000000 0.066670000000 0.197333333327 >>> 0.066670000000 0.535360000000 -0.003333333327 >>> 0.197333333327 -0.003333333327 0.527413333333 >>> ---- >>> >>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). >>> >>> This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: >>> >>> ---- >>> >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- >>> >>> Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. >>> >>> Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): >>> >>> ---- >>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>> Hand-coded Jacobian ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>> Finite difference Jacobian ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 2.66554e-05) >>> row 1: (1, 2.66554e-05) >>> row 2: (2, 2.6558e-05) ---- >>> >>> The main code is in Fortran, using double precision variables, in case it is relevant. >>> >>> Thank you. >>> >>> Noam > > -- > > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!a5khwe_QmVio9YReG8ZoVU1_d56gBpman5LPTy7KoLYK7Hhj8iyb_R2kEwE2J103gQEvNdTUmdenMiEu9H_5Txy1RDVJUL36$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Sun Mar 15 12:16:38 2026 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 15 Mar 2026 13:16:38 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Sun, Mar 15, 2026 at 12:58?PM Noam T. wrote: > The results above of the SNES output were using the flags > > -ksp_type fgmres -pc_type lu > This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. Thanks, Matt > Thanks > On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley > wrote: > > On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users < > petsc-users at mcs.anl.gov> wrote: > >> A bit more information: >> >> Looking at the solution of the system of equations, knowing the exact RHS >> vector: >> --- >> [-0.00197, 0.00203, -0.00197] >> --- >> >> SNES gives the solution: >> --- >> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >> --- >> >> which is indeed (closer to) the solution for the jacobian shown in >> MatView (the "lower precision" one). The "exact" solution would be: >> --- >> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >> --- >> >> which is already different form the second decimal digit. >> > > Are you using an exact solution method, like LU? > > Thanks, > > Matt > >> >> *** >> Requesting a low precision to have SNES do a few iterations, shows that >> the built jacobian seems to deviate more and more form the computed one >> after some iterations, e.g.: >> >> Computed (printed from in-code): >> --- >> 0.536488494840 0.066474939660 0.198813816284 >> 0.066474939660 0.529482312614 -0.002835445071 >> 0.198813816284 -0.002835445071 0.530589055263 >> --- >> >> MatView: >> --- >> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) >> --- >> >> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >> >> Thank you. >> Noam >> >> >> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. >> wrote: >> >> Hello, >> >> Looking at the assembly of the Jacobian using MatView, I noticed values >> were somewhat different from the computed ones in the jacobian function >> (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 >> quadrature points, so the exact Jacobian matrix can be computed >> analytically. >> >> In the jacobian function, after looping through all quadrature points, >> printing the matrix to stdout shows: >> >> ---- >> 0.531360000000 0.066670000000 0.197333333327 >> 0.066670000000 0.535360000000 -0.003333333327 >> 0.197333333327 -0.003333333327 0.527413333333 >> ---- >> >> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly >> four/five nonzero digits, as shown above. The rest of the elements have a >> periodic 3 ending (a couple of digits at the end are off, but that's fine). >> >> This same matrix is the one added to the global jacobian during the >> quadrature loop, with "DMPlexMatSetClosure". After looping, calling >> "MatAssemblyBegin/End", then MatView: >> >> ---- >> Mat Object: 1 MPI process >> type: seqaij >> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >> ---- >> >> Values are close, but definitely not the same as computed. Are these >> values from "MatView" the ones actually stored in the matrix? It seems >> there is some precision loss in the process. >> >> Interestingly, computing the jacobian through finite differences, shows >> the same result for the "hand-coded" jacobian, whereas the finite >> differences ones is the "exact" one (same as first one above): >> >> ---- >> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >> Hand-coded Jacobian ---------- >> Mat Object: 1 MPI process >> type: seqaij >> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >> Finite difference Jacobian ---------- >> Mat Object: 1 MPI process >> type: seqaij >> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 >> ---------- >> Mat Object: 1 MPI process >> type: seqaij >> row 0: (0, 2.66554e-05) >> row 1: (1, 2.66554e-05) >> row 2: (2, 2.6558e-05) >> ---- >> >> The main code is in Fortran, using double precision variables, in case it >> is relevant. >> >> Thank you. >> >> Noam >> >> >> >> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eGTEuz8e1jWJOAiwUd1CLQkgkPAhAAcf10wictCvTizk9RwhXbC14FDmnjsT4sT3bzYiJx0GTtqMyqq6DLXp$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eGTEuz8e1jWJOAiwUd1CLQkgkPAhAAcf10wictCvTizk9RwhXbC14FDmnjsT4sT3bzYiJx0GTtqMyqq6DLXp$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Sun Mar 15 16:24:33 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Sun, 15 Mar 2026 21:24:33 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: > This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. This is indeed the case. > To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. I imagined this was simply a printing artifact. However, something is bugging me: the message from finite differences jacobian. The printed jacobian from finite differences is exactly the computed one (see below). If the differences from MatView were simply from printing, the error between finite difference and "in-code" should be (much closer to) zero, not 1e-5. So I did a couple more checks, avoiding calls to "XView" type of functions, and getting a single value directly: (For comparison) Computed matrix in the jacobian function (used to assemble) ---- 0.531360000000 0.066670000000 0.197333333327 0.066670000000 0.535360000000 -0.003333333327 0.197333333327 -0.003333333327 0.527413333333 ---- ** Calling "MatGetValues" and then printing them all: 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 These are the same values shown as when calling MatView. They are all quite off. There is for example a difference of 5e-4 for entry (0,0). Just in case I messed up the precision, the closest single-precision value for entry (0,0) is 0x1.100e6p-1 = 0.53135997... ** 2-norm of the assembled matrix times a vector [1,1,1] 1.2294717692646715 This is _exactly_ the norm using the matrix from MatView (i.e. the one from MatGetValues) times [1,1,1]. The original/assembled matrix times [1,1,1] should be 1.229421704786441 -- difference of 5e-5 Am I accessing stored/assembled values the wrong way so that they all are always off when printed? Or am I missing something else? Thanks On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley wrote: > On Sun, Mar 15, 2026 at 12:58?PM Noam T. wrote: > >> The results above of the SNES output were using the flags >> >> -ksp_type fgmres -pc_type lu > > This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. > > To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. > > Thanks, > > Matt > >> Thanks >> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley wrote: >> >>> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users wrote: >>> >>>> A bit more information: >>>> >>>> Looking at the solution of the system of equations, knowing the exact RHS vector: >>>> --- >>>> [-0.00197, 0.00203, -0.00197] >>>> --- >>>> >>>> SNES gives the solution: >>>> --- >>>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>>> --- >>>> >>>> which is indeed (closer to) the solution for the jacobian shown in MatView (the "lower precision" one). The "exact" solution would be: >>>> --- >>>> >>>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>>> --- >>>> >>>> which is already different form the second decimal digit. >>> >>> Are you using an exact solution method, like LU? >>> >>> Thanks, >>> >>> Matt >>> >>>> *** >>>> Requesting a low precision to have SNES do a few iterations, shows that the built jacobian seems to deviate more and more form the computed one after some iterations, e.g.: >>>> >>>> Computed (printed from in-code): >>>> --- >>>> 0.536488494840 0.066474939660 0.198813816284 >>>> 0.066474939660 0.529482312614 -0.002835445071 >>>> 0.198813816284 -0.002835445071 0.530589055263 >>>> --- >>>> >>>> MatView: >>>> --- >>>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) --- >>>> >>>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>>> >>>> Thank you. >>>> Noam >>>> >>>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. wrote: >>>> >>>>> Hello, >>>>> >>>>> Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. >>>>> >>>>> In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: >>>>> >>>>> ---- >>>>> 0.531360000000 0.066670000000 0.197333333327 >>>>> 0.066670000000 0.535360000000 -0.003333333327 >>>>> 0.197333333327 -0.003333333327 0.527413333333 >>>>> ---- >>>>> >>>>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). >>>>> >>>>> This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: >>>>> >>>>> ---- >>>>> >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- >>>>> >>>>> Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. >>>>> >>>>> Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): >>>>> >>>>> ---- >>>>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>>>> Hand-coded Jacobian ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>>> Finite difference Jacobian ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>>>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>>>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 2.66554e-05) >>>>> row 1: (1, 2.66554e-05) >>>>> row 2: (2, 2.6558e-05) ---- >>>>> >>>>> The main code is in Fortran, using double precision variables, in case it is relevant. >>>>> >>>>> Thank you. >>>>> >>>>> Noam >>> >>> -- >>> >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!Zf2ZYIZGNoib5F2A2Unu3G3LpY2wT2rYE7OF3enm_k8SAy-TleMkYhEKs_obxc3G9wFif-OPNaETs-s-ffLWf9spj4lpQCW7$ > > -- > > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!Zf2ZYIZGNoib5F2A2Unu3G3LpY2wT2rYE7OF3enm_k8SAy-TleMkYhEKs_obxc3G9wFif-OPNaETs-s-ffLWf9spj4lpQCW7$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Sun Mar 15 17:04:44 2026 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 15 Mar 2026 18:04:44 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Sun, Mar 15, 2026 at 5:24?PM Noam T. wrote: > This is very easy to check. Multiply the solution by your matrix and > subtract the RHS. It must satisfy the tolerance you have for the solver. If > not, there is some other problem, but I imagine it does, which is what we > mean by the solution. > > > This is indeed the case. > > > To answer the first question, there is no reduction in precision in > MatSetValues(). I am sure if you carry out the addition by hand you will > see that the result is within 1ulp as it should be from the standard. > > > I imagined this was simply a printing artifact. However, something is > bugging me: the message from finite differences jacobian. > > The printed jacobian from finite differences is exactly the computed one > (see below). If the differences from MatView were simply from printing, the > error between finite difference and "in-code" should be (much closer to) > zero, not 1e-5. > > So I did a couple more checks, avoiding calls to "XView" type of > functions, and getting a single value directly: > > (For comparison) Computed matrix in the jacobian function (used to > assemble) > ---- > 0.531360000000 0.066670000000 0.197333333327 > 0.066670000000 0.535360000000 -0.003333333327 > 0.197333333327 -0.003333333327 0.527413333333 > ---- > > ** Calling "MatGetValues" and then printing them all: > > 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 > 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 > 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 > So the claim is that you have some small matrix (the first) and you call MatSetValues() to put it in a big matrix, and you get different values in the big matrix? I am confident that this is impossible. So, in order to verify this, it should be easy to 1) Run in the debugger 2) Stop in MatSetValues() 3) Print out the input array v[] (you should get the first matrix in full precision) 4) You could tace down to where each value is entered, but it might be easier to 5) Call https://urldefense.us/v3/__https://petsc.org/main/manualpages/Mat/MatSeqAIJGetArray/__;!!G_uCfscf7eWS!Zfo59ELDNQEj7_52YmMFINuHw7PsOrHM9FLA6nEtPQoZb6T0J-cwsVCJhIILqNlPTSNx1bunO62Z1EToyltK$ and look directly at the array right after the call to MatSetValues() Thanks, Matt > These are the same values shown as when calling MatView. > They are all quite off. There is for example a difference of 5e-4 for > entry (0,0). > Just in case I messed up the precision, the closest single-precision value > for entry (0,0) is 0x1.100e6p-1 = 0.53135997... > > ** 2-norm of the assembled matrix times a vector [1,1,1] > 1.2294717692646715 > > This is _exactly_ the norm using the matrix from MatView (i.e. the one > from MatGetValues) times [1,1,1]. > > The original/assembled matrix times [1,1,1] should be > 1.229421704786441 -- difference of 5e-5 > > Am I accessing stored/assembled values the wrong way so that they all are > always off when printed? Or am I missing something else? > > Thanks > > > On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley > wrote: > > On Sun, Mar 15, 2026 at 12:58?PM Noam T. wrote: > >> The results above of the SNES output were using the flags >> >> -ksp_type fgmres -pc_type lu >> > > This is very easy to check. Multiply the solution by your matrix and > subtract the RHS. It must satisfy the tolerance you have for the solver. If > not, there is some other problem, but I imagine it does, which is what we > mean by the solution. > > To answer the first question, there is no reduction in precision in > MatSetValues(). I am sure if you carry out the addition by hand you will > see that the result is within 1ulp as it should be from the standard. > > Thanks, > > Matt > >> Thanks >> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley < >> knepley at gmail.com> wrote: >> >> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users < >> petsc-users at mcs.anl.gov> wrote: >> >>> A bit more information: >>> >>> Looking at the solution of the system of equations, knowing the exact >>> RHS vector: >>> --- >>> [-0.00197, 0.00203, -0.00197] >>> --- >>> >>> SNES gives the solution: >>> --- >>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>> --- >>> >>> which is indeed (closer to) the solution for the jacobian shown in >>> MatView (the "lower precision" one). The "exact" solution would be: >>> --- >>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>> --- >>> >>> which is already different form the second decimal digit. >>> >> >> Are you using an exact solution method, like LU? >> >> Thanks, >> >> Matt >> >>> >>> *** >>> Requesting a low precision to have SNES do a few iterations, shows that >>> the built jacobian seems to deviate more and more form the computed one >>> after some iterations, e.g.: >>> >>> Computed (printed from in-code): >>> --- >>> 0.536488494840 0.066474939660 0.198813816284 >>> 0.066474939660 0.529482312614 -0.002835445071 >>> 0.198813816284 -0.002835445071 0.530589055263 >>> --- >>> >>> MatView: >>> --- >>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) >>> --- >>> >>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>> >>> Thank you. >>> Noam >>> >>> >>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. < >>> dontbugthedevs at proton.me> wrote: >>> >>> Hello, >>> >>> Looking at the assembly of the Jacobian using MatView, I noticed values >>> were somewhat different from the computed ones in the jacobian function >>> (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 >>> quadrature points, so the exact Jacobian matrix can be computed >>> analytically. >>> >>> In the jacobian function, after looping through all quadrature points, >>> printing the matrix to stdout shows: >>> >>> ---- >>> 0.531360000000 0.066670000000 0.197333333327 >>> 0.066670000000 0.535360000000 -0.003333333327 >>> 0.197333333327 -0.003333333327 0.527413333333 >>> ---- >>> >>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly >>> four/five nonzero digits, as shown above. The rest of the elements have a >>> periodic 3 ending (a couple of digits at the end are off, but that's fine). >>> >>> This same matrix is the one added to the global jacobian during the >>> quadrature loop, with "DMPlexMatSetClosure". After looping, calling >>> "MatAssemblyBegin/End", then MatView: >>> >>> ---- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>> ---- >>> >>> Values are close, but definitely not the same as computed. Are these >>> values from "MatView" the ones actually stored in the matrix? It seems >>> there is some precision loss in the process. >>> >>> Interestingly, computing the jacobian through finite differences, shows >>> the same result for the "hand-coded" jacobian, whereas the finite >>> differences ones is the "exact" one (same as first one above): >>> >>> ---- >>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>> Hand-coded Jacobian ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>> Finite difference Jacobian ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 >>> ---------- >>> Mat Object: 1 MPI process >>> type: seqaij >>> row 0: (0, 2.66554e-05) >>> row 1: (1, 2.66554e-05) >>> row 2: (2, 2.6558e-05) >>> ---- >>> >>> The main code is in Fortran, using double precision variables, in case >>> it is relevant. >>> >>> Thank you. >>> >>> Noam >>> >>> >>> >>> >> >> -- >> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Zfo59ELDNQEj7_52YmMFINuHw7PsOrHM9FLA6nEtPQoZb6T0J-cwsVCJhIILqNlPTSNx1bunO62Z1JIkGzX5$ >> >> >> >> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Zfo59ELDNQEj7_52YmMFINuHw7PsOrHM9FLA6nEtPQoZb6T0J-cwsVCJhIILqNlPTSNx1bunO62Z1JIkGzX5$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Zfo59ELDNQEj7_52YmMFINuHw7PsOrHM9FLA6nEtPQoZb6T0J-cwsVCJhIILqNlPTSNx1bunO62Z1JIkGzX5$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Tue Mar 17 03:48:25 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Tue, 17 Mar 2026 09:48:25 +0100 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations Message-ID: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Dear all, I am currently running a PIC-like implementation based on DMSwarm and DMDA. In my setup, a particle (DMSwarm) discretization represents, for example, a sphere placed at the center of a box-shaped domain discretized with a regular mesh (DMDA). The implementation uses both MPI and OpenMP to accelerate the computations. The domain decomposition of the sphere follows a PIC-like approach: each particle is assigned to a rank based on the mesh element it belongs to, and thus inherits the rank that ?owns? that element. This is essentially the same strategy used in one of the PETSc examples. However, I have observed that, for certain configurations, some ranks end up with very few or even no particles, which leads to load imbalance. Has anyone experienced a similar issue? Thanks, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfadams at lbl.gov Tue Mar 17 06:17:26 2026 From: mfadams at lbl.gov (Mark Adams) Date: Tue, 17 Mar 2026 07:17:26 -0400 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: Hi Miguel, This is a common problem. To my knowledge you need to deal with it on your side, but PETSc does have tools to help. I would look in the literature to get ideas and acclimate yourself to the problem. The tool that PETSc has is you can repartition your mesh. Create a dual graph (any petsc examples?) put weights on the "vertice" (now elements, use particle count) and repartition. I am not sure of the best way to proceed from here ... you could create a new DMSwarm with this new "cell" DM and add particles from the old to the new, delete the old, call DMMigrate on the new DMSwarm and that will do the moving that we want. Others will probably be able to add to this. Thanks, Mark On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos wrote: > Dear all, > > I am currently running a PIC-like implementation based on DMSwarm and > DMDA. In my setup, a particle (DMSwarm) discretization represents, for > example, a sphere placed at the center of a box-shaped domain discretized > with a regular mesh (DMDA). > > The implementation uses both MPI and OpenMP to accelerate the > computations. The domain decomposition of the sphere follows a PIC-like > approach: each particle is assigned to a rank based on the mesh element it > belongs to, and thus inherits the rank that ?owns? that element. This is > essentially the same strategy used in one of the PETSc examples. > > However, I have observed that, for certain configurations, some ranks end > up with very few or even no particles, which leads to load imbalance. > > Has anyone experienced a similar issue? > > Thanks, > Miguel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Tue Mar 17 06:53:51 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Tue, 17 Mar 2026 12:53:51 +0100 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: Thank you Mark. Indeed my question was oriented towards the tools PETSc can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex is more suited? Thanks, Miguel > On 17 Mar 2026, at 12:17, Mark Adams wrote: > > Hi Miguel, > > This is a common problem. To my knowledge you need to deal with it on your side, but PETSc does have tools to help. > I would look in the literature to get ideas and acclimate yourself to the problem. > > The tool that PETSc has is you can repartition your mesh. Create a dual graph (any petsc examples?) put weights on the "vertice" (now elements, use particle count) and repartition. > I am not sure of the best way to proceed from here ... you could create a new DMSwarm with this new "cell" DM and add particles from the old to the new, delete the old, call DMMigrate on the new DMSwarm and that will do the moving that we want. > > Others will probably be able to add to this. > > Thanks, > Mark > > > On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos > wrote: >> >> Dear all, >> >> I am currently running a PIC-like implementation based on DMSwarm and DMDA. In my setup, a particle (DMSwarm) discretization represents, for example, a sphere placed at the center of a box-shaped domain discretized with a regular mesh (DMDA). >> >> The implementation uses both MPI and OpenMP to accelerate the computations. The domain decomposition of the sphere follows a PIC-like approach: each particle is assigned to a rank based on the mesh element it belongs to, and thus inherits the rank that ?owns? that element. This is essentially the same strategy used in one of the PETSc examples. >> >> However, I have observed that, for certain configurations, some ranks end up with very few or even no particles, which leads to load imbalance. >> >> Has anyone experienced a similar issue? >> >> Thanks, >> Miguel >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfadams at lbl.gov Tue Mar 17 07:53:13 2026 From: mfadams at lbl.gov (Mark Adams) Date: Tue, 17 Mar 2026 08:53:13 -0400 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: This tool works at the Mat level so it does not matter, but you need to work at the DM level anyway. I don't know of DM tools for this. Let Matt chime in. On Tue, Mar 17, 2026 at 7:54?AM Miguel Molinos wrote: > Thank you Mark. Indeed my question was oriented towards the tools PETSc > can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex > is more suited? > > Thanks, > Miguel > > On 17 Mar 2026, at 12:17, Mark Adams wrote: > > Hi Miguel, > > This is a common problem. To my knowledge you need to deal with it on your > side, but PETSc does have tools to help. > I would look in the literature to get ideas and acclimate yourself to the > problem. > > The tool that PETSc has is you can repartition your mesh. Create a dual > graph (any petsc examples?) put weights on the "vertice" (now elements, use > particle count) and repartition. > I am not sure of the best way to proceed from here ... you could create a > new DMSwarm with this new "cell" DM and add particles from the old to the > new, delete the old, call DMMigrate on the new DMSwarm and that will do the > moving that we want. > > Others will probably be able to add to this. > > Thanks, > Mark > > > On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos wrote: > >> >> Dear all, >> >> I am currently running a PIC-like implementation based on DMSwarm and >> DMDA. In my setup, a particle (DMSwarm) discretization represents, for >> example, a sphere placed at the center of a box-shaped domain discretized >> with a regular mesh (DMDA). >> >> The implementation uses both MPI and OpenMP to accelerate the >> computations. The domain decomposition of the sphere follows a PIC-like >> approach: each particle is assigned to a rank based on the mesh element it >> belongs to, and thus inherits the rank that ?owns? that element. This is >> essentially the same strategy used in one of the PETSc examples. >> >> However, I have observed that, for certain configurations, some ranks end >> up with very few or even no particles, which leads to load imbalance. >> >> Has anyone experienced a similar issue? >> >> Thanks, >> Miguel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Tue Mar 17 09:11:54 2026 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 17 Mar 2026 10:11:54 -0400 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: On Tue, Mar 17, 2026 at 8:53?AM Mark Adams wrote: > This tool works at the Mat level so it does not matter, but you need to > work at the DM level anyway. > > I don't know of DM tools for this. Let Matt chime in. > Hi Miguel, DMPlex can definitely do point location and load balancing, which is an advantage. A disadvantage is that you have to work harder to get structured variable access, which DMDA has automatically. Depending on your discretization on this grid, this can be restored, but it is some work. What does the algorithm look like? Thanks, Matt > On Tue, Mar 17, 2026 at 7:54?AM Miguel Molinos wrote: > >> Thank you Mark. Indeed my question was oriented towards the tools PETSc >> can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex >> is more suited? >> >> Thanks, >> Miguel >> >> On 17 Mar 2026, at 12:17, Mark Adams wrote: >> >> Hi Miguel, >> >> This is a common problem. To my knowledge you need to deal with it on >> your side, but PETSc does have tools to help. >> I would look in the literature to get ideas and acclimate yourself to the >> problem. >> >> The tool that PETSc has is you can repartition your mesh. Create a dual >> graph (any petsc examples?) put weights on the "vertice" (now elements, use >> particle count) and repartition. >> I am not sure of the best way to proceed from here ... you could create a >> new DMSwarm with this new "cell" DM and add particles from the old to the >> new, delete the old, call DMMigrate on the new DMSwarm and that will do the >> moving that we want. >> >> Others will probably be able to add to this. >> >> Thanks, >> Mark >> >> >> On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos wrote: >> >>> >>> Dear all, >>> >>> I am currently running a PIC-like implementation based on DMSwarm and >>> DMDA. In my setup, a particle (DMSwarm) discretization represents, for >>> example, a sphere placed at the center of a box-shaped domain discretized >>> with a regular mesh (DMDA). >>> >>> The implementation uses both MPI and OpenMP to accelerate the >>> computations. The domain decomposition of the sphere follows a PIC-like >>> approach: each particle is assigned to a rank based on the mesh element it >>> belongs to, and thus inherits the rank that ?owns? that element. This is >>> essentially the same strategy used in one of the PETSc examples. >>> >>> However, I have observed that, for certain configurations, some ranks >>> end up with very few or even no particles, which leads to load imbalance. >>> >>> Has anyone experienced a similar issue? >>> >>> Thanks, >>> Miguel >>> >> >> -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!YV8vir7FXIBN646nU7u5CIdRqTMT34FBX2a4QOZzsJsiHeLmYLan_Dj6YlA1fVpdf-obQxW90K9Yo6wesXZK$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Tue Mar 17 10:22:32 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Tue, 17 Mar 2026 16:22:32 +0100 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: Hi Matt and Mark, Thank you for the feedback. > A disadvantage is that you have to work harder to get structured variable access, which DMDA has > automatically. Depending on your discretization on this grid, this can be restored, but it is some work. I?ve been trying to avoid DMPlex because I find harder to create ghost particles (define padding regions) using an unstructured mesh. Regarding variable access, this is not a limitation since I use the background mesh for domain decomposition purposes. The particles carry al the information. > What does the algorithm look like? My code reproduces interaction between atoms (some sort of MD). The purposes of the mesh are: - Create a domain decomposition - Particle migration - Definition of boundary conditions (it can works like a supercell) Thanks, Miguel > On 17 Mar 2026, at 15:11, Matthew Knepley wrote: > > On Tue, Mar 17, 2026 at 8:53?AM Mark Adams > wrote: >> This tool works at the Mat level so it does not matter, but you need to work at the DM level anyway. >> >> I don't know of DM tools for this. Let Matt chime in. > > Hi Miguel, > > DMPlex can definitely do point location and load balancing, which is an advantage. > > A disadvantage is that you have to work harder to get structured variable access, which DMDA has > automatically. Depending on your discretization on this grid, this can be restored, but it is some work. > > What does the algorithm look like? > > Thanks, > > Matt > >> On Tue, Mar 17, 2026 at 7:54?AM Miguel Molinos > wrote: >>> Thank you Mark. Indeed my question was oriented towards the tools PETSc can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex is more suited? >>> >>> Thanks, >>> Miguel >>> >>>> On 17 Mar 2026, at 12:17, Mark Adams > wrote: >>>> >>>> Hi Miguel, >>>> >>>> This is a common problem. To my knowledge you need to deal with it on your side, but PETSc does have tools to help. >>>> I would look in the literature to get ideas and acclimate yourself to the problem. >>>> >>>> The tool that PETSc has is you can repartition your mesh. Create a dual graph (any petsc examples?) put weights on the "vertice" (now elements, use particle count) and repartition. >>>> I am not sure of the best way to proceed from here ... you could create a new DMSwarm with this new "cell" DM and add particles from the old to the new, delete the old, call DMMigrate on the new DMSwarm and that will do the moving that we want. >>>> >>>> Others will probably be able to add to this. >>>> >>>> Thanks, >>>> Mark >>>> >>>> >>>> On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos > wrote: >>>>> >>>>> Dear all, >>>>> >>>>> I am currently running a PIC-like implementation based on DMSwarm and DMDA. In my setup, a particle (DMSwarm) discretization represents, for example, a sphere placed at the center of a box-shaped domain discretized with a regular mesh (DMDA). >>>>> >>>>> The implementation uses both MPI and OpenMP to accelerate the computations. The domain decomposition of the sphere follows a PIC-like approach: each particle is assigned to a rank based on the mesh element it belongs to, and thus inherits the rank that ?owns? that element. This is essentially the same strategy used in one of the PETSc examples. >>>>> >>>>> However, I have observed that, for certain configurations, some ranks end up with very few or even no particles, which leads to load imbalance. >>>>> >>>>> Has anyone experienced a similar issue? >>>>> >>>>> Thanks, >>>>> Miguel >>>>> >>> > > > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!cpH9UdTT6sUkh-_I5rf6KUgixjJDW8danIFmV7MKo3yzDgoXA7ISAHsvPTxrGL0IgMVuyZPUN9uhbeloGU6CVCOZ$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Tue Mar 17 10:47:34 2026 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 17 Mar 2026 11:47:34 -0400 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: On Tue, Mar 17, 2026 at 11:22?AM Miguel Molinos wrote: > Hi Matt and Mark, > > Thank you for the feedback. > > A disadvantage is that you have to work harder to get structured variable > access, which DMDA has > automatically. Depending on your discretization on this grid, this can be > restored, but it is some work. > > > I?ve been trying to avoid DMPlex because I find harder to create ghost > particles (define padding regions) using an unstructured mesh. > Oh, you can make DMPlex be geometrically structured very easily. So this should not be a problem. > Regarding variable access, this is not a limitation since I use the > background mesh for domain decomposition purposes. The particles carry al > the information. > > What does the algorithm look like? > > > My code reproduces interaction between atoms (some sort of MD). The > purposes of the mesh are: > - Create a domain decomposition > - Particle migration > - Definition of boundary conditions (it can works like a supercell) > Oh, cool. DMPlex should be very easy then. You just create a BoxMesh (I ould probably do it from the command line), and then have it load balanced exactly as Mark said. I can help you if anything does not make sense. Thanks, Matt > Thanks, > Miguel > > On 17 Mar 2026, at 15:11, Matthew Knepley wrote: > > On Tue, Mar 17, 2026 at 8:53?AM Mark Adams wrote: > >> This tool works at the Mat level so it does not matter, but you need to >> work at the DM level anyway. >> >> I don't know of DM tools for this. Let Matt chime in. >> > > Hi Miguel, > > DMPlex can definitely do point location and load balancing, which is an > advantage. > > A disadvantage is that you have to work harder to get structured variable > access, which DMDA has > automatically. Depending on your discretization on this grid, this can be > restored, but it is some work. > > What does the algorithm look like? > > Thanks, > > Matt > > >> On Tue, Mar 17, 2026 at 7:54?AM Miguel Molinos wrote: >> >>> Thank you Mark. Indeed my question was oriented towards the tools PETSc >>> can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex >>> is more suited? >>> >>> Thanks, >>> Miguel >>> >>> On 17 Mar 2026, at 12:17, Mark Adams wrote: >>> >>> Hi Miguel, >>> >>> This is a common problem. To my knowledge you need to deal with it on >>> your side, but PETSc does have tools to help. >>> I would look in the literature to get ideas and acclimate yourself to >>> the problem. >>> >>> The tool that PETSc has is you can repartition your mesh. Create a dual >>> graph (any petsc examples?) put weights on the "vertice" (now elements, use >>> particle count) and repartition. >>> I am not sure of the best way to proceed from here ... you could create >>> a new DMSwarm with this new "cell" DM and add particles from the old to the >>> new, delete the old, call DMMigrate on the new DMSwarm and that will do the >>> moving that we want. >>> >>> Others will probably be able to add to this. >>> >>> Thanks, >>> Mark >>> >>> >>> On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos wrote: >>> >>>> >>>> Dear all, >>>> >>>> I am currently running a PIC-like implementation based on DMSwarm and >>>> DMDA. In my setup, a particle (DMSwarm) discretization represents, for >>>> example, a sphere placed at the center of a box-shaped domain discretized >>>> with a regular mesh (DMDA). >>>> >>>> The implementation uses both MPI and OpenMP to accelerate the >>>> computations. The domain decomposition of the sphere follows a PIC-like >>>> approach: each particle is assigned to a rank based on the mesh element it >>>> belongs to, and thus inherits the rank that ?owns? that element. This is >>>> essentially the same strategy used in one of the PETSc examples. >>>> >>>> However, I have observed that, for certain configurations, some ranks >>>> end up with very few or even no particles, which leads to load imbalance. >>>> >>>> Has anyone experienced a similar issue? >>>> >>>> Thanks, >>>> Miguel >>>> >>> >>> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fxCuWHIJfQQ5W0v9jYacL1OPdsqwr4qqwdne4wySjXMGM-MKEwlo8jFf1PUQEmKP9bG9bzY3RLxoCJOfEp5A$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fxCuWHIJfQQ5W0v9jYacL1OPdsqwr4qqwdne4wySjXMGM-MKEwlo8jFf1PUQEmKP9bG9bzY3RLxoCJOfEp5A$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Tue Mar 17 11:24:53 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Tue, 17 Mar 2026 17:24:53 +0100 Subject: [petsc-users] Load imbalance in DMSwarm & DMDA simulations In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: Awesome! I?ll give it a try this weekend :-). Thanks, Miguel > On 17 Mar 2026, at 16:47, Matthew Knepley wrote: > > On Tue, Mar 17, 2026 at 11:22?AM Miguel Molinos > wrote: >> Hi Matt and Mark, >> >> Thank you for the feedback. >> >>> A disadvantage is that you have to work harder to get structured variable access, which DMDA has >>> automatically. Depending on your discretization on this grid, this can be restored, but it is some work. >> >> I?ve been trying to avoid DMPlex because I find harder to create ghost particles (define padding regions) using an unstructured mesh. > > Oh, you can make DMPlex be geometrically structured very easily. So this should not be a problem. > >> Regarding variable access, this is not a limitation since I use the background mesh for domain decomposition purposes. The particles carry al the information. >> >>> What does the algorithm look like? >> >> >> My code reproduces interaction between atoms (some sort of MD). The purposes of the mesh are: >> - Create a domain decomposition >> - Particle migration >> - Definition of boundary conditions (it can works like a supercell) > > Oh, cool. DMPlex should be very easy then. You just create a BoxMesh (I ould probably do it from the command line), and then have it load balanced exactly as Mark said. I can help you if anything does not make sense. > > Thanks, > > Matt > > >> Thanks, >> Miguel >> >>> On 17 Mar 2026, at 15:11, Matthew Knepley > wrote: >>> >>> On Tue, Mar 17, 2026 at 8:53?AM Mark Adams > wrote: >>>> This tool works at the Mat level so it does not matter, but you need to work at the DM level anyway. >>>> >>>> I don't know of DM tools for this. Let Matt chime in. >>> >>> Hi Miguel, >>> >>> DMPlex can definitely do point location and load balancing, which is an advantage. >>> >>> A disadvantage is that you have to work harder to get structured variable access, which DMDA has >>> automatically. Depending on your discretization on this grid, this can be restored, but it is some work. >>> >>> What does the algorithm look like? >>> >>> Thanks, >>> >>> Matt >>> >>>> On Tue, Mar 17, 2026 at 7:54?AM Miguel Molinos > wrote: >>>>> Thank you Mark. Indeed my question was oriented towards the tools PETSc can offer to address this problem. Currently I?m using DMDA, perhaps DMPlex is more suited? >>>>> >>>>> Thanks, >>>>> Miguel >>>>> >>>>>> On 17 Mar 2026, at 12:17, Mark Adams > wrote: >>>>>> >>>>>> Hi Miguel, >>>>>> >>>>>> This is a common problem. To my knowledge you need to deal with it on your side, but PETSc does have tools to help. >>>>>> I would look in the literature to get ideas and acclimate yourself to the problem. >>>>>> >>>>>> The tool that PETSc has is you can repartition your mesh. Create a dual graph (any petsc examples?) put weights on the "vertice" (now elements, use particle count) and repartition. >>>>>> I am not sure of the best way to proceed from here ... you could create a new DMSwarm with this new "cell" DM and add particles from the old to the new, delete the old, call DMMigrate on the new DMSwarm and that will do the moving that we want. >>>>>> >>>>>> Others will probably be able to add to this. >>>>>> >>>>>> Thanks, >>>>>> Mark >>>>>> >>>>>> >>>>>> On Tue, Mar 17, 2026 at 4:49?AM Miguel Molinos > wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I am currently running a PIC-like implementation based on DMSwarm and DMDA. In my setup, a particle (DMSwarm) discretization represents, for example, a sphere placed at the center of a box-shaped domain discretized with a regular mesh (DMDA). >>>>>>> >>>>>>> The implementation uses both MPI and OpenMP to accelerate the computations. The domain decomposition of the sphere follows a PIC-like approach: each particle is assigned to a rank based on the mesh element it belongs to, and thus inherits the rank that ?owns? that element. This is essentially the same strategy used in one of the PETSc examples. >>>>>>> >>>>>>> However, I have observed that, for certain configurations, some ranks end up with very few or even no particles, which leads to load imbalance. >>>>>>> >>>>>>> Has anyone experienced a similar issue? >>>>>>> >>>>>>> Thanks, >>>>>>> Miguel >>>>>>> >>>>> >>> >>> >>> >>> -- >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dC7wBPb3AlS1zbuJFuRU9iCnTvSWPgp1QWZ_lq7VsB0H4vskBrEu6on00ztQVRArQJQVhZ0cYPo5Dvo6II03PELe$ > > > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dC7wBPb3AlS1zbuJFuRU9iCnTvSWPgp1QWZ_lq7VsB0H4vskBrEu6on00ztQVRArQJQVhZ0cYPo5Dvo6II03PELe$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Tue Mar 17 11:50:12 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Tue, 17 Mar 2026 16:50:12 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: That was the claim indeed. And it held for a while. Eventually figured out the reason for the differences and, not unexpectedly, the error was on my side. There was an additional operation on the small matrix that I consistently missed every single time I tested. Values set with MatSetClosure / MatSetValues / etc are the expected ones, and from MatView they are also correct, just rounded for visualization/printing. Thanks. On Sunday, March 15th, 2026 at 11:04 PM, Matthew Knepley wrote: > On Sun, Mar 15, 2026 at 5:24?PM Noam T. wrote: > >>> This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. >> >> This is indeed the case. >> >>> To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. >> >> I imagined this was simply a printing artifact. However, something is bugging me: the message from finite differences jacobian. >> >> The printed jacobian from finite differences is exactly the computed one (see below). If the differences from MatView were simply from printing, the error between finite difference and "in-code" should be (much closer to) zero, not 1e-5. >> >> So I did a couple more checks, avoiding calls to "XView" type of functions, and getting a single value directly: >> >> (For comparison) Computed matrix in the jacobian function (used to assemble) >> ---- >> 0.531360000000 0.066670000000 0.197333333327 >> 0.066670000000 0.535360000000 -0.003333333327 >> 0.197333333327 -0.003333333327 0.527413333333 >> ---- >> >> ** Calling "MatGetValues" and then printing them all: >> >> 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 >> 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 >> 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 > > So the claim is that you have some small matrix (the first) and you call MatSetValues() to put it in a big matrix, and you get different values in the big matrix? I am confident that this is impossible. So, in order to verify this, it should be easy to > > 1) Run in the debugger > > 2) Stop in MatSetValues() > > 3) Print out the input array v[] (you should get the first matrix in full precision) > > 4) You could tace down to where each value is entered, but it might be easier to > > 5) Call https://urldefense.us/v3/__https://petsc.org/main/manualpages/Mat/MatSeqAIJGetArray/__;!!G_uCfscf7eWS!aXSiC0ZBQh6RhRlIcJvFp6VmHB_7WBNFmlvzKWJ3T17gc57mGjdy7_EzYhgQEBKGnDaA5xeOXb-jQJXkF4ojUkqPVbrrFw--$ and look directly at the array right after the call > to MatSetValues() > > Thanks, > > Matt > >> These are the same values shown as when calling MatView. >> They are all quite off. There is for example a difference of 5e-4 for entry (0,0). >> Just in case I messed up the precision, the closest single-precision value for entry (0,0) is 0x1.100e6p-1 = 0.53135997... >> >> ** 2-norm of the assembled matrix times a vector [1,1,1] >> 1.2294717692646715 >> >> This is _exactly_ the norm using the matrix from MatView (i.e. the one from MatGetValues) times [1,1,1]. >> >> The original/assembled matrix times [1,1,1] should be >> 1.229421704786441 -- difference of 5e-5 >> >> Am I accessing stored/assembled values the wrong way so that they all are always off when printed? Or am I missing something else? >> >> Thanks >> >> On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley wrote: >> >>> On Sun, Mar 15, 2026 at 12:58?PM Noam T. wrote: >>> >>>> The results above of the SNES output were using the flags >>>> >>>> -ksp_type fgmres -pc_type lu >>> >>> This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. >>> >>> To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. >>> >>> Thanks, >>> >>> Matt >>> >>>> Thanks >>>> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley wrote: >>>> >>>>> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users wrote: >>>>> >>>>>> A bit more information: >>>>>> >>>>>> Looking at the solution of the system of equations, knowing the exact RHS vector: >>>>>> --- >>>>>> [-0.00197, 0.00203, -0.00197] >>>>>> --- >>>>>> >>>>>> SNES gives the solution: >>>>>> --- >>>>>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>>>>> --- >>>>>> >>>>>> which is indeed (closer to) the solution for the jacobian shown in MatView (the "lower precision" one). The "exact" solution would be: >>>>>> --- >>>>>> >>>>>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>>>>> --- >>>>>> >>>>>> which is already different form the second decimal digit. >>>>> >>>>> Are you using an exact solution method, like LU? >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>>> *** >>>>>> Requesting a low precision to have SNES do a few iterations, shows that the built jacobian seems to deviate more and more form the computed one after some iterations, e.g.: >>>>>> >>>>>> Computed (printed from in-code): >>>>>> --- >>>>>> 0.536488494840 0.066474939660 0.198813816284 >>>>>> 0.066474939660 0.529482312614 -0.002835445071 >>>>>> 0.198813816284 -0.002835445071 0.530589055263 >>>>>> --- >>>>>> >>>>>> MatView: >>>>>> --- >>>>>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>>>>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>>>>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) --- >>>>>> >>>>>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>>>>> >>>>>> Thank you. >>>>>> Noam >>>>>> >>>>>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. >>>>>>> >>>>>>> In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: >>>>>>> >>>>>>> ---- >>>>>>> 0.531360000000 0.066670000000 0.197333333327 >>>>>>> 0.066670000000 0.535360000000 -0.003333333327 >>>>>>> 0.197333333327 -0.003333333327 0.527413333333 >>>>>>> ---- >>>>>>> >>>>>>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). >>>>>>> >>>>>>> This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: >>>>>>> >>>>>>> ---- >>>>>>> >>>>>>> Mat Object: 1 MPI process >>>>>>> type: seqaij >>>>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- >>>>>>> >>>>>>> Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. >>>>>>> >>>>>>> Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): >>>>>>> >>>>>>> ---- >>>>>>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>>>>>> Hand-coded Jacobian ---------- >>>>>>> Mat Object: 1 MPI process >>>>>>> type: seqaij >>>>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>>>>> Finite difference Jacobian ---------- >>>>>>> Mat Object: 1 MPI process >>>>>>> type: seqaij >>>>>>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>>>>>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>>>>>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>>>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>>>>>> Mat Object: 1 MPI process >>>>>>> type: seqaij >>>>>>> row 0: (0, 2.66554e-05) >>>>>>> row 1: (1, 2.66554e-05) >>>>>>> row 2: (2, 2.6558e-05) ---- >>>>>>> >>>>>>> The main code is in Fortran, using double precision variables, in case it is relevant. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Noam >>>>> >>>>> -- >>>>> >>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!aXSiC0ZBQh6RhRlIcJvFp6VmHB_7WBNFmlvzKWJ3T17gc57mGjdy7_EzYhgQEBKGnDaA5xeOXb-jQJXkF4ojUkqPVcTcJ7Tb$ >>> >>> -- >>> >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!aXSiC0ZBQh6RhRlIcJvFp6VmHB_7WBNFmlvzKWJ3T17gc57mGjdy7_EzYhgQEBKGnDaA5xeOXb-jQJXkF4ojUkqPVcTcJ7Tb$ > > -- > > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*(http:/*www.cse.buffalo.edu/*knepley/)__;fl0vfg!!G_uCfscf7eWS!aXSiC0ZBQh6RhRlIcJvFp6VmHB_7WBNFmlvzKWJ3T17gc57mGjdy7_EzYhgQEBKGnDaA5xeOXb-jQJXkF4ojUkqPVcTcJ7Tb$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Tue Mar 17 11:54:24 2026 From: knepley at gmail.com (Matthew Knepley) Date: Tue, 17 Mar 2026 12:54:24 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Tue, Mar 17, 2026 at 12:50?PM Noam T. wrote: > That was the claim indeed. And it held for a while. Eventually figured out > the reason for the differences and, not unexpectedly, the error was on my > side. There was an additional operation on the small matrix that I > consistently missed every single time I tested. > > Values set with MatSetClosure / MatSetValues / etc are the expected ones, > and from MatView they are also correct, just rounded for > visualization/printing. > Cool. Do you think there is diagnostic output I could give that would make looking into the process easier? If you are using the Plex assembly, I have -dm_plex_print_fem 5 to print out all the element vec/mats and local assembly. There is also -petscds_print_integrate 5 for lower level integration output. Let me know and I can add something. Thanks, Matt > Thanks. > > On Sunday, March 15th, 2026 at 11:04 PM, Matthew Knepley < > knepley at gmail.com> wrote: > > On Sun, Mar 15, 2026 at 5:24?PM Noam T. wrote: > >> This is very easy to check. Multiply the solution by your matrix and >> subtract the RHS. It must satisfy the tolerance you have for the solver. If >> not, there is some other problem, but I imagine it does, which is what we >> mean by the solution. >> >> >> This is indeed the case. >> >> >> To answer the first question, there is no reduction in precision in >> MatSetValues(). I am sure if you carry out the addition by hand you will >> see that the result is within 1ulp as it should be from the standard. >> >> >> I imagined this was simply a printing artifact. However, something is >> bugging me: the message from finite differences jacobian. >> >> The printed jacobian from finite differences is exactly the computed one >> (see below). If the differences from MatView were simply from printing, the >> error between finite difference and "in-code" should be (much closer to) >> zero, not 1e-5. >> >> So I did a couple more checks, avoiding calls to "XView" type of >> functions, and getting a single value directly: >> >> (For comparison) Computed matrix in the jacobian function (used to >> assemble) >> ---- >> 0.531360000000 0.066670000000 0.197333333327 >> 0.066670000000 0.535360000000 -0.003333333327 >> 0.197333333327 -0.003333333327 0.527413333333 >> ---- >> >> ** Calling "MatGetValues" and then printing them all: >> >> 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 >> 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 >> 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 >> > > So the claim is that you have some small matrix (the first) and you call > MatSetValues() to put it in a big matrix, and you get different values in > the big matrix? I am confident that this is impossible. So, in order to > verify this, it should be easy to > > 1) Run in the debugger > > 2) Stop in MatSetValues() > > 3) Print out the input array v[] (you should get the first matrix in full > precision) > > 4) You could tace down to where each value is entered, but it might be > easier to > > 5) Call https://urldefense.us/v3/__https://petsc.org/main/manualpages/Mat/MatSeqAIJGetArray/__;!!G_uCfscf7eWS!ecH8MVZGPPyWCLBwVWOE1kIET70KehuSuvpgwWWHXgtCx2q0ct8VJ5ErEr5YKL78tvU0Fs5KIoC-_H-0ue1e$ and > look directly at the array right after the call > to MatSetValues() > > Thanks, > > Matt > >> These are the same values shown as when calling MatView. >> They are all quite off. There is for example a difference of 5e-4 for >> entry (0,0). >> Just in case I messed up the precision, the closest single-precision >> value for entry (0,0) is 0x1.100e6p-1 = 0.53135997... >> >> ** 2-norm of the assembled matrix times a vector [1,1,1] >> 1.2294717692646715 >> >> This is _exactly_ the norm using the matrix from MatView (i.e. the one >> from MatGetValues) times [1,1,1]. >> >> The original/assembled matrix times [1,1,1] should be >> 1.229421704786441 -- difference of 5e-5 >> >> Am I accessing stored/assembled values the wrong way so that they all are >> always off when printed? Or am I missing something else? >> >> Thanks >> >> >> On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley < >> knepley at gmail.com> wrote: >> >> On Sun, Mar 15, 2026 at 12:58?PM Noam T. >> wrote: >> >>> The results above of the SNES output were using the flags >>> >>> -ksp_type fgmres -pc_type lu >>> >> >> This is very easy to check. Multiply the solution by your matrix and >> subtract the RHS. It must satisfy the tolerance you have for the solver. If >> not, there is some other problem, but I imagine it does, which is what we >> mean by the solution. >> >> To answer the first question, there is no reduction in precision in >> MatSetValues(). I am sure if you carry out the addition by hand you will >> see that the result is within 1ulp as it should be from the standard. >> >> Thanks, >> >> Matt >> >>> Thanks >>> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley < >>> knepley at gmail.com> wrote: >>> >>> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users < >>> petsc-users at mcs.anl.gov> wrote: >>> >>>> A bit more information: >>>> >>>> Looking at the solution of the system of equations, knowing the exact >>>> RHS vector: >>>> --- >>>> [-0.00197, 0.00203, -0.00197] >>>> --- >>>> >>>> SNES gives the solution: >>>> --- >>>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>>> --- >>>> >>>> which is indeed (closer to) the solution for the jacobian shown in >>>> MatView (the "lower precision" one). The "exact" solution would be: >>>> --- >>>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>>> --- >>>> >>>> which is already different form the second decimal digit. >>>> >>> >>> Are you using an exact solution method, like LU? >>> >>> Thanks, >>> >>> Matt >>> >>>> >>>> *** >>>> Requesting a low precision to have SNES do a few iterations, shows that >>>> the built jacobian seems to deviate more and more form the computed one >>>> after some iterations, e.g.: >>>> >>>> Computed (printed from in-code): >>>> --- >>>> 0.536488494840 0.066474939660 0.198813816284 >>>> 0.066474939660 0.529482312614 -0.002835445071 >>>> 0.198813816284 -0.002835445071 0.530589055263 >>>> --- >>>> >>>> MatView: >>>> --- >>>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) >>>> --- >>>> >>>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>>> >>>> Thank you. >>>> Noam >>>> >>>> >>>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. < >>>> dontbugthedevs at proton.me> wrote: >>>> >>>> Hello, >>>> >>>> Looking at the assembly of the Jacobian using MatView, I noticed values >>>> were somewhat different from the computed ones in the jacobian function >>>> (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 >>>> quadrature points, so the exact Jacobian matrix can be computed >>>> analytically. >>>> >>>> In the jacobian function, after looping through all quadrature points, >>>> printing the matrix to stdout shows: >>>> >>>> ---- >>>> 0.531360000000 0.066670000000 0.197333333327 >>>> 0.066670000000 0.535360000000 -0.003333333327 >>>> 0.197333333327 -0.003333333327 0.527413333333 >>>> ---- >>>> >>>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly >>>> four/five nonzero digits, as shown above. The rest of the elements have a >>>> periodic 3 ending (a couple of digits at the end are off, but that's fine). >>>> >>>> This same matrix is the one added to the global jacobian during the >>>> quadrature loop, with "DMPlexMatSetClosure". After looping, calling >>>> "MatAssemblyBegin/End", then MatView: >>>> >>>> ---- >>>> Mat Object: 1 MPI process >>>> type: seqaij >>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>> ---- >>>> >>>> Values are close, but definitely not the same as computed. Are these >>>> values from "MatView" the ones actually stored in the matrix? It seems >>>> there is some precision loss in the process. >>>> >>>> Interestingly, computing the jacobian through finite differences, shows >>>> the same result for the "hand-coded" jacobian, whereas the finite >>>> differences ones is the "exact" one (same as first one above): >>>> >>>> ---- >>>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>>> Hand-coded Jacobian ---------- >>>> Mat Object: 1 MPI process >>>> type: seqaij >>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>> Finite difference Jacobian ---------- >>>> Mat Object: 1 MPI process >>>> type: seqaij >>>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 >>>> ---------- >>>> Mat Object: 1 MPI process >>>> type: seqaij >>>> row 0: (0, 2.66554e-05) >>>> row 1: (1, 2.66554e-05) >>>> row 2: (2, 2.6558e-05) >>>> ---- >>>> >>>> The main code is in Fortran, using double precision variables, in case >>>> it is relevant. >>>> >>>> Thank you. >>>> >>>> Noam >>>> >>>> >>>> >>>> >>> >>> -- >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ecH8MVZGPPyWCLBwVWOE1kIET70KehuSuvpgwWWHXgtCx2q0ct8VJ5ErEr5YKL78tvU0Fs5KIoC-_PFIFdfe$ >>> >>> >>> >>> >> >> -- >> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ecH8MVZGPPyWCLBwVWOE1kIET70KehuSuvpgwWWHXgtCx2q0ct8VJ5ErEr5YKL78tvU0Fs5KIoC-_PFIFdfe$ >> >> >> >> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ecH8MVZGPPyWCLBwVWOE1kIET70KehuSuvpgwWWHXgtCx2q0ct8VJ5ErEr5YKL78tvU0Fs5KIoC-_PFIFdfe$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ecH8MVZGPPyWCLBwVWOE1kIET70KehuSuvpgwWWHXgtCx2q0ct8VJ5ErEr5YKL78tvU0Fs5KIoC-_PFIFdfe$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldo.bonfiglioli at unibas.it Fri Mar 20 14:09:32 2026 From: aldo.bonfiglioli at unibas.it (Aldo Bonfiglioli) Date: Fri, 20 Mar 2026 20:09:32 +0100 Subject: [petsc-users] Question regarding Message-ID: <994045ea-77d1-4384-aea1-565432208084@unibas.it> Hi there, I am (successfully) using the following piece of code to insert elemental matrices into the "global" matrix "jac": > ! > if( matrix_assembly )then > ! > i = 0 > PetscCall(DMPlexGetTransitiveClosure(dm, cell, useCone, > PETSC_NULL_INTEGER, p_points, ierr)) > ! > ! ????loop over the vertices of the cell > ! > do j = vtxbgn, vtxend, 2 ?! this is ndim-dependent > ??????????????i = i + 1 > ??????????????point = p_points(j) > PetscCall(PetscSectionGetDof(section, point, ndofs, ierr)) > ??????????????PetscCall(PetscSectionGetOffset(section, point, offset, > ierr)) > ??????????????row(i) = offset/ndofs > ??????????????col(i) = offset/ndofs > ???????????end do > ! > do i = 1, nofvert > do j = 1, nofvert > dummy = transpose(eltmat(:, :, i, j)) > ir = row(i) > ic = col(j) > ! > !p_dummyisa1dviewofdummy > ! > PetscCall(MatSetValuesBlockedLocal(jac, 2, [ir], 1, [ic], p_dummy, > ADD_VALUES, ierr)) > end do > end do > ! > PetscCall(DMPlexRestoreTransitiveClosure(dm, cell, useCone, > PETSC_NULL_INTEGER, p_points, ierr)) > ! > end if ! matrix_assembly > I would however be happy to replace all of the above with a single call to: > PetscCall(DMPlexMatSetClosure(dm, PETSC_NULL_SECTION, > PETSC_NULL_SECTION, jac, cell, values, ADD_VALUES, ierr )) which I actually succeeded to do as long as ndofs = 1. The question is: how (in which order) should I "transfer" the entries of eltmat(1:ndofs,1:ndofs,1:nofvert,1:nofvert) into the values array required by DMPlexMatSetClosure ? Thanks, Aldo -- Dr. Aldo Bonfiglioli Associate professor of Fluid Mechanics Dipartimento di Ingegneria Universita' della Basilicata V.le dell'Ateneo Lucano, 10 85100 Potenza ITALY tel:+39.0971.205203 fax:+39.0971.205215 web:https://urldefense.us/v3/__http://docenti.unibas.it/site/home/docente.html?m=002423__;!!G_uCfscf7eWS!ZusjOf_nCidORTOchtNsX_xGJZNjiAXMKKmn4rDhnR-3Y6mFzMF9Z7f7iJFeGj6tgcBzT2L5gtfxO56AMvPr3pgXHaCPziR-QL4$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Fri Mar 20 15:36:12 2026 From: knepley at gmail.com (Matthew Knepley) Date: Fri, 20 Mar 2026 16:36:12 -0400 Subject: [petsc-users] Question regarding In-Reply-To: <994045ea-77d1-4384-aea1-565432208084@unibas.it> References: <994045ea-77d1-4384-aea1-565432208084@unibas.it> Message-ID: On Fri, Mar 20, 2026 at 3:09?PM Aldo Bonfiglioli wrote: > Hi there, > > I am (successfully) using the following piece of code to insert elemental > matrices into the "global" matrix "jac": > > ! > if( matrix_assembly )then > ! > i = 0 > PetscCall(DMPlexGetTransitiveClosure(dm, cell, useCone, > PETSC_NULL_INTEGER, p_points, ierr)) > ! > ! loop over the vertices of the cell > ! > do j = vtxbgn, vtxend, 2 ! this is ndim-dependent > i = i + 1 > point = p_points(j) > PetscCall(PetscSectionGetDof(section, point, ndofs, ierr)) > PetscCall(PetscSectionGetOffset(section, point, offset, > ierr)) > row(i) = offset/ndofs > col(i) = offset/ndofs > end do > ! > do i = 1, nofvert > do j = 1, nofvert > dummy = transpose(eltmat(:, :, i, j)) > ir = row(i) > ic = col(j) > ! > ! p_dummy is a 1d view of dummy > ! > PetscCall(MatSetValuesBlockedLocal(jac, 2, [ir], 1, > [ic], p_dummy, ADD_VALUES, ierr)) > end do > end do > ! > PetscCall(DMPlexRestoreTransitiveClosure(dm, cell, useCone, > PETSC_NULL_INTEGER, p_points, ierr)) > ! > end if ! matrix_assembly > > I would however be happy to replace all of the above with a single call to: > > PetscCall(DMPlexMatSetClosure(dm, PETSC_NULL_SECTION, PETSC_NULL_SECTION, > jac, cell, values, ADD_VALUES, ierr )) > > which I actually succeeded to do as long as ndofs = 1. > > The question is: > > how (in which order) should I "transfer" the entries of > eltmat(1:ndofs,1:ndofs,1:nofvert,1:nofvert) into the values array required > by DMPlexMatSetClosure ? > > For a given field, the dofs on the closure are ordered first by mesh point, and then by field component. So all field components are contiguous on a mesh point. So in your example, the dof order would be I = {v0,c0 v0,c1 ... v0,cN v1,c0 ,,, v1,cN ... vk,c0 ... vk,cN} The matrix "values" is in row-major order, meaning that all column values for the first row are given, and then the next row begins. Does that make sense? Matt > Thanks, > > Aldo > > -- > Dr. Aldo Bonfiglioli > Associate professor of Fluid Mechanics > Dipartimento di Ingegneria > Universita' della Basilicata > V.le dell'Ateneo Lucano, 10 85100 Potenza ITALY > tel:+39.0971.205203 fax:+39.0971.205215 > web: https://urldefense.us/v3/__http://docenti.unibas.it/site/home/docente.html?m=002423__;!!G_uCfscf7eWS!aau-IpT4Lq8cW7t_107COba4WHFpEfDnaq7pja4oDx-G4HY6csFSX8xjXHW4TLmAjFh6g9ucgfMj1MCZfTgg$ > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aau-IpT4Lq8cW7t_107COba4WHFpEfDnaq7pja4oDx-G4HY6csFSX8xjXHW4TLmAjFh6g9ucgfMj1JExicVp$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.noel at inria.fr Sat Mar 21 05:01:40 2026 From: matthieu.noel at inria.fr (Matthieu Noel) Date: Sat, 21 Mar 2026 11:01:40 +0100 Subject: [petsc-users] Request for Assistance with Parallel Matrix Solving Using petsc4py in EasyFEA In-Reply-To: References: Message-ID: <577dd294-4b6a-4bd0-b0a4-5059a04e5268@inria.fr> Sorry for my late response. I found out how to solve the issue. I had to reorder the DOF ordering to ensure the matrix system is continuous: https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/blob/dev/EasyFEA/Simulations/Solvers.py*L523-L618__;Iw!!G_uCfscf7eWS!ZRIBid8MQtxlDGuOHlzwyX677gChgXqdcePniPOa8Samn9v3Sv_ru-0neC8JQXK74zKh9uO9IqyyE9LzQGl-haOxRB1bLFY$ Best regards, Matthieu Noel Le 11/03/2026 ? 21:56, Barry Smith a ?crit?: > > ? ?Does it compute the ?correct? result with one MPI process? > >> On Mar 10, 2026, at 4:29?AM, Matthieu Noel >> wrote: >> >> Dear PETSc users, >> >> My name is Matthieu Noel, and I am a research software engineer at INRIA. >> >> During my PhD thesis, I developed *EasyFEA*, an open-source finite >> element analysis tool documented here: >> https://urldefense.us/v3/__https://easyfea.readthedocs.io/en/stable/__;!!G_uCfscf7eWS!ZRIBid8MQtxlDGuOHlzwyX677gChgXqdcePniPOa8Samn9v3Sv_ru-0neC8JQXK74zKh9uO9IqyyE9LzQGl-haOxE6AgvRk$ . >> >> I am currently working on *Issue #26* >> (https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/issues/26__;!!G_uCfscf7eWS!ZRIBid8MQtxlDGuOHlzwyX677gChgXqdcePniPOa8Samn9v3Sv_ru-0neC8JQXK74zKh9uO9IqyyE9LzQGl-haOxEX807cA$ ), where I aim to use >> *petsc4py* to solve a simple stationary thermal problem in parallel. >> >> The main challenge is *constructing and solving the parallel matrix >> system* (|Ax = b|). >> >> >> Current Status: >> >> * *Mesh partitioning* has been successfully performed using *GMSH*. >> * EasyFEA provides the *assembled matrix system* (|Ax = b|) with >> applied boundary conditions. >> * My current implementation using *petsc4py* runs without errors, >> but the results obtained are incorrect. >> >> >> I suspect the problem lies in how the *parallel matrix and vectors >> are assembled or solved*, particularly in handling *ghost DOFs* and >> ensuring proper communication between MPI ranks. >> >> I would be extremely grateful for any guidance, resources, or >> examples you could share to help me address this issue. >> My current development branch is available here: >> https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/tree/26_mpi__;!!G_uCfscf7eWS!ZRIBid8MQtxlDGuOHlzwyX677gChgXqdcePniPOa8Samn9v3Sv_ru-0neC8JQXK74zKh9uO9IqyyE9LzQGl-haOxHLPPL0E$ . >> >> The PETSc function can be found at this link: >> https://urldefense.us/v3/__https://github.com/matnoel/EasyFEA/blob/26_mpi/EasyFEA/Simulations/Solvers.py*L649-L767__;Iw!!G_uCfscf7eWS!ZRIBid8MQtxlDGuOHlzwyX677gChgXqdcePniPOa8Samn9v3Sv_ru-0neC8JQXK74zKh9uO9IqyyE9LzQGl-haOxwl_Zt5w$ >> >> I am currently running the script in the attached files. >> >> >> Thank you in advance for your time and expertise. >> >> Best regards, >> Matthieu Noel >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenridao45 at gmail.com Mon Mar 23 01:21:12 2026 From: chenridao45 at gmail.com (=?UTF-8?B?6ZmI5pel5YiA?=) Date: Mon, 23 Mar 2026 14:21:12 +0800 Subject: [petsc-users] Issue: Building PLC from STL for DMPlexGenerate_Tetgen and Geometry-Aware workflows Message-ID: Dear PETSc Team, My name is Zhaoyang Chen, a senior undergraduate at Hunan University. I am working on a meshing workflow using DMPlex and am particularly interested in utilizing the geometry-aware features such as *DMPlexSnapToGeomModel()* and refinement snapping. My input data consists of *high-resolution STL triangulations*. I have encountered a major bottleneck at the very beginning of the pipeline: *constructing the Piecewise Linear Complex (PLC)* from the STL to be used by *DMPlexGenerate_Tetgen().* Since the downstream geometry-aware operations (like *DMPlexSnapToGeomModel()* ) rely on a valid underlying geometry representation, I need to resolve the PLC construction issue first. Specifically: 1. *STL to PLC Ingestion*: Is there a native or recommended pathway in PETSc to ingest an STL file and define it as the PLC for volume mesh generation? 2. *Compatibility with Snapping*: If the PLC is successfully built from an STL, can the resulting* DMPlex* still utilize *DMPlexSnapToGeomModel()*? Or is the "Geometry-Aware" snapping strictly reserved for analytical B-Rep models (e.g., via EGADS)? I am trying to understand if PETSc supports a workflow where a discrete surface (STL) acts as the "GeomModel" for both initial volumetric meshing and subsequent snapping/refinement. Any guidance on how to bridge STL data with the DMPlex geometry-aware pipeline would be greatly appreciated. Best regards, Zhaoyang Chen Hunan University -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucia.barandiaran at upc.edu Tue Mar 24 13:30:46 2026 From: lucia.barandiaran at upc.edu (Lucia Barandiaran) Date: Tue, 24 Mar 2026 19:30:46 +0100 Subject: [petsc-users] Problem with KSPGetPC within FieldSplit context Message-ID: <89fd0a84-8b6e-4243-b7b1-ef7ea647bbda@upc.edu> Dear PETSc community, We recently updated PETSc libraries and came across with a problem with FieldSplit preconditioning (our code is implemented in Fortran 90). In the older version, when calling?PCFieldSplitGetSubKSP?we declared the subksp array as KSP and it worked perfectly. However, now we must declare it as a Fortran pointer and allocate it before calling?PCFieldSplitGetSubKSP?otherwise the code won't compile... With the new modification, that part of the code is the following: ****Variable declarations ? ? ? PetscInt? ? ? ? ? ? ? ::? n_splits_retrieved ? ? ? IS? ? ? ? ? ? ? ? ? ? ::? IS_field(max_field) ? ? ? KSP, pointer :: subksp_array(:) ? ? ? PC? ? ? ? ? ? ? ? ? ? ::? subpc(max_field) ? ? ? INTEGER(iwp)? ? ? ? ? ::? nfield, ifield **** FieldSplit Part **** ? ?!? ? Allocate Fortran array to hold the KSP contexts ? ? ? ? ALLOCATE(subksp_array(n_splits_retrieved)) ? ?!? ? Second call to get the actual KSP contexts ? ? ? ? CALL PCFieldSplitGetSubKSP(solver%pc, n_splits_retrieved, & ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?subksp_array, ierr) ? ? ? ? IF (n_splits_retrieved >= 2) THEN ? ? ? ? ? DO ifield = 1, n_splits_retrieved ? ? ? ? ? ! Configure the KSP for the velocity block (field 0) ? ? ? ? ? ? CALL KSPGetPC(subksp_array(ifield), subpc(ifield), ierr) ? ? ? ? ? ? CALL KSPSetType(subksp_array(ifield), KSPGMRES, ierr) ? ? ? ? ? ? CALL PCSetType(subpc(ifield), PCJACOBI, ierr) ? ? ? ? ? ! Allows runtime options for sub-KSP ? ? ? ? ? ? CALL KSPSetFromOptions(subksp_array(ifield), ierr) ? ? ? ? ? ! Choose a viewer (stdout for example) !? ? ? ? ? ?viewer = PETSC_VIEWER_STDOUT_WORLD !? ? ? ? ? ?CALL PCView(subpc(ifield),viewer,ierr) ? ? ? ? ? END DO ? ? ? ? END IF When debugging the fortran code we observed that it stops with an error when calling KSPGetPC? and we can't figure out what are we doing wrong... Maybe we need an interface when calling that function? Thanks very much for your time, Sincerely, Luc?a Barandiar?n Scientific software developer? - Dracsys Collaborator at MECMAT group - Universitat Polit?cnica de Catalunya (UPC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Wed Mar 25 03:35:40 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Wed, 25 Mar 2026 08:35:40 +0000 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: I was not ware of those two flags (I should read the documentation more thoroughly); surely they would have been helpful. However, in the example from this discussion (single Q1 quadrilateral), those two flags do not show much information. -petscds_print_integrate N prints nothing, for any N value -dm_plex_print_fem N prints N = 1 nothing N = 2...5 --> Indices: -1 -2 0 1 2 -4 -4 -5 which I must say I cannot make much out of. The mesh I use is read with -dm_plex_filename; also using -dm_plex_interpolate 1, DMSetType(...,DMPLEX), and a few "gmsh" flags. Thanks On Tuesday, March 17th, 2026 at 4:54 PM, Matthew Knepley wrote: > On Tue, Mar 17, 2026 at 12:50?PM Noam T. wrote: > >> That was the claim indeed. And it held for a while. Eventually figured out the reason for the differences and, not unexpectedly, the error was on my side. There was an additional operation on the small matrix that I consistently missed every single time I tested. >> >> Values set with MatSetClosure / MatSetValues / etc are the expected ones, and from MatView they are also correct, just rounded for visualization/printing. > > Cool. Do you think there is diagnostic output I could give that would make looking into the process easier? If you are using the Plex assembly, I have > > -dm_plex_print_fem 5 > > to print out all the element vec/mats and local assembly. There is also > > -petscds_print_integrate 5 > > for lower level integration output. Let me know and I can add something. > > Thanks, > > Matt > >> Thanks. >> >> On Sunday, March 15th, 2026 at 11:04 PM, Matthew Knepley wrote: >> >>> On Sun, Mar 15, 2026 at 5:24?PM Noam T. wrote: >>> >>>>> This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. >>>> >>>> This is indeed the case. >>>> >>>>> To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. >>>> >>>> I imagined this was simply a printing artifact. However, something is bugging me: the message from finite differences jacobian. >>>> >>>> The printed jacobian from finite differences is exactly the computed one (see below). If the differences from MatView were simply from printing, the error between finite difference and "in-code" should be (much closer to) zero, not 1e-5. >>>> >>>> So I did a couple more checks, avoiding calls to "XView" type of functions, and getting a single value directly: >>>> >>>> (For comparison) Computed matrix in the jacobian function (used to assemble) >>>> ---- >>>> 0.531360000000 0.066670000000 0.197333333327 >>>> 0.066670000000 0.535360000000 -0.003333333327 >>>> 0.197333333327 -0.003333333327 0.527413333333 >>>> ---- >>>> >>>> ** Calling "MatGetValues" and then printing them all: >>>> >>>> 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 >>>> 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 >>>> 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 >>> >>> So the claim is that you have some small matrix (the first) and you call MatSetValues() to put it in a big matrix, and you get different values in the big matrix? I am confident that this is impossible. So, in order to verify this, it should be easy to >>> >>> 1) Run in the debugger >>> >>> 2) Stop in MatSetValues() >>> >>> 3) Print out the input array v[] (you should get the first matrix in full precision) >>> >>> 4) You could tace down to where each value is entered, but it might be easier to >>> >>> 5) Call https://urldefense.us/v3/__https://petsc.org/main/manualpages/Mat/MatSeqAIJGetArray/__;!!G_uCfscf7eWS!a3jb_9v8vNE4YjzEnb85ZoqueG86kGxBhCXLdX7zEtltm9VCBjNyx9eRwjN936aBfbaQQiYBu5noPL3PipvkE10JfHywpfwm$ and look directly at the array right after the call >>> to MatSetValues() >>> >>> Thanks, >>> >>> Matt >>> >>>> These are the same values shown as when calling MatView. >>>> They are all quite off. There is for example a difference of 5e-4 for entry (0,0). >>>> Just in case I messed up the precision, the closest single-precision value for entry (0,0) is 0x1.100e6p-1 = 0.53135997... >>>> >>>> ** 2-norm of the assembled matrix times a vector [1,1,1] >>>> 1.2294717692646715 >>>> >>>> This is _exactly_ the norm using the matrix from MatView (i.e. the one from MatGetValues) times [1,1,1]. >>>> >>>> The original/assembled matrix times [1,1,1] should be >>>> 1.229421704786441 -- difference of 5e-5 >>>> >>>> Am I accessing stored/assembled values the wrong way so that they all are always off when printed? Or am I missing something else? >>>> >>>> Thanks >>>> >>>> On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley wrote: >>>> >>>>> On Sun, Mar 15, 2026 at 12:58?PM Noam T. wrote: >>>>> >>>>>> The results above of the SNES output were using the flags >>>>>> >>>>>> -ksp_type fgmres -pc_type lu >>>>> >>>>> This is very easy to check. Multiply the solution by your matrix and subtract the RHS. It must satisfy the tolerance you have for the solver. If not, there is some other problem, but I imagine it does, which is what we mean by the solution. >>>>> >>>>> To answer the first question, there is no reduction in precision in MatSetValues(). I am sure if you carry out the addition by hand you will see that the result is within 1ulp as it should be from the standard. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>>> Thanks >>>>>> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley wrote: >>>>>> >>>>>>> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users wrote: >>>>>>> >>>>>>>> A bit more information: >>>>>>>> >>>>>>>> Looking at the solution of the system of equations, knowing the exact RHS vector: >>>>>>>> --- >>>>>>>> [-0.00197, 0.00203, -0.00197] >>>>>>>> --- >>>>>>>> >>>>>>>> SNES gives the solution: >>>>>>>> --- >>>>>>>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>>>>>>> --- >>>>>>>> >>>>>>>> which is indeed (closer to) the solution for the jacobian shown in MatView (the "lower precision" one). The "exact" solution would be: >>>>>>>> --- >>>>>>>> >>>>>>>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>>>>>>> --- >>>>>>>> >>>>>>>> which is already different form the second decimal digit. >>>>>>> >>>>>>> Are you using an exact solution method, like LU? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>>> *** >>>>>>>> Requesting a low precision to have SNES do a few iterations, shows that the built jacobian seems to deviate more and more form the computed one after some iterations, e.g.: >>>>>>>> >>>>>>>> Computed (printed from in-code): >>>>>>>> --- >>>>>>>> 0.536488494840 0.066474939660 0.198813816284 >>>>>>>> 0.066474939660 0.529482312614 -0.002835445071 >>>>>>>> 0.198813816284 -0.002835445071 0.530589055263 >>>>>>>> --- >>>>>>>> >>>>>>>> MatView: >>>>>>>> --- >>>>>>>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>>>>>>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>>>>>>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) --- >>>>>>>> >>>>>>>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> Noam >>>>>>>> >>>>>>>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Looking at the assembly of the Jacobian using MatView, I noticed values were somewhat different from the computed ones in the jacobian function (DMSNESSetJacobian). For the test, I used a single Q1 element, with 4 quadrature points, so the exact Jacobian matrix can be computed analytically. >>>>>>>>> >>>>>>>>> In the jacobian function, after looping through all quadrature points, printing the matrix to stdout shows: >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> 0.531360000000 0.066670000000 0.197333333327 >>>>>>>>> 0.066670000000 0.535360000000 -0.003333333327 >>>>>>>>> 0.197333333327 -0.003333333327 0.527413333333 >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly four/five nonzero digits, as shown above. The rest of the elements have a periodic 3 ending (a couple of digits at the end are off, but that's fine). >>>>>>>>> >>>>>>>>> This same matrix is the one added to the global jacobian during the quadrature loop, with "DMPlexMatSetClosure". After looping, calling "MatAssemblyBegin/End", then MatView: >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> Mat Object: 1 MPI process >>>>>>>>> type: seqaij >>>>>>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>>>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>>>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) ---- >>>>>>>>> >>>>>>>>> Values are close, but definitely not the same as computed. Are these values from "MatView" the ones actually stored in the matrix? It seems there is some precision loss in the process. >>>>>>>>> >>>>>>>>> Interestingly, computing the jacobian through finite differences, shows the same result for the "hand-coded" jacobian, whereas the finite differences ones is the "exact" one (same as first one above): >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>>>>>>>> Hand-coded Jacobian ---------- >>>>>>>>> Mat Object: 1 MPI process >>>>>>>>> type: seqaij >>>>>>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>>>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>>>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>>>>>>> Finite difference Jacobian ---------- >>>>>>>>> Mat Object: 1 MPI process >>>>>>>>> type: seqaij >>>>>>>>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>>>>>>>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>>>>>>>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>>>>>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 ---------- >>>>>>>>> Mat Object: 1 MPI process >>>>>>>>> type: seqaij >>>>>>>>> row 0: (0, 2.66554e-05) >>>>>>>>> row 1: (1, 2.66554e-05) >>>>>>>>> row 2: (2, 2.6558e-05) ---- >>>>>>>>> >>>>>>>>> The main code is in Fortran, using double precision variables, in case it is relevant. >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> Noam >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*5D(http:/*www.cse.buffalo.edu/*knepley/)__;fiUvfg!!G_uCfscf7eWS!a3jb_9v8vNE4YjzEnb85ZoqueG86kGxBhCXLdX7zEtltm9VCBjNyx9eRwjN936aBfbaQQiYBu5noPL3PipvkE10JfDOBL8C5$ >>>>> >>>>> -- >>>>> >>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*5D(http:/*www.cse.buffalo.edu/*knepley/)__;fiUvfg!!G_uCfscf7eWS!a3jb_9v8vNE4YjzEnb85ZoqueG86kGxBhCXLdX7zEtltm9VCBjNyx9eRwjN936aBfbaQQiYBu5noPL3PipvkE10JfDOBL8C5$ >>> >>> -- >>> >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*5D(http:/*www.cse.buffalo.edu/*knepley/)__;fiUvfg!!G_uCfscf7eWS!a3jb_9v8vNE4YjzEnb85ZoqueG86kGxBhCXLdX7zEtltm9VCBjNyx9eRwjN936aBfbaQQiYBu5noPL3PipvkE10JfDOBL8C5$ > > -- > > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/*5D(http:/*www.cse.buffalo.edu/*knepley/)__;fiUvfg!!G_uCfscf7eWS!a3jb_9v8vNE4YjzEnb85ZoqueG86kGxBhCXLdX7zEtltm9VCBjNyx9eRwjN936aBfbaQQiYBu5noPL3PipvkE10JfDOBL8C5$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontbugthedevs at proton.me Wed Mar 25 03:50:58 2026 From: dontbugthedevs at proton.me (Noam T.) Date: Wed, 25 Mar 2026 08:50:58 +0000 Subject: [petsc-users] 20-node hexes Message-ID: Hello, Is it possible to build/use a mesh consisting of 20-node hexes in PETSc? I tried reading (-dm_plex_filename) an existing mesh, with a 20-node cube, from gmsh (using the option "SecondOrderIncomplete"); statistics show 20 nodes, however the "Entities" section still only contains 8 vertices, so that may not work here. Using -petscdualspace_lagrange_XYZ I could not achieve this either. I searched some old threads in the mailing list; there are a couple, but they don't specify how they build it; they just mention they are using such mesh. Searching for "serendipity" in the documentation did not return anything either. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Wed Mar 25 04:54:04 2026 From: knepley at gmail.com (Matthew Knepley) Date: Wed, 25 Mar 2026 05:54:04 -0400 Subject: [petsc-users] 20-node hexes In-Reply-To: References: Message-ID: On Wed, Mar 25, 2026 at 4:51?AM Noam T. via petsc-users < petsc-users at mcs.anl.gov> wrote: > Hello, > > Is it possible to build/use a mesh consisting of 20-node hexes in PETSc? > > I tried reading (-dm_plex_filename) an existing mesh, with a 20-node cube, > from gmsh (using the option "SecondOrderIncomplete"); statistics show 20 > nodes, however the "Entities" section still only contains 8 vertices, so > that may not work here. > > Using -petscdualspace_lagrange_XYZ I could not achieve this either. > > I searched some old threads in the mailing list; there are a couple, but > they don't specify how they build it; they just mention they are using such > mesh. > > Searching for "serendipity" in the documentation did not return anything > either. > No, PETSc cannot represent the serendipity space. You can create a PetscSection that has this data layout, so you can hold vectors with these solutions, do local to global, etc, but Plex cannot compute residuals. Firedrake has these elements. The argument for serendipity elements is that they save computation, but in doing so they give up opportunities for optimization (like vectorization) and they are slightly less accurate. I have never seen them win in time to solution. Thanks, Matt > Thanks, > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fmdgmR8_axS6DJ93AuPyevdHxx6X2NwEb7MsORSO5Mlpe9mhVBH8GcCK79-kHJODbwn83qenIi4-J6gg_GTQ$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Wed Mar 25 05:03:07 2026 From: knepley at gmail.com (Matthew Knepley) Date: Wed, 25 Mar 2026 06:03:07 -0400 Subject: [petsc-users] Different precision from MatAssembly/MatView In-Reply-To: References: Message-ID: On Wed, Mar 25, 2026 at 4:35?AM Noam T. wrote: > I was not ware of those two flags (I should read the documentation more > thoroughly); surely they would have been helpful. > > However, in the example from this discussion (single Q1 quadrilateral), > those two flags do not show much information. > Ah, then you are not using Plex to compute the residual, say with DMPlexSNESComputeResidual, so the integrate flag is never active (you do not use PetscFEIntegrateResidual). > -petscds_print_integrate N prints nothing, for any N value > > -dm_plex_print_fem N prints > > N = 1 nothing > N = 2...5 --> Indices: -1 -2 0 1 2 -4 -4 -5 > Here, MatSetClosure() is telling you what indices it expanded in the call to MatSetValues(). There were 8 indices, but 5 of them were constrained in the Section, so they are negative. Thanks, Matt > which I must say I cannot make much out of. > > The mesh I use is read with -dm_plex_filename; also using > -dm_plex_interpolate 1, DMSetType(...,DMPLEX), and a few "gmsh" flags. > > Thanks > > > On Tuesday, March 17th, 2026 at 4:54 PM, Matthew Knepley < > knepley at gmail.com> wrote: > > On Tue, Mar 17, 2026 at 12:50?PM Noam T. wrote: > >> That was the claim indeed. And it held for a while. Eventually figured >> out the reason for the differences and, not unexpectedly, the error was on >> my side. There was an additional operation on the small matrix that I >> consistently missed every single time I tested. >> >> Values set with MatSetClosure / MatSetValues / etc are the expected ones, >> and from MatView they are also correct, just rounded for >> visualization/printing. >> > > Cool. Do you think there is diagnostic output I could give that would make > looking into the process easier? If you are using the Plex assembly, I have > > -dm_plex_print_fem 5 > > to print out all the element vec/mats and local assembly. There is also > > -petscds_print_integrate 5 > > for lower level integration output. Let me know and I can add something. > > Thanks, > > Matt > >> Thanks. >> >> On Sunday, March 15th, 2026 at 11:04 PM, Matthew Knepley < >> knepley at gmail.com> wrote: >> >> On Sun, Mar 15, 2026 at 5:24?PM Noam T. wrote: >> >>> This is very easy to check. Multiply the solution by your matrix and >>> subtract the RHS. It must satisfy the tolerance you have for the solver. If >>> not, there is some other problem, but I imagine it does, which is what we >>> mean by the solution. >>> >>> >>> This is indeed the case. >>> >>> >>> To answer the first question, there is no reduction in precision in >>> MatSetValues(). I am sure if you carry out the addition by hand you will >>> see that the result is within 1ulp as it should be from the standard. >>> >>> >>> I imagined this was simply a printing artifact. However, something is >>> bugging me: the message from finite differences jacobian. >>> >>> The printed jacobian from finite differences is exactly the computed one >>> (see below). If the differences from MatView were simply from printing, the >>> error between finite difference and "in-code" should be (much closer to) >>> zero, not 1e-5. >>> >>> So I did a couple more checks, avoiding calls to "XView" type of >>> functions, and getting a single value directly: >>> >>> (For comparison) Computed matrix in the jacobian function (used to >>> assemble) >>> ---- >>> 0.531360000000 0.066670000000 0.197333333327 >>> 0.066670000000 0.535360000000 -0.003333333327 >>> 0.197333333327 -0.003333333327 0.527413333333 >>> ---- >>> >>> ** Calling "MatGetValues" and then printing them all: >>> >>> 5.313866666667E-01 6.667333333333E-02 1.973381999940E-01 >>> 6.667333333333E-02 5.353866666667E-01 -3.338499994017E-03 >>> 1.973381999940E-01 -3.338499994017E-03 5.274399026665E-01 >>> >> >> So the claim is that you have some small matrix (the first) and you call >> MatSetValues() to put it in a big matrix, and you get different values in >> the big matrix? I am confident that this is impossible. So, in order to >> verify this, it should be easy to >> >> 1) Run in the debugger >> >> 2) Stop in MatSetValues() >> >> 3) Print out the input array v[] (you should get the first matrix in full >> precision) >> >> 4) You could tace down to where each value is entered, but it might be >> easier to >> >> 5) Call https://urldefense.us/v3/__https://petsc.org/main/manualpages/Mat/MatSeqAIJGetArray/__;!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdCFA-uJK$ and >> look directly at the array right after the call >> to MatSetValues() >> >> Thanks, >> >> Matt >> >>> These are the same values shown as when calling MatView. >>> They are all quite off. There is for example a difference of 5e-4 for >>> entry (0,0). >>> Just in case I messed up the precision, the closest single-precision >>> value for entry (0,0) is 0x1.100e6p-1 = 0.53135997... >>> >>> ** 2-norm of the assembled matrix times a vector [1,1,1] >>> 1.2294717692646715 >>> >>> This is _exactly_ the norm using the matrix from MatView (i.e. the one >>> from MatGetValues) times [1,1,1]. >>> >>> The original/assembled matrix times [1,1,1] should be >>> 1.229421704786441 -- difference of 5e-5 >>> >>> Am I accessing stored/assembled values the wrong way so that they all >>> are always off when printed? Or am I missing something else? >>> >>> Thanks >>> >>> >>> On Sunday, March 15th, 2026 at 6:16 PM, Matthew Knepley < >>> knepley at gmail.com> wrote: >>> >>> On Sun, Mar 15, 2026 at 12:58?PM Noam T. >>> wrote: >>> >>>> The results above of the SNES output were using the flags >>>> >>>> -ksp_type fgmres -pc_type lu >>>> >>> >>> This is very easy to check. Multiply the solution by your matrix and >>> subtract the RHS. It must satisfy the tolerance you have for the solver. If >>> not, there is some other problem, but I imagine it does, which is what we >>> mean by the solution. >>> >>> To answer the first question, there is no reduction in precision in >>> MatSetValues(). I am sure if you carry out the addition by hand you will >>> see that the result is within 1ulp as it should be from the standard. >>> >>> Thanks, >>> >>> Matt >>> >>>> Thanks >>>> On Sunday, March 15th, 2026 at 5:12 PM, Matthew Knepley < >>>> knepley at gmail.com> wrote: >>>> >>>> On Sun, Mar 15, 2026 at 11:19?AM Noam T. via petsc-users < >>>> petsc-users at mcs.anl.gov> wrote: >>>> >>>>> A bit more information: >>>>> >>>>> Looking at the solution of the system of equations, knowing the exact >>>>> RHS vector: >>>>> --- >>>>> [-0.00197, 0.00203, -0.00197] >>>>> --- >>>>> >>>>> SNES gives the solution: >>>>> --- >>>>> 3.316262462871E-03, -4.189244774965E-03, 2.468317119413E-03 >>>>> --- >>>>> >>>>> which is indeed (closer to) the solution for the jacobian shown in >>>>> MatView (the "lower precision" one). The "exact" solution would be: >>>>> --- >>>>> 3.282607248309093b-3, -4.241572005990172b-3,, 2.425030835360701b-3 >>>>> --- >>>>> >>>>> which is already different form the second decimal digit. >>>>> >>>> >>>> Are you using an exact solution method, like LU? >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>>> >>>>> *** >>>>> Requesting a low precision to have SNES do a few iterations, shows >>>>> that the built jacobian seems to deviate more and more form the computed >>>>> one after some iterations, e.g.: >>>>> >>>>> Computed (printed from in-code): >>>>> --- >>>>> 0.536488494840 0.066474939660 0.198813816284 >>>>> 0.066474939660 0.529482312614 -0.002835445071 >>>>> 0.198813816284 -0.002835445071 0.530589055263 >>>>> --- >>>>> >>>>> MatView: >>>>> --- >>>>> row 0: (0, 0.538491) (1, 0.0662019) (2, 0.198808) >>>>> row 1: (0, 0.0662019) (1, 0.526981) (2, -0.00257554) >>>>> row 2: (0, 0.198808) (1, -0.00257554) (2, 0.529883) >>>>> --- >>>>> >>>>> Only one digit is correct/the same in entries [1,2], [2,1] and [2,2]. >>>>> >>>>> Thank you. >>>>> Noam >>>>> >>>>> >>>>> On Sunday, March 15th, 2026 at 3:29 PM, Noam T. < >>>>> dontbugthedevs at proton.me> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Looking at the assembly of the Jacobian using MatView, I noticed >>>>> values were somewhat different from the computed ones in the jacobian >>>>> function (DMSNESSetJacobian). For the test, I used a single Q1 element, >>>>> with 4 quadrature points, so the exact Jacobian matrix can be computed >>>>> analytically. >>>>> >>>>> In the jacobian function, after looping through all quadrature points, >>>>> printing the matrix to stdout shows: >>>>> >>>>> ---- >>>>> 0.531360000000 0.066670000000 0.197333333327 >>>>> 0.066670000000 0.535360000000 -0.003333333327 >>>>> 0.197333333327 -0.003333333327 0.527413333333 >>>>> ---- >>>>> >>>>> (showing only the 3 free DoFs). The 2x2 submatrix in [0:1] has exactly >>>>> four/five nonzero digits, as shown above. The rest of the elements have a >>>>> periodic 3 ending (a couple of digits at the end are off, but that's fine). >>>>> >>>>> This same matrix is the one added to the global jacobian during the >>>>> quadrature loop, with "DMPlexMatSetClosure". After looping, calling >>>>> "MatAssemblyBegin/End", then MatView: >>>>> >>>>> ---- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>>> ---- >>>>> >>>>> Values are close, but definitely not the same as computed. Are these >>>>> values from "MatView" the ones actually stored in the matrix? It seems >>>>> there is some precision loss in the process. >>>>> >>>>> Interestingly, computing the jacobian through finite differences, >>>>> shows the same result for the "hand-coded" jacobian, whereas the finite >>>>> differences ones is the "exact" one (same as first one above): >>>>> >>>>> ---- >>>>> ||J - Jfd||_F/||J||_F = 4.90736e-05, ||J - Jfd||_F = 4.74265e-05 >>>>> Hand-coded Jacobian ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.531387) (1, 0.0666733) (2, 0.197338) >>>>> row 1: (0, 0.0666733) (1, 0.535387) (2, -0.0033385) >>>>> row 2: (0, 0.197338) (1, -0.0033385) (2, 0.52744) >>>>> Finite difference Jacobian ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 0.53136) (1, 0.06667) (2, 0.197333) >>>>> row 1: (0, 0.06667) (1, 0.53536) (2, -0.00333333) >>>>> row 2: (0, 0.197333) (1, -0.00333333) (2, 0.527413) >>>>> Hand-coded minus finite-difference Jacobian with tolerance 1e-05 >>>>> ---------- >>>>> Mat Object: 1 MPI process >>>>> type: seqaij >>>>> row 0: (0, 2.66554e-05) >>>>> row 1: (1, 2.66554e-05) >>>>> row 2: (2, 2.6558e-05) >>>>> ---- >>>>> >>>>> The main code is in Fortran, using double precision variables, in case >>>>> it is relevant. >>>>> >>>>> Thank you. >>>>> >>>>> Noam >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdBg21gLV$ >>>> >>>> >>>> >>>> >>> >>> -- >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdBg21gLV$ >>> >>> >>> >>> >> >> -- >> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdBg21gLV$ >> >> >> >> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdBg21gLV$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!b2z23LNHOLo_xQtxCTVj6d1lgTRJZI9AkCNs-HnbBq9xRAkVMM8SoPmLIcAoDnGdhsY3KahbO0vXdBg21gLV$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo.denovellis at epfl.ch Fri Mar 27 09:10:48 2026 From: leonardo.denovellis at epfl.ch (Leonardo De Novellis) Date: Fri, 27 Mar 2026 14:10:48 +0000 Subject: [petsc-users] Questions on QR methods in PETSc Message-ID: Dear Users Support Team, I have a couple of questions regarding QR decompositions in PETSc. 1) I would like to find the least-squares solution of a rectangular system of the form Ax = b, where A is a dense and tall-skinny matrix (size around 1000000 x 10). Since A has very bad conditioning, I want to avoid iterative methods (such as KSPLSQR), since the number of iterations can get very large, and would like to use a direct QR solving method. Currently, I am running my code on only 1 core, and A is of type seqaij. With this setup, the following code works fine: call KSPSetType(ksp, KSPPREONLY, ierr) call KSPGetPC(ksp, pc, ierr) call PCSetType(pc, PCQR, ierr) call KSPSetOperators(ksp, A, A, ierr) t1 = MPI_Wtime() call KSPSolve(ksp, b, x, ierr) t2 = MPI_Wtime() I eventually want to run this in parallel on multiple cores. Will PCQR work for an mpiaij / mpidense matrix? If not, what would you suggest as a direct solving approach for this system? 2) I would also like to compute an explicit QR decomposition of A, and want to do so in parallel. Is there any way to do so in PETSc? If not, as a possible alternative, would you recommend using SLEPc BVOrthogonalize function? Kind regards, Leonardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jroman at dsic.upv.es Fri Mar 27 11:27:46 2026 From: jroman at dsic.upv.es (Jose E. Roman) Date: Fri, 27 Mar 2026 16:27:46 +0000 Subject: [petsc-users] Questions on QR methods in PETSc In-Reply-To: References: Message-ID: <4FB1C701-FB50-4ECC-8F0C-0CAD11E8092F@dsic.upv.es> > El 27 mar 2026, a las 15:10, Leonardo De Novellis via petsc-users escribi?: > > Dear Users Support Team, > I have a couple of questions regarding QR decompositions in PETSc. > > 1) I would like to find the least-squares solution of a rectangular system of the form Ax = b, where A is a dense and tall-skinny matrix (size around 1000000 x 10). > Since A has very bad conditioning, I want to avoid iterative methods (such as KSPLSQR), since the number of iterations can get very large, and would like to use a direct QR solving method. > Currently, I am running my code on only 1 core, and A is of type seqaij. With this setup, the following code works fine: > > call KSPSetType(ksp, KSPPREONLY, ierr) > call KSPGetPC(ksp, pc, ierr) > call PCSetType(pc, PCQR, ierr) > call KSPSetOperators(ksp, A, A, ierr) > t1 = MPI_Wtime() > call KSPSolve(ksp, b, x, ierr) > t2 = MPI_Wtime() > > I eventually want to run this in parallel on multiple cores. Will PCQR work for an mpiaij / mpidense matrix? If not, what would you suggest as a direct solving approach for this system? As an alternative, you can try PCSVD. If your matrix is ill-conditioned, I would trust SVD more than QR. Both PCQR and PCSVD are sequential, but PCSVD will work in parallel by creating a redundant dense matrix replicated in all processes, so that computation is still sequential. You can obtain a similar behaviour with PCREDUNDANT + PCQR. > > 2) I would also like to compute an explicit QR decomposition of A, and want to do so in parallel. Is there any way to do so in PETSc? If not, as a possible alternative, would you recommend using SLEPc BVOrthogonalize function? PETSc does not have parallel QR. In SLEPc BVOrthogonalize() will do the job. I would try the TSQR and SVQB methods, they should work for ill-conditioned matrices. With 1 MPI process TSQR should be equivalent to PCQR. You can also use the result of BVOrthogonalize() to compute the least-squares solution as x=R^{-1}*Q^T*b. Jose > > Kind regards, > Leonardo > > From knepley at gmail.com Fri Mar 27 13:24:55 2026 From: knepley at gmail.com (Matthew Knepley) Date: Fri, 27 Mar 2026 14:24:55 -0400 Subject: [petsc-users] Questions on QR methods in PETSc In-Reply-To: References: Message-ID: Hi Leonardo, On Fri, Mar 27, 2026 at 11:35?AM Leonardo De Novellis via petsc-users < petsc-users at mcs.anl.gov> wrote: > Dear Users Support Team, > I have a couple of questions regarding QR decompositions in PETSc. > > 1) I would like to find the least-squares solution of a rectangular system > of the form Ax = b, where A is a dense and tall-skinny matrix (size around > 1000000 x 10). > Since A has very bad conditioning, I want to avoid iterative methods (such > as KSPLSQR), since the number of iterations can get very large, and would > like to use a direct QR solving method. > Currently, I am running my code on only 1 core, and A is of type seqaij. > With this setup, the following code works fine: > > call KSPSetType(ksp, KSPPREONLY, ierr) > call KSPGetPC(ksp, pc, ierr) > call PCSetType(pc, PCQR, ierr) > call KSPSetOperators(ksp, A, A, ierr) > t1 = MPI_Wtime() > call KSPSolve(ksp, b, x, ierr) > t2 = MPI_Wtime() > > I eventually want to run this in parallel on multiple cores. Will PCQR > work for an mpiaij / mpidense matrix? > No it is only serial. We could call the ScLAPACK or Elemental version of QR, but we don't right now. > If not, what would you suggest as a direct solving approach for this > system? > It would be easy to make the normal equations (dot products would make the matrix on all procs) and factor. > 2) I would also like to compute an explicit QR decomposition of A, and > want to do so in parallel. Is there any way to do so in PETSc? If not, as a > possible alternative, would you recommend using SLEPc BVOrthogonalize > function? > I would definitely recommend using BV. I have been meaning to pull that into PETSc because it is so great, but have not done it yet. You can just reconfigure with --download-slepc and run with it. Thanks, Matt > Kind regards, > Leonardo > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Z4T-_YeS6p8NNr11QP3I3s_AuA703BYFYU_kioU8FmIJV9NlyY9GTk0HN36-zO9hRinjxpI1ipiRQe8yYU1n$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Sun Mar 29 17:24:54 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Mon, 30 Mar 2026 00:24:54 +0200 Subject: [petsc-users] DMSwarm Initialization on a DMPlex (PIC scheme) In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> Message-ID: <4A8D4097-F2FC-4753-AED4-302B0089DF29@upm.es> Dear all, I am experiencing an issue where particles created with DMSwarm are being increased across MPI ranks when initializing a DMSwarm over a periodic DMPlex. I follow this procedure on every rank: Create a sequential vector with the global coordinates of all particles (18,000 atoms). Call DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, &cellSF) to find which particles belong to the local DMPlex partition. Then call PetscSFGetGraph. Iterate through the results and add any particle with a valid cell index (index != DMLOCATEPOINT_POINT_NOT_FOUND) to the local DMSwarm. The sum of n_atoms_local across all ranks gives 18,740 instead of the expected 18,000. It seems that particles located exactly on periodic boundaries or MPI interfaces are being identified as "found" by multiple ranks simultaneously. Does DMLocatePoints return points found in ghost/halo cells by default when the DMPlex is periodic or distributed with overlap? Thanks, Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Sun Mar 29 19:50:42 2026 From: knepley at gmail.com (Matthew Knepley) Date: Sun, 29 Mar 2026 20:50:42 -0400 Subject: [petsc-users] DMSwarm Initialization on a DMPlex (PIC scheme) In-Reply-To: <4A8D4097-F2FC-4753-AED4-302B0089DF29@upm.es> References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> <4A8D4097-F2FC-4753-AED4-302B0089DF29@upm.es> Message-ID: On Sun, Mar 29, 2026 at 6:25?PM Miguel Molinos wrote: > Dear all, > > I am experiencing an issue where particles created with DMSwarm are being > increased across MPI ranks when initializing a DMSwarm over a periodic > DMPlex. I follow this procedure on every rank: > > 1. > > Create a sequential vector with the global coordinates of all > particles (18,000 atoms). > 2. > > Call DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, > &cellSF) to find which particles belong to the local DMPlex partition. Then > call PetscSFGetGraph. > 3. > > Iterate through the results and add any particle with a valid cell > index (index != DMLOCATEPOINT_POINT_NOT_FOUND) to the local DMSwarm. > > The sum of n_atoms_local across all ranks gives 18,740 instead of the > expected 18,000. It seems that particles located exactly on periodic > boundaries or MPI interfaces are being identified as "found" by multiple > ranks simultaneously. Does DMLocatePoints return points found in ghost/halo > cells by default when the DMPlex is periodic or distributed with overlap? > I do not think this should happen at periodic boundaries, but definitely if you have cell overlap it will happen. It iterates over all local cells to check particle location. You could discard those points by checking if the cell is in the point SF in Step 3. Thanks, Matt > Thanks, > > Miguel > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!asSid27diNY8deyJIRO7sClJg5Rp59NAjfq_99WjlYxUYDas8kx6pf9AEu-ySF2VTzFf-cbhEjrxpQSaC54Y$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.molinos at upm.es Mon Mar 30 13:20:53 2026 From: m.molinos at upm.es (Miguel Molinos) Date: Mon, 30 Mar 2026 20:20:53 +0200 Subject: [petsc-users] DMSwarm Initialization on a DMPlex (PIC scheme) In-Reply-To: References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> <4A8D4097-F2FC-4753-AED4-302B0089DF29@upm.es> Message-ID: <14FE915F-1C9B-444C-A315-D057C2C85B06@upm.es> Thank you Matt Indeed the right way was to use the rank property of the SF. Thanks, Miguel PetscCall( DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, &cellSF)); PetscCall(PetscSFGetGraph(cellSF, &nroots, NULL, NULL, &LA_sfcell)); PetscCall(VecGetArray(coordinates, &coordinates_ptr)); // Note: mean_q_ptr should be filled based on n_atoms_local increment for (PetscInt site_i = 0; site_i < n_atoms; site_i++) { // Check if the point is found in the local process if (LA_sfcell[site_i].rank == rank_MPI) { idx_ptr[n_atoms_local] = site_i; for (int alpha = 0; alpha < dim; alpha++) { mean_q_ptr[n_atoms_local * dim + alpha] = Simulation_file.mean_q[site_i * dim + alpha]; } n_atoms_local++; } } > On Mar 30, 2026, at 2:50?AM, Matthew Knepley wrote: > > On Sun, Mar 29, 2026 at 6:25?PM Miguel Molinos > wrote: >> Dear all, >> >> I am experiencing an issue where particles created with DMSwarm are being increased across MPI ranks when initializing a DMSwarm over a periodic DMPlex. I follow this procedure on every rank: >> >> Create a sequential vector with the global coordinates of all particles (18,000 atoms). >> >> Call DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, &cellSF) to find which particles belong to the local DMPlex partition. Then call PetscSFGetGraph. >> >> Iterate through the results and add any particle with a valid cell index (index != DMLOCATEPOINT_POINT_NOT_FOUND) to the local DMSwarm. >> >> The sum of n_atoms_local across all ranks gives 18,740 instead of the expected 18,000. It seems that particles located exactly on periodic boundaries or MPI interfaces are being identified as "found" by multiple ranks simultaneously. Does DMLocatePoints return points found in ghost/halo cells by default when the DMPlex is periodic or distributed with overlap? >> > I do not think this should happen at periodic boundaries, but definitely if you have cell overlap it will happen. It iterates over all local cells to check particle location. You could discard those points by checking if the cell is in the point SF in Step 3. > > Thanks, > > Matt >> Thanks, >> >> Miguel >> > > > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dhM8KIoPRZB22Da7-tZeGcTAKt33F9B8fGduBARq61MGINsttNyOQ0iz4oOuKSstx8O9_w-Ukkrip9fFSmO136sx$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From knepley at gmail.com Mon Mar 30 15:09:35 2026 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 30 Mar 2026 16:09:35 -0400 Subject: [petsc-users] DMSwarm Initialization on a DMPlex (PIC scheme) In-Reply-To: <14FE915F-1C9B-444C-A315-D057C2C85B06@upm.es> References: <35478FEE-0065-4684-9507-964583B48EB7@upm.es> <4A8D4097-F2FC-4753-AED4-302B0089DF29@upm.es> <14FE915F-1C9B-444C-A315-D057C2C85B06@upm.es> Message-ID: On Mon, Mar 30, 2026 at 2:21?PM Miguel Molinos wrote: > Thank you Matt > > Indeed the right way was to use the rank property of the SF. > Great! Sometime you will have to show me some of the results. Thanks, Matt > Thanks, > Miguel > > PetscCall( > DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, &cellSF)); > PetscCall(PetscSFGetGraph(cellSF, &nroots, NULL, NULL, &LA_sfcell)); > > PetscCall(VecGetArray(coordinates, &coordinates_ptr)); > > // Note: mean_q_ptr should be filled based on n_atoms_local increment > for (PetscInt site_i = 0; site_i < n_atoms; site_i++) { > // Check if the point is found in the local process > if (LA_sfcell[site_i].rank == rank_MPI) { > idx_ptr[n_atoms_local] = site_i; > for (int alpha = 0; alpha < dim; alpha++) { > mean_q_ptr[n_atoms_local * dim + alpha] = > Simulation_file.mean_q[site_i * dim + alpha]; > } > n_atoms_local++; > } > } > > > On Mar 30, 2026, at 2:50?AM, Matthew Knepley wrote: > > On Sun, Mar 29, 2026 at 6:25?PM Miguel Molinos wrote: > >> Dear all, >> >> I am experiencing an issue where particles created with DMSwarm are being >> increased across MPI ranks when initializing a DMSwarm over a periodic >> DMPlex. I follow this procedure on every rank: >> >> 1. >> >> Create a sequential vector with the global coordinates of all >> particles (18,000 atoms). >> 2. >> >> Call DMLocatePoints(FE_Mesh, coordinates, DM_POINTLOCATION_NONE, >> &cellSF) to find which particles belong to the local DMPlex partition. Then >> call PetscSFGetGraph. >> 3. >> >> Iterate through the results and add any particle with a valid cell >> index (index != DMLOCATEPOINT_POINT_NOT_FOUND) to the local DMSwarm. >> >> The sum of n_atoms_local across all ranks gives 18,740 instead of the >> expected 18,000. It seems that particles located exactly on periodic >> boundaries or MPI interfaces are being identified as "found" by multiple >> ranks simultaneously. Does DMLocatePoints return points found in ghost/halo >> cells by default when the DMPlex is periodic or distributed with overlap? >> > I do not think this should happen at periodic boundaries, but definitely > if you have cell overlap it will happen. It iterates over all local cells > to check particle location. You could discard those points by checking if > the cell is in the point SF in Step 3. > > Thanks, > > Matt > >> Thanks, >> >> Miguel >> > > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bxNF7CZVEFp0DL1eyWSI-q2mEvdEpUJBuYVryE4HyTVqCjf90sjlGjoC8DR4_2B411ZwzCyYUIDIydqguJ43$ > > > > -- 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bxNF7CZVEFp0DL1eyWSI-q2mEvdEpUJBuYVryE4HyTVqCjf90sjlGjoC8DR4_2B411ZwzCyYUIDIydqguJ43$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at petsc.dev Tue Mar 31 11:40:31 2026 From: bsmith at petsc.dev (Barry Smith) Date: Tue, 31 Mar 2026 12:40:31 -0400 Subject: [petsc-users] PETSc 3.25 release available Message-ID: We are pleased to announce the release of PETSc version 3.25.0 at https://urldefense.us/v3/__https://petsc.org/release/download/__;!!G_uCfscf7eWS!crYCqsnsvMAPfCK0pQRgIP1_zCqNubyqDslXRCb0eK3oHK2-fceukuOb5LXIqRCn9y7PkKMIMDvx8qByaeA3Ds4$ A list of the major changes and updates can be found at https://urldefense.us/v3/__https://petsc.org/release/changes/325/__;!!G_uCfscf7eWS!crYCqsnsvMAPfCK0pQRgIP1_zCqNubyqDslXRCb0eK3oHK2-fceukuOb5LXIqRCn9y7PkKMIMDvx8qByE8MHLc0$ The final update to petsc-3.24 i.e petsc-3.24.6 is also available We recommend upgrading to PETSc 3.25.0 soon. As always, please report problems to petsc-maint at mcs.anl.gov and ask questions at petsc-users at mcs.anl.gov This release includes contributions from Alex Lindsay Barry Smith Blaise Bourdin Boris Martin Carl von Bonin Claude Opus 4.6 Claude Sonnet 4.6 Connor Ward Cursor David Wells Eric Chamberland Erik Fabrizzi Erik Fabrizzi Han Liu Hansol Suh James Wright Jared Frazier Jed Brown Jeongu Kim Jonas Heinzmann Jose Roman Junchao Zhang Lisandro Dalcin Louis Moresi Mark Adams Martin Diehl Matthew Knepley Miguel Salazar Mr. Hong Zhang Nils Friess Noam T Num Mendez Nuno Nobre Pablo Brubeck Paul Kuehner Pierre Jolivet Richard Tran Mills Ronald Gould Satish Balay sdargavi Stefano Zampini Stephan Kramer Tobin Davis-Jones Toby Isaac Tom Caruso Victor Eijkhout Zach Atkins and bug reports/proposed improvements received from Baha? Eddine Sidi Hida Chris Douglas @cmdoug David Knezevic Jin Chen Jose E. Roman Lois Curfman McInnes Mathieu Deuse M Weiland Pierre Jolivet Pierre LEDAC Pim Heeman Stefano Zampini Steven Dargaville Victor Eijkhout Vincent Robert As always, thanks for your support, Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: