Parrallel Unstructured Mesh Deformation Interface class by danieldouglas92 · Pull Request #7083 · geodynamics/aspect

danieldouglas92 · 2026-07-22T19:41:09Z

@tjhei @bangerth if there is a proper way to give you credit for this please let me know. This is adding the external_tool_interface mesh deformation plugin that you guys wrote for the ASPECT-Landlab project with the tests that do not require python/landlab.

bangerth · 2026-07-22T20:48:03Z

You'll have to run the indentation script:

diff --git a/include/aspect/mesh_deformation/external_tool_interface.h b/include/aspect/mesh_deformation/external_tool_interface.h
index 7bc9fb9..120b648 100644
--- a/include/aspect/mesh_deformation/external_tool_interface.h
+++ b/include/aspect/mesh_deformation/external_tool_interface.h
@@ -239,4 +239,4 @@ namespace aspect
   }
 }
 
-#endif
\ No newline at end of file
+#endif
diff --git a/source/mesh_deformation/external_tool_interface.cc b/source/mesh_deformation/external_tool_interface.cc
index 6f4d2ee..444321f 100644
--- a/source/mesh_deformation/external_tool_interface.cc
+++ b/source/mesh_deformation/external_tool_interface.cc
@@ -344,4 +344,4 @@ namespace aspect
 
 #undef INSTANTIATE
   }
-}
\ No newline at end of file
+}

bangerth

I wonder what the proper protocol is -- @tjhei and I designed and implemented these classes. We probably shouldn't review this patch :-)

We could say that you (@danieldouglas92) should just review your own pull request ;-) Alternatively, perhaps @MFraters or @Minerallo or @Djneu would be willing to take a look?

danieldouglas92 · 2026-07-23T07:04:17Z

@bangerth I'll quickly go through and at least clean up the documentation and then ping the others once this is ready for a proper review

MFraters

Looks generally good. The current openLEM integration works through a moving grid. I see no reason why not, but can you confirm that it is possible (and efficient) to update the evaluation points in between getting the velocities from aspect and interpolating the velocites back to aspect? Can you add a test which does that?

tjhei · 2026-07-25T09:55:25Z

can we call it ParallelUnstructuredInterface?

MFraters · 2026-07-25T10:04:59Z

can we call it ParallelUnstructuredInterface?

Yes, I think that that is probably a more descriptive name.

tjhei · 2026-07-25T10:08:46Z

I see no reason why not, but can you confirm that it is possible (and efficient) to update the evaluation points in between getting the velocities from aspect and interpolating the velocites back to aspect?

it involves MPI communication but I expect this to be scalable (we use this in a different deal.II code on 100k MPI ranks).

Can you add a test which does that?

We probably should do that. We can triggers this with a simple example where we have mesh adaptivity for example.

danieldouglas92 · 2026-07-25T13:52:58Z

@MFraters I added a test which shows that the update() function resets the evaluation_points()!

Djneu · 2026-07-25T14:49:44Z

