[petsc-users] How to combine different element types into a single DMPlex?
Eric Chamberland
Eric.Chamberland at giref.ulaval.ca
Wed Jul 31 15:16:47 CDT 2024
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) ?
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!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9_yUIGas$
>
> 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!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9-bqwEGn$
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9w0270gm$ >
>>>
>>> --
>>> 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!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9-bqwEGn$
>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9w0270gm$ >
>>>
>>>
>>>
>>> --
>>> 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!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9-bqwEGn$
>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!fgngRI84CI_6fHdWdRiVbv0bvraQkhXyV396Uo5y2mORbR4DjlMYrHTqX0p22Ysp8t9yJPhCL1E3fkbWxmIZpQp6dYhcdaKz9w0270gm$ >
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240731/dea81bef/attachment-0001.html>
More information about the petsc-users
mailing list