From em459 at bath.ac.uk Wed Jul 1 04:51:22 2026 From: em459 at bath.ac.uk (Eike Mueller) Date: Wed, 1 Jul 2026 09:51:22 +0000 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected Message-ID: Dear PETSc developers, I?m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$ Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that?s probably not the best solution. Thanks a lot, Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.zampini at gmail.com Wed Jul 1 04:57:03 2026 From: stefano.zampini at gmail.com (Stefano Zampini) Date: Wed, 1 Jul 2026 11:57:03 +0200 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected In-Reply-To: References: Message-ID: Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users < petsc-users at mcs.anl.gov> ha scritto: > Dear PETSc developers, > > I?m using a code which checks > > #if PETSC_VERSION_GT(3, 24, 5) > // do something > #endif > > For my PETSc installation I have: > > #define PETSC_VERSION_RELEASE 0 > #define PETSC_VERSION_MAJOR 3 > #define PETSC_VERSION_MINOR 24 > #define PETSC_VERSION_SUBMINOR 4 > > Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will > always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, > since there is no mention of PETSC_VERSION_RELEASE in the documentation at > https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!eXtIe5AlCt-M_9NTY6mTYUFfAOSlre4lUJNgNeQL-KzEpNIlkhB-nENTTXc73Pm2jCf-mrxbN-EiQGg4BJEOajxm692uuQo$ > > > > Is this intended behaviour? Is there a good way of checking the version > irrespective of RELEASE? I can of course always copy and modify the > definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 > bit, but that?s probably not the best solution. > > Thanks a lot, > > Eike > -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From em459 at bath.ac.uk Wed Jul 1 05:01:33 2026 From: em459 at bath.ac.uk (Eike Mueller) Date: Wed, 1 Jul 2026 10:01:33 +0000 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected In-Reply-To: References: Message-ID: <1A6BDA83-E40E-4FF4-861A-492D822FC9D7@bath.ac.uk> Dear Stefano, Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn?t be used, since PETSc assumes that I?ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless? All the best, Eike On 1 Jul 2026, at 11:57, Stefano Zampini wrote: You don't often get email from stefano.zampini at gmail.com. Learn why this is important CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users > ha scritto: Dear PETSc developers, I?m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!dK_G2FqkxEB61-gt5y9yXSRRMwOUDSdecJWpolADZwyWo2D8GoaR_rqMv-Tha4kP0XxOK3nZ5vyTVeObTgIcPw$ Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that?s probably not the best solution. Thanks a lot, Eike -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.zampini at gmail.com Wed Jul 1 05:10:25 2026 From: stefano.zampini at gmail.com (Stefano Zampini) Date: Wed, 1 Jul 2026 12:10:25 +0200 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected In-Reply-To: <1A6BDA83-E40E-4FF4-861A-492D822FC9D7@bath.ac.uk> References: <1A6BDA83-E40E-4FF4-861A-492D822FC9D7@bath.ac.uk> Message-ID: > > > > Thank you for the prompt reply! So does that mean that in this case > PETSC_VERSION_GT (or any of the related functions) shouldn?t be used, since > PETSc assumes that I?ll keep track of versions and PETSC_VERSION_MAJOR etc. > are essentially meaningless? > They are not meaningless, as packages using PETSc use them to distinguish between software releases. If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything. What is your specific use case? > > All the best, > > Eike > > On 1 Jul 2026, at 11:57, Stefano Zampini > wrote: > > You don't often get email from stefano.zampini at gmail.com. Learn why this > is important > > *CAUTION: * This email came from outside of the University. To keep your > account safe, only click on links and open attachments if you know the > person who sent the email, or you expected to receive this communication. > > Dear Eike > > PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off > the release branch > Otherwise, if you branched off main, it is 0. > The model behind is that new developments won't need to care about older > versions. > This means that, if you use a development version of PETSc obtained from > git, we assume you'll keep updating it. > Does it make sense to you? > > Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users < > petsc-users at mcs.anl.gov> ha scritto: > >> Dear PETSc developers, >> >> I?m using a code which checks >> >> #if PETSC_VERSION_GT(3, 24, 5) >> // do something >> #endif >> >> For my PETSc installation I have: >> >> #define PETSC_VERSION_RELEASE 0 >> #define PETSC_VERSION_MAJOR 3 >> #define PETSC_VERSION_MINOR 24 >> #define PETSC_VERSION_SUBMINOR 4 >> >> Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will >> always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, >> since there is no mention of PETSC_VERSION_RELEASE in the documentation at >> https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!ad8GqP9izvZda6GYXhaU-6kMioIi9KP-wNYVU3oahOFcSjZW46knA4tRtfy5Ajkng2tIpXkK5kcCZjc4g9upfpo3E6AVQtU$ >> >> >> >> Is this intended behaviour? Is there a good way of checking the version >> irrespective of RELEASE? I can of course always copy and modify the >> definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 >> bit, but that?s probably not the best solution. >> >> Thanks a lot, >> >> Eike >> > > > -- > Stefano > > > -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From em459 at bath.ac.uk Wed Jul 1 12:22:17 2026 From: em459 at bath.ac.uk (Eike Mueller) Date: Wed, 1 Jul 2026 17:22:17 +0000 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected In-Reply-To: References: <1A6BDA83-E40E-4FF4-861A-492D822FC9D7@bath.ac.uk> Message-ID: <6ED676F8-9757-447D-8673-A229541A31D9@bath.ac.uk> Dear Stefano, I?m using the PETSc main branch since I?ve done a developer install of Firedrake. The code I use relies on PETSC_VERSION_GT to support different PETSc versions. But Nils has fixed this now, by simply requiring a sufficiently high PETSc version in CMake. With that, there is no longer any need for PETSC_VERSION_GT in the source code. All the best, Eike On 1 Jul 2026, at 12:10, Stefano Zampini wrote: CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn?t be used, since PETSc assumes that I?ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless? They are not meaningless, as packages using PETSc use them to distinguish between software releases. If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything. What is your specific use case? All the best, Eike On 1 Jul 2026, at 11:57, Stefano Zampini > wrote: You don't often get email from stefano.zampini at gmail.com. Learn why this is important CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users > ha scritto: Dear PETSc developers, I?m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!YQTN7SVBlprILJigcY_ch3FjaIk5ZO3_qLH6wPNmJH5yxvCkknQ0RViS6w1xHPdd34yIaJJnrvSAcvAuTOnbSg$ Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that?s probably not the best solution. Thanks a lot, Eike -- Stefano -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From jed at jedbrown.org Wed Jul 1 14:04:13 2026 From: jed at jedbrown.org (Jed Brown) Date: Wed, 01 Jul 2026 13:04:13 -0600 Subject: [petsc-users] PETSC_VERSION_GT doesn't behave as I would have expected In-Reply-To: <6ED676F8-9757-447D-8673-A229541A31D9@bath.ac.uk> References: <1A6BDA83-E40E-4FF4-861A-492D822FC9D7@bath.ac.uk> <6ED676F8-9757-447D-8673-A229541A31D9@bath.ac.uk> Message-ID: <87jyrelefm.fsf@jedbrown.org> The behavior is intentional. PETSc does not support or make stability guarantees for old non-release snapshots, so development versions shall behave as +Infinity. If you're living on 'main', you should expect to update it across any changes that impact your work. Note that the subminor version also has no significance when working on the 'main' branch. Sometimes a fix lands in 'main' first and later is ported to 'release' (if the fix needs to be performed in a different way), so having an old subminor version on 'main' doesn't even mean that a bug is still present. (The subminor version is updated for patch releases on 'release' and they arrive on 'main' whenever 'release' is merged forward.) Eike Mueller via petsc-users writes: > Dear Stefano, > > I?m using the PETSc main branch since I?ve done a developer install of Firedrake. The code I use relies on PETSC_VERSION_GT to support different PETSc versions. But Nils has fixed this now, by simply requiring a sufficiently high PETSc version in CMake. With that, there is no longer any need for PETSC_VERSION_GT in the source code. > > All the best, > > Eike > > On 1 Jul 2026, at 12:10, Stefano Zampini wrote: > > CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. > > > > Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn?t be used, since PETSc assumes that I?ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless? > > They are not meaningless, as packages using PETSc use them to distinguish between software releases. > If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release > > Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything. > > What is your specific use case? > > > All the best, > > Eike > > On 1 Jul 2026, at 11:57, Stefano Zampini > wrote: > > You don't often get email from stefano.zampini at gmail.com. Learn why this is important > CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. > > Dear Eike > > PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch > Otherwise, if you branched off main, it is 0. > The model behind is that new developments won't need to care about older versions. > This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. > Does it make sense to you? > > Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users > ha scritto: > Dear PETSc developers, > > I?m using a code which checks > > #if PETSC_VERSION_GT(3, 24, 5) > // do something > #endif > > For my PETSc installation I have: > > #define PETSC_VERSION_RELEASE 0 > #define PETSC_VERSION_MAJOR 3 > #define PETSC_VERSION_MINOR 24 > #define PETSC_VERSION_SUBMINOR 4 > > Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!YQTN7SVBlprILJigcY_ch3FjaIk5ZO3_qLH6wPNmJH5yxvCkknQ0RViS6w1xHPdd34yIaJJnrvSAcvAuTOnbSg$ > > Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that?s probably not the best solution. > > Thanks a lot, > > Eike > > > -- > Stefano > > > > -- > Stefano From matteo.semplice at uninsubria.it Thu Jul 2 09:55:14 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Thu, 2 Jul 2026 16:55:14 +0200 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes Message-ID: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> Dear PETSc, ? ? I am a bit puzzled by the 3d tet mesh representations as DMPlex. I boiled it down to a mesh of a single tet. More specifically, * if a I create the mesh as ? const PetscInt dim=3; ? const PetscInt numCells=1; // The number of cells, only on process 0 ? const PetscInt numVertices=4; // The number of vertices owned by this process, or PETSC_DECIDE, only on process 0 ? const PetscInt numCorners=4; // The number of vertices for each cell, only on process 0 ? const PetscBool interpolate=PETSC_TRUE; // should intermediate mesh entities (faces, edges) be created? ? // An array of numCells?numCornersnumCells?numCorners numbers, the vertices for each cell, only on process 0 ? const PetscInt cells[] = {0,1,2,3 }; ? const PetscInt spaceDim=3; // The spatial dimension used for coordinates ? // An array of numVertices?spaceDimnumVertices?spaceDim numbers, the coordinates of each vertex, only on process 0 ? const PetscReal vertexCoords[] = { 0,0,0, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1,0,0, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,1,0, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,0,1 }; ? PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, dim, ? ? ? ? ? ? ?numCells, numVertices, numCorners, interpolate, cells, ? ? ? ? ? ? ?spaceDim, vertexCoords, dmMesh) ); I get the representation that I would expect: DM Object: Mesh 1 MPI process ?type: plex Mesh in 3 dimensions: ?Number of 0-cells per rank: 4 ?Number of 1-cells per rank: 6 ?Number of 2-cells per rank: 4 ?Number of 3-cells per rank: 1 Labels: ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) Mesh with 1 cells with DMPlexGetCellCoordinates giving me the coordinates CELL 0 with vertices at ( 0.000, ????0, 0.000 ) ( 1.000, ????0, 0.000 ) ( 0.000, ????1, 0.000 ) ( 0.000, ????0, 1.000 ) * on the other hand, if I load the MSH file $MeshFormat 2.2 0 8 $EndMeshFormat $Nodes 4 1 0.0 0.0 0.0 2 1.0 0.0 0.0 3 0.0 1.0 0.0 4 0.0 0.0 1.0 $EndNodes $Elements 1 1 4 2 0 1 1 2 3 4 $EndElements with DMPlexCreateGmshFromFile, the first and second vertices are swapped and I get DM Object: Mesh 1 MPI process ?type: plex Mesh in 3 dimensions: ?Number of 0-cells per rank: 4 ?Number of 1-cells per rank: 6 ?Number of 2-cells per rank: 4 ?Number of 3-cells per rank: 1 Labels: ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) ?Cell Sets: 1 strata with value/size (0 (1)) Mesh with 1 cells with DMPlexGetCellCoordinates giving me CELL 0 with vertices at ( 1.000, ????0, 0.000 ) ( 0.000, ????0, 0.000 ) ( 0.000, ????1, 0.000 ) ( 0.000, ????0, 1.000 ) I understand that this behaviour is somehow consistent with the formulas in DMPlexComputeTetrahedronGeometry_Internal, where you compute the Jacobians swappnig the order of vertices (and with 0.5 factors that I do not understand at all... it looks as if your reference element was not the unit simplex) if (J) { ? ? ?for (d = 0; d < dim; d++) { ? ? ? ?/* I orient with outward face normals */ ? ? ? ?J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ? ?J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ? ?J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ?} } but still I am worried by this fact that different ways of creating a mesh gives a DMPlex with different orientations. Can you explain the rationale behind this or refer me to some documentation? Best ? ? 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 jed at jedbrown.org Thu Jul 2 10:22:22 2026 From: jed at jedbrown.org (Jed Brown) Date: Thu, 02 Jul 2026 09:22:22 -0600 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes In-Reply-To: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> References: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> Message-ID: <87y0ftju1d.fsf@jedbrown.org> DMPlex internal ordering is not the same as VTK ordering. The code you supply will have an inward-facing normal (as evaluated by DMPlex geometry routines). The IO routines translate to the internal ordering convention. If you are creating a mesh manually or writing a new file reader, you should use (or convert to) the DMPlex convention. Matteo Semplice via petsc-users writes: > Dear PETSc, > > ? ? I am a bit puzzled by the 3d tet mesh representations as DMPlex. I > boiled it down to a mesh of a single tet. More specifically, > > * if a I create the mesh as > > ? const PetscInt dim=3; > ? const PetscInt numCells=1; // The number of cells, only on > process 0 > ? const PetscInt numVertices=4; // The number of vertices owned > by this process, or PETSC_DECIDE, only on process 0 > ? const PetscInt numCorners=4; // The number of vertices for > each cell, only on process 0 > ? const PetscBool interpolate=PETSC_TRUE; // should > intermediate mesh entities (faces, edges) be created? > ? // An array of numCells?numCornersnumCells?numCorners > numbers, the vertices for each cell, only on process 0 > ? const PetscInt cells[] = {0,1,2,3 }; > ? const PetscInt spaceDim=3; // The spatial dimension used for > coordinates > ? // An array of numVertices?spaceDimnumVertices?spaceDim > numbers, the coordinates of each vertex, only on process 0 > ? const PetscReal vertexCoords[] = { 0,0,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1,0,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,1,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,0,1 }; > ? PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, dim, > ? ? ? ? ? ? ?numCells, numVertices, numCorners, interpolate, cells, > ? ? ? ? ? ? ?spaceDim, vertexCoords, dmMesh) ); > > I get the representation that I would expect: > > DM Object: Mesh 1 MPI process > ?type: plex > Mesh in 3 dimensions: > ?Number of 0-cells per rank: 4 > ?Number of 1-cells per rank: 6 > ?Number of 2-cells per rank: 4 > ?Number of 3-cells per rank: 1 > Labels: > ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me the coordinates > > CELL 0 with vertices at > ( 0.000, ????0, 0.000 ) > ( 1.000, ????0, 0.000 ) > ( 0.000, ????1, 0.000 ) > ( 0.000, ????0, 1.000 ) > > * on the other hand, if I load the MSH file > > $MeshFormat > 2.2 0 8 > $EndMeshFormat > $Nodes > 4 > 1 0.0 0.0 0.0 > 2 1.0 0.0 0.0 > 3 0.0 1.0 0.0 > 4 0.0 0.0 1.0 > $EndNodes > $Elements > 1 > 1 4 2 0 1 1 2 3 4 > $EndElements > > with DMPlexCreateGmshFromFile, the first and second vertices are > swapped and I get > > DM Object: Mesh 1 MPI process > ?type: plex > Mesh in 3 dimensions: > ?Number of 0-cells per rank: 4 > ?Number of 1-cells per rank: 6 > ?Number of 2-cells per rank: 4 > ?Number of 3-cells per rank: 1 > Labels: > ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > ?Cell Sets: 1 strata with value/size (0 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me > > CELL 0 with vertices at > ( 1.000, ????0, 0.000 ) > ( 0.000, ????0, 0.000 ) > ( 0.000, ????1, 0.000 ) > ( 0.000, ????0, 1.000 ) > > I understand that this behaviour is somehow consistent with the formulas > in DMPlexComputeTetrahedronGeometry_Internal, where you compute the > Jacobians swappnig the order of vertices (and with 0.5 factors that I do > not understand at all... it looks as if your reference element was not > the unit simplex) > > if (J) { > ? ? ?for (d = 0; d < dim; d++) { > ? ? ? ?/* I orient with outward face normals */ > ? ? ? ?J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ?} > } > > but still I am worried by this fact that different ways of creating a > mesh gives a DMPlex with different orientations. > > Can you explain the rationale behind this or refer me to some > documentation? > > Best > > ? ? 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 From matteo.semplice at uninsubria.it Thu Jul 2 10:26:02 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Thu, 2 Jul 2026 17:26:02 +0200 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes In-Reply-To: <87y0ftju1d.fsf@jedbrown.org> References: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> <87y0ftju1d.fsf@jedbrown.org> Message-ID: Thanks! ? ? is there a document explaining the DMPLex internal ordering? (and by the way what's the reason to have the factors 0.5 in the jacobians? I would not expect them if the reference tet is (0,0,0), (1,0,0), etc if (J) { ? ? ?for (d = 0; d < dim; d++) { ? ? ? ?/* I orient with outward face normals */ ? ? ? ?J[d * dim + 0] =*0.5* * (PetscRealPart(coords[2 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ? ?J[d * dim + 1] =*0.5* * (PetscRealPart(coords[1 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ? ?J[d * dim + 2] =*0.5* * (PetscRealPart(coords[3 * dim + d]) - PetscRealPart(coords[0 * dim + d])); ? ? ?} } Thanks ? ? Matteo Il 02/07/26 17:22, Jed Brown ha scritto: > DMPlex internal ordering is not the same as VTK ordering. The code you supply will have an inward-facing normal (as evaluated by DMPlex geometry routines). The IO routines translate to the internal ordering convention. If you are creating a mesh manually or writing a new file reader, you should use (or convert to) the DMPlex convention. > > Matteo Semplice via petsc-users writes: > >> Dear PETSc, >> >> ? ? I am a bit puzzled by the 3d tet mesh representations as DMPlex. I >> boiled it down to a mesh of a single tet. More specifically, >> >> * if a I create the mesh as >> >> ? const PetscInt dim=3; >> ? const PetscInt numCells=1; // The number of cells, only on >> process 0 >> ? const PetscInt numVertices=4; // The number of vertices owned >> by this process, or PETSC_DECIDE, only on process 0 >> ? const PetscInt numCorners=4; // The number of vertices for >> each cell, only on process 0 >> ? const PetscBool interpolate=PETSC_TRUE; // should >> intermediate mesh entities (faces, edges) be created? >> ? // An array of numCells?numCornersnumCells?numCorners >> numbers, the vertices for each cell, only on process 0 >> ? const PetscInt cells[] = {0,1,2,3 }; >> ? const PetscInt spaceDim=3; // The spatial dimension used for >> coordinates >> ? // An array of numVertices?spaceDimnumVertices?spaceDim >> numbers, the coordinates of each vertex, only on process 0 >> ? const PetscReal vertexCoords[] = { 0,0,0, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1,0,0, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,1,0, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,0,1 }; >> ? PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, dim, >> ? ? ? ? ? ? ?numCells, numVertices, numCorners, interpolate, cells, >> ? ? ? ? ? ? ?spaceDim, vertexCoords, dmMesh) ); >> >> I get the representation that I would expect: >> >> DM Object: Mesh 1 MPI process >> ?type: plex >> Mesh in 3 dimensions: >> ?Number of 0-cells per rank: 4 >> ?Number of 1-cells per rank: 6 >> ?Number of 2-cells per rank: 4 >> ?Number of 3-cells per rank: 1 >> Labels: >> ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) >> ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) >> Mesh with 1 cells >> >> with DMPlexGetCellCoordinates giving me the coordinates >> >> CELL 0 with vertices at >> ( 0.000, ????0, 0.000 ) >> ( 1.000, ????0, 0.000 ) >> ( 0.000, ????1, 0.000 ) >> ( 0.000, ????0, 1.000 ) >> >> * on the other hand, if I load the MSH file >> >> $MeshFormat >> 2.2 0 8 >> $EndMeshFormat >> $Nodes >> 4 >> 1 0.0 0.0 0.0 >> 2 1.0 0.0 0.0 >> 3 0.0 1.0 0.0 >> 4 0.0 0.0 1.0 >> $EndNodes >> $Elements >> 1 >> 1 4 2 0 1 1 2 3 4 >> $EndElements >> >> with DMPlexCreateGmshFromFile, the first and second vertices are >> swapped and I get >> >> DM Object: Mesh 1 MPI process >> ?type: plex >> Mesh in 3 dimensions: >> ?Number of 0-cells per rank: 4 >> ?Number of 1-cells per rank: 6 >> ?Number of 2-cells per rank: 4 >> ?Number of 3-cells per rank: 1 >> Labels: >> ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) >> ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) >> ?Cell Sets: 1 strata with value/size (0 (1)) >> Mesh with 1 cells >> >> with DMPlexGetCellCoordinates giving me >> >> CELL 0 with vertices at >> ( 1.000, ????0, 0.000 ) >> ( 0.000, ????0, 0.000 ) >> ( 0.000, ????1, 0.000 ) >> ( 0.000, ????0, 1.000 ) >> >> I understand that this behaviour is somehow consistent with the formulas >> in DMPlexComputeTetrahedronGeometry_Internal, where you compute the >> Jacobians swappnig the order of vertices (and with 0.5 factors that I do >> not understand at all... it looks as if your reference element was not >> the unit simplex) >> >> if (J) { >> ? ? ?for (d = 0; d < dim; d++) { >> ? ? ? ?/* I orient with outward face normals */ >> ? ? ? ?J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + d]) - >> PetscRealPart(coords[0 * dim + d])); >> ? ? ? ?J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + d]) - >> PetscRealPart(coords[0 * dim + d])); >> ? ? ? ?J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + d]) - >> PetscRealPart(coords[0 * dim + d])); >> ? ? ?} >> } >> >> but still I am worried by this fact that different ways of creating a >> mesh gives a DMPlex with different orientations. >> >> Can you explain the rationale behind this or refer me to some >> documentation? >> >> Best >> >> ? ? 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 -- 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 jed at jedbrown.org Thu Jul 2 10:34:43 2026 From: jed at jedbrown.org (Jed Brown) Date: Thu, 02 Jul 2026 09:34:43 -0600 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes In-Reply-To: References: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> <87y0ftju1d.fsf@jedbrown.org> Message-ID: <87v7axjtgs.fsf@jedbrown.org> See DMPlexCreateReferenceCell_Internal (in plexcreate.c), and look at the coordinates. One common convention for the reference line segment is (-1, 1), which is the natural domain for Legendre polynomials and quadrature. Some packages use this, and some use (0, 1). There is a similar choice of reference element for triangles and tetrahedra. Matteo Semplice writes: > Thanks! > > ? ? is there a document explaining the DMPLex internal ordering? > > (and by the way what's the reason to have the factors 0.5 in the > jacobians? I would not expect them if the reference tet is (0,0,0), > (1,0,0), etc > > if (J) { > ? ? ?for (d = 0; d < dim; d++) { > ? ? ? ?/* I orient with outward face normals */ > ? ? ? ?J[d * dim + 0] =*0.5* * (PetscRealPart(coords[2 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 1] =*0.5* * (PetscRealPart(coords[1 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 2] =*0.5* * (PetscRealPart(coords[3 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > ? ? ?} > } > > Thanks > > ? ? Matteo > > Il 02/07/26 17:22, Jed Brown ha scritto: >> DMPlex internal ordering is not the same as VTK ordering. The code you supply will have an inward-facing normal (as evaluated by DMPlex geometry routines). The IO routines translate to the internal ordering convention. If you are creating a mesh manually or writing a new file reader, you should use (or convert to) the DMPlex convention. >> >> Matteo Semplice via petsc-users writes: >> >>> Dear PETSc, >>> >>> ? ? I am a bit puzzled by the 3d tet mesh representations as DMPlex. I >>> boiled it down to a mesh of a single tet. More specifically, >>> >>> * if a I create the mesh as >>> >>> ? const PetscInt dim=3; >>> ? const PetscInt numCells=1; // The number of cells, only on >>> process 0 >>> ? const PetscInt numVertices=4; // The number of vertices owned >>> by this process, or PETSC_DECIDE, only on process 0 >>> ? const PetscInt numCorners=4; // The number of vertices for >>> each cell, only on process 0 >>> ? const PetscBool interpolate=PETSC_TRUE; // should >>> intermediate mesh entities (faces, edges) be created? >>> ? // An array of numCells?numCornersnumCells?numCorners >>> numbers, the vertices for each cell, only on process 0 >>> ? const PetscInt cells[] = {0,1,2,3 }; >>> ? const PetscInt spaceDim=3; // The spatial dimension used for >>> coordinates >>> ? // An array of numVertices?spaceDimnumVertices?spaceDim >>> numbers, the coordinates of each vertex, only on process 0 >>> ? const PetscReal vertexCoords[] = { 0,0,0, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1,0,0, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,1,0, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,0,1 }; >>> ? PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, dim, >>> ? ? ? ? ? ? ?numCells, numVertices, numCorners, interpolate, cells, >>> ? ? ? ? ? ? ?spaceDim, vertexCoords, dmMesh) ); >>> >>> I get the representation that I would expect: >>> >>> DM Object: Mesh 1 MPI process >>> ?type: plex >>> Mesh in 3 dimensions: >>> ?Number of 0-cells per rank: 4 >>> ?Number of 1-cells per rank: 6 >>> ?Number of 2-cells per rank: 4 >>> ?Number of 3-cells per rank: 1 >>> Labels: >>> ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) >>> ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) >>> Mesh with 1 cells >>> >>> with DMPlexGetCellCoordinates giving me the coordinates >>> >>> CELL 0 with vertices at >>> ( 0.000, ????0, 0.000 ) >>> ( 1.000, ????0, 0.000 ) >>> ( 0.000, ????1, 0.000 ) >>> ( 0.000, ????0, 1.000 ) >>> >>> * on the other hand, if I load the MSH file >>> >>> $MeshFormat >>> 2.2 0 8 >>> $EndMeshFormat >>> $Nodes >>> 4 >>> 1 0.0 0.0 0.0 >>> 2 1.0 0.0 0.0 >>> 3 0.0 1.0 0.0 >>> 4 0.0 0.0 1.0 >>> $EndNodes >>> $Elements >>> 1 >>> 1 4 2 0 1 1 2 3 4 >>> $EndElements >>> >>> with DMPlexCreateGmshFromFile, the first and second vertices are >>> swapped and I get >>> >>> DM Object: Mesh 1 MPI process >>> ?type: plex >>> Mesh in 3 dimensions: >>> ?Number of 0-cells per rank: 4 >>> ?Number of 1-cells per rank: 6 >>> ?Number of 2-cells per rank: 4 >>> ?Number of 3-cells per rank: 1 >>> Labels: >>> ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) >>> ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) >>> ?Cell Sets: 1 strata with value/size (0 (1)) >>> Mesh with 1 cells >>> >>> with DMPlexGetCellCoordinates giving me >>> >>> CELL 0 with vertices at >>> ( 1.000, ????0, 0.000 ) >>> ( 0.000, ????0, 0.000 ) >>> ( 0.000, ????1, 0.000 ) >>> ( 0.000, ????0, 1.000 ) >>> >>> I understand that this behaviour is somehow consistent with the formulas >>> in DMPlexComputeTetrahedronGeometry_Internal, where you compute the >>> Jacobians swappnig the order of vertices (and with 0.5 factors that I do >>> not understand at all... it looks as if your reference element was not >>> the unit simplex) >>> >>> if (J) { >>> ? ? ?for (d = 0; d < dim; d++) { >>> ? ? ? ?/* I orient with outward face normals */ >>> ? ? ? ?J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + d]) - >>> PetscRealPart(coords[0 * dim + d])); >>> ? ? ? ?J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + d]) - >>> PetscRealPart(coords[0 * dim + d])); >>> ? ? ? ?J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + d]) - >>> PetscRealPart(coords[0 * dim + d])); >>> ? ? ?} >>> } >>> >>> but still I am worried by this fact that different ways of creating a >>> mesh gives a DMPlex with different orientations. >>> >>> Can you explain the rationale behind this or refer me to some >>> documentation? >>> >>> Best >>> >>> ? ? 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 > > -- > 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 From knepley at gmail.com Thu Jul 2 18:56:40 2026 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 2 Jul 2026 19:56:40 -0400 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes In-Reply-To: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> References: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> Message-ID: On Thu, Jul 2, 2026 at 10:55?AM Matteo Semplice via petsc-users < petsc-users at mcs.anl.gov> wrote: > Dear PETSc, > > I am a bit puzzled by the 3d tet mesh representations as DMPlex. I > boiled it down to a mesh of a single tet. More specifically, > > - if a I create the mesh as > > const PetscInt dim=3; > const PetscInt numCells=1; // The number of cells, only on process 0 > const PetscInt numVertices=4; // The number of vertices owned by this > process, or PETSC_DECIDE, only on process 0 > const PetscInt numCorners=4; // The number of vertices for each cell, > only on process 0 > const PetscBool interpolate=PETSC_TRUE; // should intermediate mesh > entities (faces, edges) be created? > // An array of numCells?numCornersnumCells?numCorners numbers, the > vertices for each cell, only on process 0 > const PetscInt cells[] = {0,1,2,3 }; > const PetscInt spaceDim=3; // The spatial dimension used for coordinates > // An array of numVertices?spaceDimnumVertices?spaceDim numbers, the > coordinates of each vertex, only on process 0 > const PetscReal vertexCoords[] = { 0,0,0, > 1,0,0, > 0,1,0, > 0,0,1 }; > PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, dim, > numCells, numVertices, numCorners, interpolate, cells, > spaceDim, vertexCoords, dmMesh) ); > > I get the representation that I would expect: > > DM Object: Mesh 1 MPI process > type: plex > Mesh in 3 dimensions: > Number of 0-cells per rank: 4 > Number of 1-cells per rank: 6 > Number of 2-cells per rank: 4 > Number of 3-cells per rank: 1 > Labels: > celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me the coordinates > > CELL 0 with vertices at > ( 0.000, 0, 0.000 ) > ( 1.000, 0, 0.000 ) > ( 0.000, 1, 0.000 ) > ( 0.000, 0, 1.000 ) > > > - on the other hand, if I load the MSH file > > $MeshFormat > 2.2 0 8 > $EndMeshFormat > $Nodes > 4 > 1 0.0 0.0 0.0 > 2 1.0 0.0 0.0 > 3 0.0 1.0 0.0 > 4 0.0 0.0 1.0 > $EndNodes > $Elements > 1 > 1 4 2 0 1 1 2 3 4 > $EndElements > > with DMPlexCreateGmshFromFile, the first and second vertices are swapped > and I get > > DM Object: Mesh 1 MPI process > type: plex > Mesh in 3 dimensions: > Number of 0-cells per rank: 4 > Number of 1-cells per rank: 6 > Number of 2-cells per rank: 4 > Number of 3-cells per rank: 1 > Labels: > celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > Cell Sets: 1 strata with value/size (0 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me > > CELL 0 with vertices at > ( 1.000, 0, 0.000 ) > ( 0.000, 0, 0.000 ) > ( 0.000, 1, 0.000 ) > ( 0.000, 0, 1.000 ) > > I understand that this behaviour is somehow consistent with the formulas > in DMPlexComputeTetrahedronGeometry_Internal, where you compute the > Jacobians swappnig the order of vertices (and with 0.5 factors that I do > not understand at all... it looks as if your reference element was not the > unit simplex) > > if (J) { > for (d = 0; d < dim; d++) { > /* I orient with outward face normals */ > J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + d]) - > PetscRealPart(coords[0 * dim + d])); > } > } > > but still I am worried by this fact that different ways of creating a mesh > gives a DMPlex with different orientations. > > Can you explain the rationale behind this or refer me to some > documentation? > 1. DMPlexCreateFromCellListPetsc() is very low-level, so I let you do whatever you want, including tell me to use inverted cells. DMPlexCreateGmshFromFile() is guaranteed to get a properly oriented simplex from GMsh, so I guarantee that it produces a properly oriented Plex simplex. 2. Here is the order of vertices, and face vertices, in a Plex tetrahedron. https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/blob/main/src/dm/impls/plex/plexinterpolate.c?ref_type=heads*L194__;Iw!!G_uCfscf7eWS!fu9zsNqFCcOd2B75fjpxQSn9mZeYFR3er6s4FhLRrwVo7aVdS4BgUE7eMN4pq3YHjZRId_sQT8Cq0SjYzs6B$ I truly believe the only sensible way to describe a simple is to have every normal outward facing. The convention in Gmsh is to have some normals inward and some outward, which I think is ridiculous. It breaks the inherent symmetry of the simplex. 3. The reference simplex has coordinates 1 and -1, and thus volume 4/3. This is the convention of FIAT ( https://urldefense.us/v3/__https://www.firedrakeproject.org/fiat/index.html__;!!G_uCfscf7eWS!fu9zsNqFCcOd2B75fjpxQSn9mZeYFR3er6s4FhLRrwVo7aVdS4BgUE7eMN4pq3YHjZRId_sQT8Cq0dx6sHl6$ ) 4. You can always get my orientation for things by calling DMPlexOrient(). 5. Orientations are representors for elements of the dihedral group of the k-cell. I am almost done with a description of this for every geometric cell supported (of course you can define any cell you want in Plex). I can show you this if you want, although it is unfinished. Thanks, Matt > Best > > 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 > > -- 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!fu9zsNqFCcOd2B75fjpxQSn9mZeYFR3er6s4FhLRrwVo7aVdS4BgUE7eMN4pq3YHjZRId_sQT8Cq0cS9ccw2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.semplice at uninsubria.it Fri Jul 3 09:39:45 2026 From: matteo.semplice at uninsubria.it (Matteo Semplice) Date: Fri, 3 Jul 2026 16:39:45 +0200 Subject: [petsc-users] orientation of DMPLEX for tetrehedral meshes In-Reply-To: References: <5ce440f8-8be2-4298-8323-c0d302b910bd@uninsubria.it> Message-ID: Thanks both for your replies! Matteo Il 03/07/26 01:56, Matthew Knepley ha scritto: > On Thu, Jul 2, 2026 at 10:55?AM Matteo Semplice via petsc-users > wrote: > > Dear PETSc, > > ? ? I am a bit puzzled by the 3d tet mesh representations as > DMPlex. I boiled it down to a mesh of a single tet. More specifically, > > * if a I create the mesh as > > ? const PetscInt dim=3; > ? const PetscInt numCells=1; // The number of cells, only > on process 0 > ? const PetscInt numVertices=4; // The number of vertices > owned by this process, or PETSC_DECIDE, only on process 0 > ? const PetscInt numCorners=4; // The number of vertices > for each cell, only on process 0 > ? const PetscBool interpolate=PETSC_TRUE; // should > intermediate mesh entities (faces, edges) be created? > ? // An array of numCells?numCornersnumCells?numCorners > numbers, the vertices for each cell, only on process 0 > ? const PetscInt cells[] = {0,1,2,3 }; > ? const PetscInt spaceDim=3; // The spatial dimension used > for coordinates > ? // An array of numVertices?spaceDimnumVertices?spaceDim > numbers, the coordinates of each vertex, only on process 0 > ? const PetscReal vertexCoords[] = { 0,0,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1,0,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,1,0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,0,1 }; > ? PetscCall( DMPlexCreateFromCellListPetsc(MPI_COMM_WORLD, > dim, > ? ? ? ? ? ? ?numCells, numVertices, numCorners, > interpolate, cells, > ? ? ? ? ? ? ?spaceDim, vertexCoords, dmMesh) ); > > I get the representation that I would expect: > > DM Object: Mesh 1 MPI process > ?type: plex > Mesh in 3 dimensions: > ?Number of 0-cells per rank: 4 > ?Number of 1-cells per rank: 6 > ?Number of 2-cells per rank: 4 > ?Number of 3-cells per rank: 1 > Labels: > ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me the coordinates > > CELL 0 with vertices at > ( 0.000, ????0, 0.000 ) > ( 1.000, ????0, 0.000 ) > ( 0.000, ????1, 0.000 ) > ( 0.000, ????0, 1.000 ) > > * on the other hand, if I load the MSH file > > $MeshFormat > 2.2 0 8 > $EndMeshFormat > $Nodes > 4 > 1 0.0 0.0 0.0 > 2 1.0 0.0 0.0 > 3 0.0 1.0 0.0 > 4 0.0 0.0 1.0 > $EndNodes > $Elements > 1 > 1 4 2 0 1 1 2 3 4 > $EndElements > > with DMPlexCreateGmshFromFile, the first and second vertices > are swapped and I get > > DM Object: Mesh 1 MPI process > ?type: plex > Mesh in 3 dimensions: > ?Number of 0-cells per rank: 4 > ?Number of 1-cells per rank: 6 > ?Number of 2-cells per rank: 4 > ?Number of 3-cells per rank: 1 > Labels: > ?celltype: 4 strata with value/size (0 (4), 1 (6), 3 (4), 6 (1)) > ?depth: 4 strata with value/size (0 (4), 1 (6), 2 (4), 3 (1)) > ?Cell Sets: 1 strata with value/size (0 (1)) > Mesh with 1 cells > > with DMPlexGetCellCoordinates giving me > > CELL 0 with vertices at > ( 1.000, ????0, 0.000 ) > ( 0.000, ????0, 0.000 ) > ( 0.000, ????1, 0.000 ) > ( 0.000, ????0, 1.000 ) > > I understand that this behaviour is somehow consistent with the > formulas in DMPlexComputeTetrahedronGeometry_Internal, where you > compute the Jacobians swappnig the order of vertices (and with 0.5 > factors that I do not understand at all... it looks as if your > reference element was not the unit simplex) > > if (J) { > ? ? ?for (d = 0; d < dim; d++) { > ? ? ? ?/* I orient with outward face normals */ > ? ? ? ?J[d * dim + 0] = 0.5 * (PetscRealPart(coords[2 * dim + > d]) - PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 1] = 0.5 * (PetscRealPart(coords[1 * dim + > d]) - PetscRealPart(coords[0 * dim + d])); > ? ? ? ?J[d * dim + 2] = 0.5 * (PetscRealPart(coords[3 * dim + > d]) - PetscRealPart(coords[0 * dim + d])); > ? ? ?} > } > > but still I am worried by this fact that different ways of > creating a mesh gives a DMPlex with different orientations. > > Can you explain the rationale behind this or refer me to some > documentation? > > 1.?DMPlexCreateFromCellListPetsc() is very low-level, so I let you do > whatever you want, including tell me to use inverted > cells.?DMPlexCreateGmshFromFile() is guaranteed to get a properly > oriented simplex from GMsh, so I guarantee that it produces a properly > oriented Plex simplex. > > 2. Here is the order of vertices, and face vertices, in a Plex > tetrahedron. > > https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/blob/main/src/dm/impls/plex/plexinterpolate.c?ref_type=heads*L194__;Iw!!G_uCfscf7eWS!d6tvrzxI6yh_hzS8CpBk5uE1ZZZurd6twtW_RnzPfkPvxUkzTAf6W2LI-clrnlasaru3zm6h5u925ioefyQ5XBiI3f4JQtzhNZ2Fkg$ > > I truly believe the only sensible way to describe a simple is to have > every normal outward facing. The convention in Gmsh is to have some > normals inward and some outward, which I think is ridiculous. It > breaks the inherent symmetry of the simplex. > > 3. The reference simplex has coordinates 1 and -1, and thus volume > 4/3. This is the convention of FIAT > (https://urldefense.us/v3/__https://www.firedrakeproject.org/fiat/index.html__;!!G_uCfscf7eWS!d6tvrzxI6yh_hzS8CpBk5uE1ZZZurd6twtW_RnzPfkPvxUkzTAf6W2LI-clrnlasaru3zm6h5u925ioefyQ5XBiI3f4JQtyQtGQqeg$ ) > > 4. You can always get my orientation for things by calling DMPlexOrient(). > > 5. Orientations are representors for elements of the dihedral group of > the k-cell. I am almost?done with a description of this for every > geometric cell supported (of course you can define any cell you want > in Plex). I can show you this if you want, although it is unfinished. > > ? Thanks, > > ? ? ?Matt > > Best > > ? ? 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 > > > > -- > 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!d6tvrzxI6yh_hzS8CpBk5uE1ZZZurd6twtW_RnzPfkPvxUkzTAf6W2LI-clrnlasaru3zm6h5u925ioefyQ5XBiI3f4JQtx1gAf7kA$ > -- 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: