Dear Matt,
I have now written a code to transform a DMPlex coming from a DMForest
to a DMPlex of type DM_POLY, by removing the double faces and edges.
Also, I can successfully write this transformed DMPlex of type DM_POLY
to a file.
However, the code to perform the transformation only works on a single
process. Therefore, I distribute the original DMForest to process 0,
perform the transformation to obtain a DMPlex of type DM_POLY.
Is there a way, I can redistribute the transformed DMPlex back to the
original distribution based on the cells' distribution of the original
DMPlex? Can I somehow "store" the distribution of a DMPlex based on how
the cells are divided over the processes, and distribute back to this
original distribution?
Thanks, best regards,
Berend.
p.s. If someone is interested in the code to transform a DMForest to a
DMPlex of type DM_POLY, I am more than happy to share.
On 1/22/24 20:30, Matthew Knepley wrote:
On Mon, Jan 22, 2024 at 2:26 PM Berend van Wachem
<berend.vanwac...@ovgu.de <mailto:berend.vanwac...@ovgu.de>> wrote:
Dear Matt,
The problem is that I haven't figured out how to write a polyhedral
DMplex in parallel. So, currently, I can write the Vec data
in parallel, but the cones for the cells/faces/edges/nodes for the
mesh from just one process to a file (after gathering the
DMplex to a single process).
Ah shoot. Can you send me a polyhedral mesh (or code to generate one) so
I can fix the parallel write problem? Or maybe it is already an issue
and I forgot?
From the restart, I can then read the cone information from one
process from the file, recreate the DMPlex, and then
redistribute it. In this scenario, the Vec data I read in (in
parallel) will not match the correct cells of the DMplex. Hence, I
need to put it in the right place afterwards.
Yes, then searching makes sense. You could call DMLocatePoints(), but
maybe you are doing that.
Thanks,
Matt
Best, Berend.
On 1/22/24 20:03, Matthew Knepley wrote:
> On Mon, Jan 22, 2024 at 1:57 PM Berend van Wachem
<berend.vanwac...@ovgu.de <mailto:berend.vanwac...@ovgu.de>
<mailto:berend.vanwac...@ovgu.de <mailto:berend.vanwac...@ovgu.de>>>
wrote:
>
> Dear Matt,
>
> Thanks for your quick response.
> I have a DMPlex with a polyhedral mesh, and have defined a
number of vectors with data at the cell center. I have generated
> data
> for a number of timesteps, and I write the data for each
point to a file together with the (x,y,z) co-ordinate of the cell
> center.
>
> When I want to do a restart from the DMPlex, I recreate the
DMplex with the polyhedral mesh, redistribute it, and for each cell
> center find the corresponding (x,y,z) co-ordinate and insert
the data that corresponds to it. This is quite expensive, as it
> means I need to compare doubles very often.
>
> But reading your response, this may not be a bad way of doing it?
>
>
> It always seems to be a game of "what do you want to assume?". I
tend to assume that I wrote the DM and Vec in the same order,
> so when I load them they match. This is how Firedrake I/O works,
so that you can load up on a different number of processes
> (https://arxiv.org/abs/2401.05868
<https://arxiv.org/abs/2401.05868> <https://arxiv.org/abs/2401.05868
<https://arxiv.org/abs/2401.05868>>).
>
> So, are you writing a Vec, and then redistributing and writing
another Vec? In the scheme above, you would have to write both
> DMs. Are you trying to avoid this?
>
> Thanks,
>
> Matt
>
> Thanks,
>
> Berend.
>
> On 1/22/24 18:58, Matthew Knepley wrote:
> > On Mon, Jan 22, 2024 at 10:49 AM Berend van Wachem
<berend.vanwac...@ovgu.de <mailto:berend.vanwac...@ovgu.de>
<mailto:berend.vanwac...@ovgu.de <mailto:berend.vanwac...@ovgu.de>>
> <mailto:berend.vanwac...@ovgu.de
<mailto:berend.vanwac...@ovgu.de> <mailto:berend.vanwac...@ovgu.de
<mailto:berend.vanwac...@ovgu.de>>>> wrote:
> >
> > Dear Petsc-Team,
> >
> > Is there a good way to define a unique integer number
in each element
> > (e.g. a cell) of a DMPlex mesh, which is in the same
location,
> > regardless of the number of processors or the
distribution of the mesh
> > over the processors?
> >
> > So, for instance, if I have a DMPlex box mesh, the
top-right-front
> > corner element (e.g. cell) will always have the same
unique number,
> > regardless of the number of processors the mesh is
distributed over?
> >
> > I want to be able to link the results I have achieved
with a mesh from
> > DMPlex on a certain number of cores to the same mesh
from a DMPlex on a
> > different number of cores.
> >
> > Of course, I could make a tree based on the distance
of each element to
> > a certain point (based on the X,Y,Z co-ordinates of
the element), and go
> > through this tree in the same way and define an
integer based on this,
> > but that seems rather cumbersome.
> >
> >
> > I think this is harder than it sounds. The distance will
not work because it can be very degenerate.
> > You could lexicographically sort the coordinates, but this
is hard in parallel. It is fine if you are willing
> > to gather everything on one process. You could put down a
p4est, use the Morton order to number them since this is stable
> for a
> > given refinement. And then within each box
lexicographically sort the centroids. This is definitely cumbersome,
but I cannot
> > think of anything else. This also might have parallel
problems since you need to know how much overlap you need to fill
> each box.
> >
> > Thanks,
> >
> > Matt
> >
> > Thanks and best regards, Berend.
> >
> > --
> > 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/
<https://www.cse.buffalo.edu/~knepley/>
<https://www.cse.buffalo.edu/~knepley/
<https://www.cse.buffalo.edu/~knepley/>>
<http://www.cse.buffalo.edu/~knepley/
<http://www.cse.buffalo.edu/~knepley/>
> <http://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/
<https://www.cse.buffalo.edu/~knepley/>
<http://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/>
