I think the above Jed's reply declared what I am worried about. That is: if I don't use faking 3D elements, automatic topological interpolation is not available. I also notice your discussion with Nicolas. You suggest users could do it themselves by using GetRawFaces etc. I think maybe I can try to do it another time.
Thank you very much Yuan 2021年11月3日(水) 20:19 Matthew Knepley <[email protected]>: > On Tue, Nov 2, 2021 at 10:49 PM 袁煕 <[email protected]> wrote: > >> Well! All objects in this world could definitely be modeled as 3D >> volumes. But considering costs of meshing and following calculations, in >> most cases it is neither practical nor necessary. And in some specific >> cases, e.g., to model cell membranes, 2D membrane elements may behave >> better than 3D volume ones. It is therefore, in many cases, modeling should >> be much simplified and in some cases they could be modeled as 2D or 1D ones. >> > > I have _never_ suggested using 3D elements, as you can see from my reply > to Nicolas. I said you can use _exactly_ the element you want. I am not > sure how to be more clear. > > Matt > > >> Following paper is obtained after just google "parachute, FSI" >> *A parallel 3D computational method for fluid-structure interactions in >> parachute systems >> <https://www.researchgate.net/publication/228719684_A_parallel_3D_computational_method_for_fluid-structure_interactions_in_parachute_systems>* >> >> You can see they use cable (1D) and membrane (2D) elements to model >> parachutes. Those public software, such as ABAQUS, ANSYS, NASTRAN, etc all >> allow the mixed usage of topologically different elements. They tell the >> same story. It is the reality and I don't think such reality would change >> in the near future. >> >> Best regards >> >> Yuan >> >> 2021年11月2日(火) 18:22 Matthew Knepley <[email protected]>: >> >>> On Mon, Nov 1, 2021 at 11:20 PM 袁煕 <[email protected]> wrote: >>> >>>> Dear Matthew, >>>> >>>> I built a test problem using the strategy you suggested. It works! It >>>> is enough for me right now. Thank you very much. >>>> >>>> ! 9----------8----------13 >>>> ! /| /| /| >>>> ! / | / | / | >>>> ! / | / | / | >>>> ! 6---------7---------12 | >>>> ! | | | | | | >>>> ! | | | | | | >>>> ! | | | | | | >>>> ! | | | | | | >>>> ! | 5------|---4-------|--11--------17------16 >>>> ! | / | / | / / / >>>> ! | / | / | / / / >>>> ! |/ |/ |/ / / >>>> ! 2-- ------3---------10--------14-------15 >>>> >>>> coneSize = (/ 8,8,8,8, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 /) >>>> cones = (/ 2,5,4,3,6,7,8,9, 3,4,11,10,7,12,13,8, & >>>> 10,14,17,11, 10,14,17,11, 14,15,16,17, 14,15,16,17 /) >>>> >>>> There is still a problem left, however, that is how to build a 3D cell >>>> from a 2 vertex segment. I think I could construct a virtual tetrahedron. >>>> >>>> Finally, It can't be denied that this approach needs additional effort >>>> in mesh construction (and It is something strange to construct a 3D object >>>> from a one dimensional segment). In fact, structures with different >>>> topological dimensions are not that rare. Parachute, for example, may be >>>> composed with two dimensional parafoil and one dimensional cord. FRP(Fiber >>>> reinforced plastics) may be modelled by one dimensional reinforcement and >>>> three dimensional plastics. It is therefore, I am wondering, if PETSc would >>>> take into consider of such cases by, for example >>>> >>>> - Enable a face, DM_POLYTOPE_SEGMENT2D, defined by one edge. And >>>> - Eable cells, such >>>> as DM_POLYTOPE_QUADRILATERAL3D, DM_POLYTOPE_TRIANGLE3D and >>>> DM_POLYTOPE_SEGMENT3D, with one face. >>>> >>> >>> I think I am still not being completely clear. These types of cells >>> definitely exist. However, let's take the case of the parachute. The one >>> dimensional cords are part of >>> the two dimensional patches, which are part of a three dimensional >>> volume. This is how we have modeled it. You assemble different equations on >>> different pieces, but >>> that does not affect the mesh. >>> >>> Thanks, >>> >>> Matt >>> >>> >>>> Sorry for a newbie in PETSc to provide such a suggestion. But if it >>>> could be accomplished, it would help mech structural engineering, civil >>>> engineering, and solid mechanics applicationers. >>>> >>>> Best regards, >>>> >>>> Yuan >>>> >>>> >>>> >>>> 2021年11月1日(月) 18:32 Matthew Knepley <[email protected]>: >>>> >>>>> On Sun, Oct 31, 2021 at 12:21 PM 袁煕 <[email protected]> wrote: >>>>> >>>>>> Dear Matt >>>>>> >>>>>> Thank you for your detailed explanation. >>>>>> >>>>>> First, I would like to answer your question about my application >>>>>> where low dimensional features are not embedded in the larger volume. It >>>>>> is >>>>>> quite general in structural engineering. For example, buildings are >>>>>> generally modelled as shells and beams, which are two and one dimension >>>>>> respectively. While building foundation is modelled by solid >>>>>> elements, which is three dimension, at the same time. >>>>>> >>>>> >>>>> I think I see what you want now. Let me make a suggestion (along the >>>>> lines of what Mark said), and attempt to justify it by answering some >>>>> questions. >>>>> >>>>> Suggestion: I think you should consider using a volumetric mesh for >>>>> your problem >>>>> >>>>> Q1: Can I get the same algebraic system this way? >>>>> >>>>> Yes. You would only assign unknowns to faces and edges of the mesh >>>>> where you have shell and beam elements. >>>>> >>>>> Q2: What are the advantages? >>>>> >>>>> You would get topological connectivity of all parts of the structure, >>>>> automatic coupling of the different formulations, >>>>> and you could separately solve the different structures using block >>>>> preconditioners, while still forming a unified >>>>> residual so that you can guarantee a consistent solution. >>>>> >>>>> Q3: Wouldn't this be expensive? >>>>> >>>>> No. For the shells and beams, you would still need the vertices, >>>>> edges, and faces. First, by the Euler relation, these would >>>>> outnumbers the additional cells. Second, since no unknowns would be >>>>> associated with the cells, only additional memory in >>>>> the mesh would be used, not the system solves. Memory and time are >>>>> dominated by the solve, so this should be in the noise. >>>>> >>>>> What do you think? >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> >>>>>> Secondly, It is regrettably to find that DMComposite is not available >>>>>> for me, because all my solid, shell, and beam elements are connected each >>>>>> other. >>>>>> >>>>>> At last, I have build a simple program to see if DMPlexSetCellType() >>>>>> works for me, following the suggestion of functions in PETSc like >>>>>> DMPlexCreateCGNS. But it failed when it tried to do DMPlexInterpolate >>>>>> ! 9----------8---------13 >>>>>> ! /| /| /| >>>>>> ! / | / | / | >>>>>> ! / | / | / | >>>>>> ! 6---------7---------12 | >>>>>> ! | | | | | | >>>>>> ! | | | | | | >>>>>> ! | | | | | | >>>>>> ! | | | | | | >>>>>> ! | 5------|---4-------|-11--------17--------16 >>>>>> ! | / | / | / / / >>>>>> ! | / | / | / / / >>>>>> ! |/ |/ |/ / / >>>>>> ! 2---------3---------10--------14-------15 >>>>>> >>>>>> The calculation result are follows. It seems that the cell type are >>>>>> set correctly but depth is still 2. >>>>>> -------------------------------------------------------------------- >>>>>> DM Object: TestMesh 2 MPI processes >>>>>> type: plex >>>>>> TestMesh in 3 dimensions: >>>>>> 0-cells: 16 0 >>>>>> 3-cells: 20 (18) 0 >>>>>> Labels: >>>>>> celltype: 3 strata with value/size (7 (2), 4 (2), 0 (16)) >>>>>> depth: 2 strata with value/size (0 (16), 1 (20)) >>>>>> [0]PETSC ERROR: --------------------- Error Message >>>>>> -------------------------------------------------------------- >>>>>> [0]PETSC ERROR: Object is in wrong state >>>>>> [0]PETSC ERROR: Array was not checked out >>>>>> [0]PETSC ERROR: See https://petsc.org/release/faq/ for trouble >>>>>> shooting. >>>>>> [0]PETSC ERROR: Petsc Development GIT revision: >>>>>> v3.16.0-351-g743e004674 GIT Date: 2021-10-29 09:32:23 -0500 >>>>>> [0]PETSC ERROR: ./ex3f90 on a arch-linux-c-debug named >>>>>> DESKTOP-9ITFSBM by hillyuan Mon Nov 1 00:26:39 2021 >>>>>> [0]PETSC ERROR: Configure options --with-cc=mpiicc --with-cxx=mpiicpc >>>>>> --with-fc=mpiifort --with-fortran-bindings=1 >>>>>> --with-blaslapack-dir=/opt/intel/oneapi/mkl/2021.3.0 >>>>>> --with-mkl_pardiso-dir=/opt/intel/oneapi/mkl/2021.3.0 >>>>>> [0]PETSC ERROR: #1 DMRestoreWorkArray() at >>>>>> /home/hillyuan/programs/petsc/src/dm/interface/dm.c:1580 >>>>>> [0]PETSC ERROR: #2 DMPlexRestoreRawFaces_Internal() at >>>>>> /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:323 >>>>>> [0]PETSC ERROR: #3 DMPlexInterpolateFaces_Internal() at >>>>>> /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:375 >>>>>> [0]PETSC ERROR: #4 DMPlexInterpolate() at >>>>>> /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:1340 >>>>>> >>>>>> ----------------------------------------------------------------------------------------- >>>>>> I attached my test program in this mail. It is much appreciated that >>>>>> you could provide any suggestion. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yuan >>>>>> >>>>>> >>>>>> 2021年10月31日(日) 21:16 Matthew Knepley <[email protected]>: >>>>>> >>>>>>> On Thu, Oct 28, 2021 at 10:48 PM 袁煕 <[email protected]> wrote: >>>>>>> >>>>>>>> Dear Matt, >>>>>>>> >>>>>>>> My mesh is something like the following figure, which is >>>>>>>> composed of three elements : one hexahedron(solid element), one >>>>>>>> quadrilateral (shell element), and one line (beam element). I found the >>>>>>>> function "TestEmptyStrata" in file \dm\impls\plex\tests\ex11.c >>>>>>>> would be a good example to read in such a kind of mesh by using >>>>>>>> DMPlexSetCone. But a problem is that you should declare all faces and >>>>>>>> edges >>>>>>>> of hexahedron element, all edges in quadrilateral element by >>>>>>>> DMPlexSetCone, otherwise PETsc could not do >>>>>>>> topological interpolation afterwards. Am I right here? >>>>>>>> As general in FEM mesh, my mesh does not contain any information >>>>>>>> about faces or edges of solid elements. That's why I consider >>>>>>>> using DMCOMPOSITE. That is >>>>>>>> >>>>>>>> - Put hexahedron, quadrilateral, and line elements into >>>>>>>> different DM structures. >>>>>>>> - do topological interpolation in those DMs separately. >>>>>>>> - composite them. >>>>>>>> >>>>>>>> Is there anything wrong in my above consideration? Any >>>>>>>> suggestions? >>>>>>>> >>>>>>>> ------------ >>>>>>>> /| /| >>>>>>>> / | / | cell 0: Hex >>>>>>>> / | / | >>>>>>>> ------------/ | >>>>>>>> | | | | >>>>>>>> | | | | cell 1: Quad >>>>>>>> | --------|---|------------ >>>>>>>> | / | / / >>>>>>>> | / | / / >>>>>>>> |/ |/ / >>>>>>>> ------------------------------------------- >>>>>>>> cell 2: line >>>>>>>> >>>>>>>> Much thanks for your help. >>>>>>>> >>>>>>> >>>>>>> If you are solving something where everything is embedded in a >>>>>>> volumetric mesh, then there is no problem. However, if you really have >>>>>>> the mesh above, where lower dimensional pieces are sticking out of >>>>>>> the mesh, then Plex can represent the mesh, but automatic interpolation >>>>>>> (creation of edges and faces) will not work. Why is this? We use >>>>>>> depth in the DAG as a proxy for cell dimension, but this will no longer >>>>>>> work >>>>>>> if faces are not part of a volume. >>>>>>> >>>>>>> Will DMCOMPOSITE do what you want? It depends. It will be able to >>>>>>> lay out a vector, but it will not know about any topological >>>>>>> connectivity >>>>>>> between the meshes and will not preallocate a Jacobian with any >>>>>>> interaction. If the meshes are truly separate, this is fine. If not, it >>>>>>> is >>>>>>> not that >>>>>>> useful. >>>>>>> >>>>>>> Could you modify the existing code to support this? Yes, it would >>>>>>> not be terribly difficult. When you load the mesh, you must know what >>>>>>> kind >>>>>>> of cell you are loading. You could explicitly set this using >>>>>>> DMPlexSetCellType(). Then, instead of taking a certain height stratum of >>>>>>> the DAG >>>>>>> to loop over, you would instead use all cells marked with a certain >>>>>>> cell type. The rest of the interpolation code should work fine. >>>>>>> >>>>>>> What kind of physics do you have where low dimensional features are >>>>>>> not embedded in the larger volume? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>>> Yuan >>>>>>>> >>>>>>>> 2021年10月28日(木) 22:05 Matthew Knepley <[email protected]>: >>>>>>>> >>>>>>>>> On Thu, Oct 28, 2021 at 4:59 AM 袁煕 <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Dear Matt, >>>>>>>>>> >>>>>>>>>> Thank you for your quick response. >>>>>>>>>> >>>>>>>>>> I think what you mean is to build DAG from my mesh at first and >>>>>>>>>> then call DMPlexCreateFromDAG >>>>>>>>>> <https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexCreateFromDAG.html#DMPlexCreateFromDAG>() >>>>>>>>>> to construct DMPlex. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, I do not mean that. >>>>>>>>> >>>>>>>>> >>>>>>>>>> A new problem is, as I know, the function DMPlexInterpolate would >>>>>>>>>> generate points with different depth. What's the difference between >>>>>>>>>> those >>>>>>>>>> faces and segment elements generated by DMPlexInterpolate with that >>>>>>>>>> defined by the original mesh, or should we not use DMPlexInterpolate >>>>>>>>>> in >>>>>>>>>> such a case? >>>>>>>>>> >>>>>>>>>> On the other hand, can DMComposite be used in this case by >>>>>>>>>> defining DMPlex with different topological dimensions at first and >>>>>>>>>> then >>>>>>>>>> composite them? >>>>>>>>>> >>>>>>>>> >>>>>>>>> You do not need that. I am obviously not understanding your >>>>>>>>> question. My short answer is that Plex _already_ handles cells of >>>>>>>>> different >>>>>>>>> dimension automatically without anything extra. >>>>>>>>> >>>>>>>>> Maybe it would help if you defined a specific problem you have. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks in advance. >>>>>>>>>> >>>>>>>>>> Yuan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2021年10月27日(水) 19:27 Matthew Knepley <[email protected]>: >>>>>>>>>> >>>>>>>>>>> On Wed, Oct 27, 2021 at 4:50 AM 袁煕 <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am trying to parallelize my serial FEM program using PETSc. >>>>>>>>>>>> This program calculates structure deformation by using various >>>>>>>>>>>> types of >>>>>>>>>>>> elements such as solid, shell, beam, and truss. At the very >>>>>>>>>>>> beginning, I >>>>>>>>>>>> found it was hard for me to put such kinds of elements into >>>>>>>>>>>> DMPlex. Because >>>>>>>>>>>> solid elements are topologically three dimensional, shell element >>>>>>>>>>>> two, and >>>>>>>>>>>> beam or truss are topologically one-dimensional elements. After >>>>>>>>>>>> reading >>>>>>>>>>>> chapter 2.10: "DMPlex: Unstructured Grids in PETSc" of users manual >>>>>>>>>>>> carefully, I found the provided functions, such as DMPlexSetCone, >>>>>>>>>>>> cannot >>>>>>>>>>>> declare those topological differences. >>>>>>>>>>>> >>>>>>>>>>>> My question is : Is it possible and how to define all those >>>>>>>>>>>> topologically different elements into a DMPlex struct? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes. The idea is to program in a dimension-independent way, so >>>>>>>>>>> that the code can handle cells of any dimension. >>>>>>>>>>> What you probably want is the "depth" in the DAG representation, >>>>>>>>>>> which you can think of as the dimension of a cell. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexGetPointDepth.html#DMPlexGetPointDepth >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks in advance! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Yuan. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> What most experimenters take for granted before they begin their >>>>>>>>>>> experiments is infinitely more interesting than any results to >>>>>>>>>>> which their >>>>>>>>>>> experiments lead. >>>>>>>>>>> -- Norbert Wiener >>>>>>>>>>> >>>>>>>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>>>>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> What most experimenters take for granted before they begin their >>>>>>>>> experiments is infinitely more interesting than any results to which >>>>>>>>> their >>>>>>>>> experiments lead. >>>>>>>>> -- Norbert Wiener >>>>>>>>> >>>>>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> What most experimenters take for granted before they begin their >>>>>>> experiments is infinitely more interesting than any results to which >>>>>>> their >>>>>>> experiments lead. >>>>>>> -- Norbert Wiener >>>>>>> >>>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> What most experimenters take for granted before they begin their >>>>> experiments is infinitely more interesting than any results to which their >>>>> experiments lead. >>>>> -- Norbert Wiener >>>>> >>>>> https://www.cse.buffalo.edu/~knepley/ >>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>> >>>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >>> >>> https://www.cse.buffalo.edu/~knepley/ >>> <http://www.cse.buffalo.edu/~knepley/> >>> >> > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> >
