[petsc-users] How to combine different element types into a single DMPlex?
Matthew Knepley
knepley at gmail.com
Thu Aug 1 08:24:47 CDT 2024
On Thu, Aug 1, 2024 at 8:23 AM Eric Chamberland <
Eric.Chamberland at giref.ulaval.ca> wrote:
> Hi Matthew,
>
> we have our own format that uses MPI I/O for the initial read, then we
> would like to do almost exactly what we do in ex47.c (
> https://urldefense.us/v3/__https://petsc.org/main/src/dm/impls/plex/tests/ex47.c.html__;!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W06sEuZH$ ) excepted the
> very beginning of the program that will read (MPI I/O) from the disk.
> Then, always in parallel:
>
> 1- Populate a DMPlex with multiple element types (with a variant of
> DMPlexBuildFromCellListParallel ? do you have an example of this?)
>
> 2- Call partitioning (DMPlexDistribute)
>
> 3- Compute overlap (DMPlexDistributeOverlap)
>
> 4- Also compute the corresponding mapping between original element numbers
> and partitonned+overlap elements ( DMPlexNaturalToGlobalBegin/End)
>
> The main point here here is overlap computation. And the big challenge is
> that we must always rely on the fact that never, ever, any node read all
> the mesh: all nodes have only a small part of it at the beginning then we
> want parallel partitioning and overlapping computation...
>
> It is now working fine for a mesh with a single type of element, but if we
> can modify ex47.c with an example of a mixed element types that will
> achieve what we would like to do!
>
> We can do that. We only need to change step 1. I will put it on my TODO
list. My thinking is the same as Vaclav, namely to replace numCorners with
a PetscSection describing the cells[] array. Will that work for you?
Thanks,
Matt
> Thanks,
>
> Eric
>
>
> On 2024-07-31 22:09, Matthew Knepley wrote:
>
> On Wed, Jul 31, 2024 at 4:16 PM Eric Chamberland <
> Eric.Chamberland at giref.ulaval.ca> wrote:
>
>> Hi Vaclav,
>>
>> Okay, I am coming back with this question after some time... ;)
>>
>> I am just wondering if it is now possible to call
>> DMPlexBuildFromCellListParallel or something else, to build a mesh that
>> combine different element types into a single DMPlex (in parallel of
>> course) ?
>>
> 1) Meshes with different cell types are fully functional, and some
> applications have been using them for a while now.
>
> 2) The Firedrake I/O methods support these hybrid meshes.
>
> 3) You can, for example, read in a GMsh or ExodusII file with different
> cell types.
>
> However, there is no direct interface like
> DMPlexBuildFromCellListParallel(). If you plan on creating meshes by hand,
> I can build that for you.
> No one so far has wanted that. Rather they want to read in a mesh in some
> format, or alter a base mesh by inserting other cell types.
>
> So, what is the motivating use case?
>
> Thanks,
>
> Matt
>
>> Thanks,
>>
>> Eric
>> On 2021-09-23 11:30, Hapla Vaclav wrote:
>>
>> Note there will soon be a generalization of
>> DMPlexBuildFromCellListParallel() around, as a side product of our current
>> collaborative efforts with Firedrake guys. It will take a PetscSection
>> instead of relying on the blocksize [which is indeed always constant for
>> the given dataset]. Stay tuned.
>>
>> https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/4350__;!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W_UAR2Yb$
>>
>> Thanks,
>>
>> Vaclav
>>
>> On 23 Sep 2021, at 16:53, Eric Chamberland <
>> Eric.Chamberland at giref.ulaval.ca> wrote:
>>
>> Hi,
>>
>> oh, that's a great news!
>>
>> In our case we have our home-made file-format, invariant to the number of
>> processes (thanks to MPI_File_set_view), that uses collective, asynchronous
>> MPI I/O native calls for unstructured hybrid meshes and fields .
>>
>> So our needs are not for reading meshes but only to fill an hybrid DMPlex
>> with DMPlexBuildFromCellListParallel (or something else to come?)... to
>> exploit petsc partitioners and parallel overlap computation...
>>
>> Thanks for the follow-up! :)
>>
>> Eric
>>
>>
>> On 2021-09-22 7:20 a.m., Matthew Knepley wrote:
>>
>> On Wed, Sep 22, 2021 at 3:04 AM Karin&NiKo <niko.karin at gmail.com> wrote:
>>
>>> Dear Matthew,
>>>
>>> This is great news!
>>> For my part, I would be mostly interested in the parallel input
>>> interface. Sorry for that...
>>> Indeed, in our application, we already have a parallel mesh data
>>> structure that supports hybrid meshes with parallel I/O and distribution
>>> (based on the MED format). We would like to use a DMPlex to make parallel
>>> mesh adaptation.
>>> As a matter of fact, all our meshes are in the MED format. We could
>>> also contribute to extend the interface of DMPlex with MED (if you consider
>>> it could be usefull).
>>>
>>
>> An MED interface does exist. I stopped using it for two reasons:
>>
>> 1) The code was not portable and the build was failing on different
>> architectures. I had to manually fix it.
>>
>> 2) The boundary markers did not provide global information, so that
>> parallel reading was much harder.
>>
>> Feel free to update my MED reader to a better design.
>>
>> Thanks,
>>
>> Matt
>>
>>
>>> Best regards,
>>> Nicolas
>>>
>>>
>>> Le mar. 21 sept. 2021 à 21:56, Matthew Knepley <knepley at gmail.com> a
>>> écrit :
>>>
>>>> On Tue, Sep 21, 2021 at 10:31 AM Karin&NiKo <niko.karin at gmail.com>
>>>> wrote:
>>>>
>>>>> Dear Eric, dear Matthew,
>>>>>
>>>>> I share Eric's desire to be able to manipulate meshes composed of
>>>>> different types of elements in a PETSc's DMPlex.
>>>>> Since this discussion, is there anything new on this feature for the
>>>>> DMPlex object or am I missing something?
>>>>>
>>>>
>>>> Thanks for finding this!
>>>>
>>>> Okay, I did a rewrite of the Plex internals this summer. It should now
>>>> be possible to interpolate a mesh with any
>>>> number of cell types, partition it, redistribute it, and many other
>>>> manipulations.
>>>>
>>>> You can read in some formats that support hybrid meshes. If you let me
>>>> know how you plan to read it in, we can make it work.
>>>> Right now, I don't want to make input interfaces that no one will ever
>>>> use. We have a project, joint with Firedrake, to finalize
>>>> parallel I/O. This will make parallel reading and writing for
>>>> checkpointing possible, supporting topology, geometry, fields and
>>>> layouts, for many meshes in one HDF5 file. I think we will finish in
>>>> November.
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>> Thanks,
>>>>> Nicolas
>>>>>
>>>>> Le mer. 21 juil. 2021 à 04:25, Eric Chamberland <
>>>>> Eric.Chamberland at giref.ulaval.ca> a écrit :
>>>>>
>>>>>> Hi,
>>>>>> On 2021-07-14 3:14 p.m., Matthew Knepley wrote:
>>>>>>
>>>>>> On Wed, Jul 14, 2021 at 1:25 PM Eric Chamberland <
>>>>>> Eric.Chamberland at giref.ulaval.ca> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> while playing with DMPlexBuildFromCellListParallel, I noticed we
>>>>>>> have to
>>>>>>> specify "numCorners" which is a fixed value, then gives a fixed
>>>>>>> number
>>>>>>> of nodes for a series of elements.
>>>>>>>
>>>>>>> How can I then add, for example, triangles and quadrangles into a
>>>>>>> DMPlex?
>>>>>>>
>>>>>>
>>>>>> You can't with that function. It would be much mich more complicated
>>>>>> if you could, and I am not sure
>>>>>> it is worth it for that function. The reason is that you would need
>>>>>> index information to offset into the
>>>>>> connectivity list, and that would need to be replicated to some
>>>>>> extent so that all processes know what
>>>>>> the others are doing. Possible, but complicated.
>>>>>>
>>>>>> Maybe I can help suggest something for what you are trying to do?
>>>>>>
>>>>>> Yes: we are trying to partition our parallel mesh with PETSc
>>>>>> functions. The mesh has been read in parallel so each process owns a part
>>>>>> of it, but we have to manage mixed elements types.
>>>>>>
>>>>>> When we directly use ParMETIS_V3_PartMeshKway, we give two arrays to
>>>>>> describe the elements which allows mixed elements.
>>>>>>
>>>>>> So, how would I read my mixed mesh in parallel and give it to PETSc
>>>>>> DMPlex so I can use a PetscPartitioner with DMPlexDistribute ?
>>>>>>
>>>>>> A second goal we have is to use PETSc to compute the overlap, which
>>>>>> is something I can't find in PARMetis (and any other partitionning library?)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> --
>>>>>>> Eric Chamberland, ing., M. Ing
>>>>>>> Professionnel de recherche
>>>>>>> GIREF/Université Laval
>>>>>>> (418) 656-2131 poste 41 22 42
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7WzLKFxyz$
>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W4OhwXgr$ >
>>>>>>
>>>>>> --
>>>>>> Eric Chamberland, ing., M. Ing
>>>>>> Professionnel de recherche
>>>>>> GIREF/Université Laval
>>>>>> (418) 656-2131 poste 41 22 42
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> 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!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7WzLKFxyz$
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W4OhwXgr$ >
>>>>
>>>
>>
>> --
>> 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!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7WzLKFxyz$
>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W4OhwXgr$ >
>>
>> --
>> Eric Chamberland, ing., M. Ing
>> Professionnel de recherche
>> GIREF/Université Laval
>> (418) 656-2131 poste 41 22 42
>>
>>
>> --
>> Eric Chamberland, ing., M. Ing
>> Professionnel de recherche
>> GIREF/Université Laval
>> (418) 656-2131 poste 41 22 42
>>
>>
>
> --
> 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!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7WzLKFxyz$
> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W4OhwXgr$ >
>
> --
> Eric Chamberland, ing., M. Ing
> Professionnel de recherche
> GIREF/Université Laval
> (418) 656-2131 poste 41 22 42
>
>
--
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!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7WzLKFxyz$ <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!aHeMEPfb0Meog5f2a3LiP86hnFxzuIQvMnwh6xTVli7pOyTG58-uCFxfN1vPwH43kT7LT5MKKPc7W4OhwXgr$ >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240801/837a0049/attachment-0001.html>
More information about the petsc-users
mailing list