+
+        if (my_rank == 0)
+          {
+            // Combine data coming from all ranks and determine closest evaluation point for each DoF:


From this part, this already combines all ranks so later on we don't need to gather everything down to rank 0 in the individual landscape evolution model interfaces?

Add more documentation about this

This piece of code is only an implementation detail (and might be replaced in the future) to deterministically make a decision "which points is closest". It forgets about any information exchanged at the end of this function.

@danieldouglas92 can you add a comment like this?

Djneu · 2026-07-25T14:55:42Z

+         * surface, rather than on the currently deformed top surface
+         * that describes the current elevation map.
+         *
+         * @note This function sets up communication structures that


Will I need to think about resetting the evaluation points on mesh refinement for something like fastscape when its mesh will remain fixed?

We need to rebuild the mapping of external evaluation points and degrees of freedom even if the fastscape mesh stays fixed. This already happens using a signal.

Djneu

Hi all, I mostly just had some questions so I understand everything better, but I think it looks like it does everything that would be needed! If I understand, if fastscape.cc is eventually updated to use this the workflow would be something like:

Set up what the fastscape mesh will be and return the values with set_evaluation_points.
compute_velocity_constrains_on_boundary will then evaluate the solution values everywhere (and have them combined on rank 0), and in compute updated velocities I can use these values to find the velocity differences as well as set up all the compositional kd/kf values needed.

danieldouglas92 · 2026-07-26T15:52:14Z

@MFraters @Djneu I addressed your comments and this should hopefully pass all the testers now

Minerallo · 2026-07-28T00:29:21Z

So in the FastScape C++ coupling we used Utilities::MPI::isend() and irecv() with Wolfgang last year. The current interface from what I see use .compress(), this hide how the information is re-distributed. I wonder if we dont need to access this information for future applications ... ?

danieldouglas92 · 2026-07-28T11:20:25Z

@Minerallo A new comment has been added about the .compress function

tjhei

I only have a few minor comments.

tjhei · 2026-07-28T14:31:23Z

+
+        if (my_rank == 0)
+          {
+            // Combine data coming from all ranks and determine closest evaluation point for each DoF:


This piece of code is only an implementation detail (and might be replaced in the future) to deterministically make a decision "which points is closest". It forgets about any information exchanged at the end of this function.

@danieldouglas92 can you add a comment like this?

MFraters

Can you clarify what happens to the output vector when points are outside of the domain (as discussed)? Maybe initialize the vector with NaN.

Otherwise looks good to me.

MFraters · 2026-07-29T09:08:01Z

+
+      if (!remote_point_evaluator->all_points_found())
+        {
+          this->get_pcout() << "WARNING: not all evaluation points were found inside the domain!" << std::endl;


Can you make a this a debug only output?

Co-authored-by: Timo Heister <heister@clemson.edu> Co-authored-by: Wolfgang Bangerth <bangerth@colostate.edu>

danieldouglas92 · 2026-07-29T11:33:13Z

@MFraters I addressed your comments!

MFraters

Thanks for addressing the comments. Looks good to me now.

bangerth · 2026-07-29T18:55:34Z

Hi all, I mostly just had some questions so I understand everything better, but I think it looks like it does everything that would be needed! If I understand, if fastscape.cc is eventually updated to use this the workflow would be something like:

Set up what the fastscape mesh will be and return the values with set_evaluation_points.

compute_velocity_constrains_on_boundary will then evaluate the solution values everywhere (and have them combined on rank 0), and in compute updated velocities I can use these values to find the velocity differences as well as set up all the compositional kd/kf values needed.

Yes, this is exactly how we think it would look like.

bangerth added the ready to test label Jul 22, 2026

bangerth reviewed Jul 22, 2026

View reviewed changes

bangerth mentioned this pull request Jul 23, 2026

Implement an interface that external surface deformation tools can use. #6584

Closed

danieldouglas92 force-pushed the add_external_tool_interface branch 3 times, most recently from 4c25fd4 to 245c029 Compare July 23, 2026 13:30

MFraters self-assigned this Jul 25, 2026

MFraters reviewed Jul 25, 2026

View reviewed changes

danieldouglas92 force-pushed the add_external_tool_interface branch from 45a39e4 to 0228853 Compare July 25, 2026 13:04

Djneu reviewed Jul 25, 2026

View reviewed changes

Comment thread source/mesh_deformation/parallel_unstructured_interface.cc

Djneu reviewed Jul 25, 2026

View reviewed changes

Comment thread source/mesh_deformation/parallel_unstructured_interface.cc Outdated

Djneu reviewed Jul 25, 2026

View reviewed changes

danieldouglas92 force-pushed the add_external_tool_interface branch from 0228853 to d84490f Compare July 26, 2026 15:51

danieldouglas92 force-pushed the add_external_tool_interface branch 4 times, most recently from 0638271 to 7ceea4a Compare July 26, 2026 20:45

danieldouglas92 commented Jul 28, 2026

View reviewed changes

Comment thread source/mesh_deformation/parallel_unstructured_interface.cc

danieldouglas92 force-pushed the add_external_tool_interface branch from 7ceea4a to d7199d9 Compare July 28, 2026 11:20

danieldouglas92 force-pushed the add_external_tool_interface branch 2 times, most recently from d6b8452 to e13205c Compare July 28, 2026 12:17

tjhei self-requested a review July 28, 2026 14:26

tjhei approved these changes Jul 28, 2026

View reviewed changes

tjhei changed the title ~~Add External Tool Interface~~ Parrallel Unstructured Mesh Deformation Interface class Jul 28, 2026

danieldouglas92 force-pushed the add_external_tool_interface branch 2 times, most recently from 1b00a6b to 33c1573 Compare July 28, 2026 20:16

MFraters reviewed Jul 29, 2026

View reviewed changes

danieldouglas92 and others added 2 commits July 29, 2026 06:58

add parallel_unstructured_interface

e048a93

Co-authored-by: Timo Heister <heister@clemson.edu> Co-authored-by: Wolfgang Bangerth <bangerth@colostate.edu>

add new test

abc0d64

danieldouglas92 force-pushed the add_external_tool_interface branch from 33c1573 to abc0d64 Compare July 29, 2026 10:58

MFraters approved these changes Jul 29, 2026

View reviewed changes

MFraters merged commit a3b493f into geodynamics:main Jul 29, 2026
9 checks passed

Uh oh!

Conversation

danieldouglas92 commented Jul 22, 2026

Uh oh!

bangerth commented Jul 22, 2026

Uh oh!

bangerth left a comment

Choose a reason for hiding this comment

Uh oh!

danieldouglas92 commented Jul 23, 2026

Uh oh!

MFraters left a comment

Choose a reason for hiding this comment

Uh oh!

tjhei commented Jul 25, 2026

Uh oh!

MFraters commented Jul 25, 2026

Uh oh!

tjhei commented Jul 25, 2026

Uh oh!

danieldouglas92 commented Jul 25, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Djneu left a comment

Choose a reason for hiding this comment

Uh oh!

danieldouglas92 commented Jul 26, 2026

Uh oh!

Minerallo commented Jul 28, 2026

Uh oh!

Uh oh!

danieldouglas92 commented Jul 28, 2026

Uh oh!

tjhei left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MFraters left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danieldouglas92 commented Jul 29, 2026

Uh oh!

MFraters left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bangerth commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants