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
Free surface extension to arbitrary deformation #2071
Conversation
2702f83
to
549eb6c
Compare
source/mesh_deformation/function.cc
Outdated
void | ||
Function<dim>::update () | ||
{ | ||
function.set_time(this->get_time()); |
There was a problem hiding this comment.
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
.
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 The second comment is about the names. I see that you made a very nice namespace |
namespace MeshDeformation | ||
{ | ||
/** | ||
* A plugin that computes the deformation of surface " |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
.
source/mesh_deformation/function.cc
Outdated
"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 " |
There was a problem hiding this comment.
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.
Hi Rene, I'm also a little confused by the MeshDeformation/FreeSurface naming :) |
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: |
18e941f
to
b1fd488
Compare
Move free surface Create mesh deformation interface Add function deformation plugin Update documentation. Revert cookbook. Add option to add constraints Reorganize includes Update test
b1fd488
to
cf2f1aa
Compare
7c2b49f
to
0253270
Compare
@gassmoeller The input file of the test needs to be updated (it still includes Model settings) |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. | ||
*/ |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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'
Superseded by #2964. |
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:
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 inFreeSurface
) 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.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?