Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Free surface extension to arbitrary deformation #2071

Closed

Conversation

gassmoeller
Copy link
Member

This is a suggestion for an implementation of #2067 (some documentation still missing). I have verified that it works as intended, but I would like to ask for opinions about the interface design. Currently each new mesh deformation plugin can add constraints to the constraint matrix that is used to solve the Laplace problem of distributing the mesh vertices. This gives plugins great flexibility, but also feels a bit weird, because users need to know a lot about the internals to be able to write a new plugin. I have considered two alternative approaches, but they have their own problems:

  1. an interface of the form Tensor<1,dim> vertex_velocity (Point<dim> position) is very intuitive, but for plugins that internally solve some kind of other problem (e.g. a projection in FreeSurface) it is actually not simple to compute this kind of information. These plugins by design handle deformation-velocity as a vector for all points, not a point-wise quantity.
  2. an interface of the form void mesh_deformation(Vector &mesh_velocity) would allow even more flexibility. In particular if a plugin wants to prescribe every vertex, it does not even need to solve the Laplace problem. In my above proposed interface one could maybe improvise this behavior by constraining every DoF, but that might lead to solver problems, or might be slow (constraint matrices are probably not designed for constraining all DoFs?).

Is there a better approach I do not see, or should we just stick with the current interface, and work around problems when (if) they appear?

void
Function<dim>::update ()
{
function.set_time(this->get_time());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just so we do not forget this later on: I think in the final version this should also take into account the parameter Use years in output instead of seconds.

@MFraters
Copy link
Member

Hey Rene,

Very cool, especially the core example! I am not an expert on the free surface code, but I have two comments on the code.

The first comment is about your question. I think that a plugin should be as much self-contained as possible. If I understand the your explanation correctly, all plugins now contribute to a constrained matrix, which is then solved. I would be much more in favour of a structure where these kind of computations are handled internally by the plugins, and the interface would only give back a velocity/displacement/new position/new mesh. Like you say, this is also a bit more more intuitive. I do not fully understand what you mean with the interface void mesh_deformation(Vector &mesh_velocity), so maybe we can talk about that.

The second comment is about the names. I see that you made a very nice namespace MeshDeformation, but then you call the handler FreeSurfaceHandler and in the parameters the section is also called Free surface. The problem is that you also named the free surface plugin freesurface, so it comes quite confusing to read the code. I would suggest that you change free surface in all places, which are not part of the free surface plugin to mesh deformation, which this is much more general. It would break the inputfile, but I think it would make the code (and input) file much more readable.

namespace MeshDeformation
{
/**
* A plugin that computes the deformation of surface "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rm "

* problem, which computes the displacements of the internal
* vertices so that the mesh does not become too distorted due to
* motion of the free surface. Velocities of vertices on the free
* surface are set to be the normal of the Stokes velocity solution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should update the comments to include the "vertical" projection and the Additional tangential mesh velocity boundary indicators.

"deform according to an analytically prescribed "
"function. Note that the function prescribes a "
"deformation velocity, i.e. the return value of "
"the function is multiplied by the time step length "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I understand it, the return value of the function is not multiplied by the time step length here, but the velocity solution computed with the constraints provided here is multiplied by the time step length to compute the mesh displacement. The way it is formulated here, it seems this plugin returns the displacement instead of the displacement velocity.

@anne-glerum
Copy link
Contributor

Hi Rene,
very nice indeed! To me, the interaction of a new plugin of this type with some surface processing code would be very interesting. Such a code would provide a dim-1 grid of surface elevation/surface node location (which could be converted to a grid of surface velocities). I.e. there is no direct information for the motion of every vertex (approach 2.). Some interpolation will be necessary between the SPC grid and the vertices, which could perhaps be combined with approach 1., but your current implementation seems neatest to me.

I'm also a little confused by the MeshDeformation/FreeSurface naming :)

@gassmoeller
Copy link
Member Author

We discussed this some more, and plan to make an interface with a hierarchy of functions that can be overwritten by the user (inspired by deal.II manifold classes). One would be the current interface function, another one could be of the style:
double surface_velocity (const Point<dim> &position)

Move free surface

Create mesh deformation interface

Add function deformation plugin

Update documentation. Revert cookbook.

Add option to add constraints

Reorganize includes

Update test
@gassmoeller gassmoeller changed the title [WIP] Free surface extension to arbitrary deformation Free surface extension to arbitrary deformation Jun 23, 2018
@anne-glerum
Copy link
Contributor

@gassmoeller The input file of the test needs to be updated (it still includes Model settings)

Copy link
Contributor

@anne-glerum anne-glerum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for updating!
I still feel the naming could be improved as Menno commented before. Why not have a MeshDeformationHandler etc?


private:
/**
* Stabilization parameter for the free surface. Should be between
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove space before Should

private:
/**
* Stabilization parameter for the free surface. Should be between
* zero and one. A value of zero means no stabilization. See Kaus
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove space before See

LinearAlgebra::Vector &output) const;

/**
* Stabilization parameter for the free surface. Should be between
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove extra spaces

* know them by name. This allows the files in which individual
* plugins are implemented to register these plugins, rather than also
* having to modify the Manager class by adding the new initial
* temperature plugin class.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

temperature plugin -> mesh deformation plugin

* Set the boundary conditions for the solution of the elliptic
* problem, which computes the displacements of the internal
* vertices so that the mesh does not become too distorted due to
* motion of the free surface. Velocities of vertices on the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove additional white space

* vertices so that the mesh does not become too distorted due to
* motion of the free surface. Velocities of vertices on the
* deforming surface are fixed according to the selected deformation
* plugins. Velocities of vertices on free-slip
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

* plugins. Velocities of vertices on free-slip
* boundaries are constrained to be tangential to those boundaries.
* Velocities of vertices on no-slip boundaries are set to be zero.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add that when the no-slip boundaries are marked as additional tangential boundaries, their vertex velocities are constraint to be tangential.

# The 'inner core material' model also contains a function that
# represents the resistance to melting/freezing at the inner core
# boundary.
# This phase boundary model combines a prescribed a normal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'a prescribed a normal velocity'

@gassmoeller
Copy link
Member Author

Superseded by #2964.

@gassmoeller gassmoeller deleted the free_surface_extension branch August 6, 2020 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants