On Wed, Sep 22, 2021 at 3:04 AM Karin&NiKo
<[email protected]> 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
<[email protected]> a écrit :
On Tue, Sep 21, 2021 at 10:31 AM Karin&NiKo
<[email protected]> 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
<[email protected]> 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 <[email protected]>
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!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfsLvKmAp$
<https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfmYFl_DF$ >
--
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!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfsLvKmAp$
<https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfmYFl_DF$ >
--
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!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfsLvKmAp$
<https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!cgLnoLq-w8YlD_y4ZrBQbY1i_SgBSKmVRFIOZU9rULyu9jowettkaC7Srlg-sjuHlrXIjItOOY-dgiXMDyfGE3fljVcPVgrTfmYFl_DF$ >