Convert(copy) a refined serial triangulation to a distributed triangulation

101 views
Skip to first unread message

LY XXXiao

unread,
Dec 23, 2023, 10:51:41 AM12/23/23
to deal.II User Group
Dear group (Hi again),

I am trying to use two sets of mesh for different parts of the problem. Mesh 1 (triangulation) is refined outside the program but read through read_vtu() function, which means that it has to be a serial triangulation. The mesh 2 is further refined from Mesh 1 for the heavy computation (and therefore has to be in distributed mode). 

Do you have any smart solution to convert the refined serial triangulation to a distributed one ?

Many thanks and merry xmas,
Longying

Wolfgang Bangerth

unread,
Jan 17, 2024, 8:57:08 PM1/17/24
to dea...@googlegroups.com

On 12/23/23 08:51, LY XXXiao wrote:
>
> I am trying to use two sets of mesh for different parts of the problem.
> Mesh 1 (triangulation) is refined outside the program but read through
> read_vtu() function, which means that it has to be a serial
> triangulation. The mesh 2 is further refined from Mesh 1 for the heavy
> computation (and therefore has to be in distributed mode).
>
> Do you have any smart solution to convert the refined serial
> triangulation to a distributed one ?

Longying:
our apologies for letting your question sit for so long.

It is not true if you read a mesh via GridIn that the triangulation has
to be sequential. You can attach a parallel::distributed::Triangulation
to a GridIn object, and it will happily create a parallel (coarse)
triangulation for you that you can then refine as often as you want.

Best
W.

LY XXXiao

unread,
Jul 15, 2025, 9:16:41 AMJul 15
to deal.II User Group
Hi Wolfgang,

 I think either I didn't understand the function document and your email correctly, or I didn't state it clearly.  I compromised it by reading it in as a normal triangulation, i.e. not distributed. As we are trying to solve larger-scale geophysics problems, we encounter some limitations so I come back to this post.  I assume many applications can benefit from it.

What we want:
There is a distributed refined mesh1 with defined parameters. This mesh has been saved as *.vtu file, with 'serialize_triangulation=true'.
And we want to read it in from the vtu file as a distributed triangulation.

What we have done:
As you suggested, we attached the distributed triangulation to the gridin and used read_vtu(), the n_global_active_cells() is however, 0.  I have attached the test snippet here. Hopefully, you or someone else will have the time to correct my understanding of this function.

Many thanks,
Longying



deal.ii_readvtu_test.cpp

Wolfgang Bangerth

unread,
Jul 15, 2025, 11:32:42 PMJul 15
to dea...@googlegroups.com
On 7/15/25 07:16, LY XXXiao wrote:
>
> What we want:
> There is a distributed refined mesh1 with defined parameters. This mesh has
> been saved as *.vtu file, with 'serialize_triangulation=true'.
> And we want to read it in from the vtu file as a distributed triangulation.
>
> What we have done:
> As you suggested, we attached the distributed triangulation to the gridin and
> used read_vtu(), the n_global_active_cells() is however, 0.  I have attached
> the test snippet here. Hopefully, you or someone else will have the time to
> correct my understanding of this function.

I don't think you can read in distributed, refined triangulations that way.
(Not in the sense of "this isn't implemented", but "this is conceptually not
possible".) If you want to write and read distributed, refined triangulations,
you should use the serialization mechanism for triangulations. VTU is not the
right format for this, there is not enough semantic information in VTU files
to re-create triangulations that way.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/


Luca Heltai

unread,
Jul 16, 2025, 1:28:58 AMJul 16
to Deal.II Users
Actually, I think there is enough information to recreate the full triangulation, provided that you save *one file per processor*, and read back one file per processor.

The reason why this should work, is because the “serialize_triangulation=true”, actually serialises the full triangulation using the serialization mechanisms, and stores that information in a field of the (vtu) xml file that is ignored by paraview. However, the triangulation you have is effectively different on each processor, and you must make sure that you read it back in on each processor in the correct way.

L.
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
> --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/dealii/23459386-0c6a-48b7-82a6-b27df88acff2%40colostate.edu.

blais...@gmail.com

unread,
Aug 25, 2025, 10:47:01 AMAug 25
to deal.II User Group
Could an alternartive be to read it as a serial triangulation and then to partition it as a fullydistributed triangulation using METIS or ZOLTAN?
Sure you would loose the ability to do further dynamic mesh adaptation, but still could be useful
Reply all
Reply to author
Forward
0 new messages