Pointwise condition to kill "rigid body motion"

[jfbarthelemy]

Dear Ferrite devs and users,

What would be the most direct way to impose a condition on a precise node to avoid rigid body motion in a mechanical problem? I have seen the possibility to impose affine constraints but this implies the knowledge of dof number. Here I would like to impose such a constraint (eg a displacement component equal to zero) on a point defined by its coordinates not its node number or dof number. Ideally it would even be better to be able to impose it on an arbitrary point of the domain (not necessarily a node) thus involving affine conditions on dofs of the nodes attached to the cell containing the point. Is there a straightfoward way to do this in Ferrite?

By the way, I saw that it is not possible in a 3D problem to import physical points or lines from a gmsh mesh although nodesets and linesets exist. Would it be relevant to import such physical groups in order to be able to handle a problem such as the one evoked above?

Thanks in advance

[KnutAM]

Hi,
You can create the nodeset from the coordinate:
addnodeset!(grid, "my_node", x -> x ≈ Vec((-1,-1)))
Then you can add the DBC to this nodeset:
add!(ch, Dirichlet(:u, getnodeset(grid, "my_node"), Returns(zero(Vec{2}))))
as if it was a faceset.

I'm not aware of a straight forward way to impose affine constraints on the cell nodes based on an arbitrary point. But the point eval handler internals might help with at least identifying the cell efficiently.

[jfbarthelemy]

@termi-official Yes but how would you do that concretely please? With Affine Constraints? But that would mean that I should get the number of the concerned dofs but what I only know is the coordinates or the physical tags of the nodes (although not imported yet). Sorry for questions that may not be relevant, I am new to Ferrite.

[koehlerson]

I think you should stick to nodesets as long as they are supported, which they are currently. I guess you use isoparametric anyhow right now. I think it's quite easy to do. A colleague of mine send me a code snippet some time ago that implements nodesets. If you add some tests to the PR, we can merge it: Ferrite-FEM/FerriteGmsh.jl#26

[termi-official]

No need to be sorry! I think these are valid questions.

Since I also could not find time to fix it in FerriteGmsh.jl I have a preprocessing script which uses addboundaryvertexset! to mark the vertices which I want to constraint (just works on master, but we are trying to make a release as soon as possible). The exact boundary condition to apply is however problem specific. For example, for a rectangular cuboid with corners (0,0,0), (10,2,1) I mark (0,0,0) and fix with Dirichlet $u=(0,0,0)$ on this point. Then 3 outer sides are also constrained to be in plane with Dirichlet conditions by setting $u \cdot n=0$, where $n$ is the normal vector. The script looks like this

    dbcs = ConstraintHandler(dh)
    # Clamp three sides
    dbc = Dirichlet(:d, getfaceset(grid, "left"), (x,t) -> [0.0], [1])
    add!(dbcs, dbc)
    dbc = Dirichlet(:d, getfaceset(grid, "front"), (x,t) -> [0.0], [2])
    add!(dbcs, dbc)
    dbc = Dirichlet(:d, getfaceset(grid, "bottom"), (x,t) -> [0.0], [3])
    add!(dbcs, dbc)
    dbc = Dirichlet(:d, getfaceset(grid, "fixed_corner"), (x,t) -> [0.0, 0.0, 0.0], [1, 2, 3])
    add!(dbcs, dbc)
    close!(dbcs)

If we have curved geometries where we want to apply such conditions things are a bit more tricky. I go with penalty terms to enforce such constraints in this case for now.

Does that help?

[jfbarthelemy]

Thanks! This is clear indeed to kill rigid body motion.

I wrongly thought you were mentioning the use of AffineConstraints, which was not the original question but is still of interest since I always come back to the problem of identifying the global dof numbers associated to given nodes. Imagine I want to impose that the solution (scalar to simplify e.g. in the heat equation problem) is identical at two given nodes defined by their components. If I'm not mistaken this can be done by an AffineConstraint but we need the global dof numbers. From what I read, I see two methods to do so (after building the nodeset with addnodeset! and the components to previously get the node ids):

1. using the snippet provided in #788
2. building a temporary ConstraintHandler and extract prescribed_dofs

Am I wrong?

In the case of curved boundary in a mechanical problem, I would have used a Lagrange multiplier field in order to impose u.n=0 on some boundary surfaces. Nevertheless it does not seem to be possible to add a variable living only on a part of the boundary (on a faceset) since SubDofHandler allowing to handle a multivariable problem can only be built on cellsets and not facesets. Is it the case or did I miss something?

Thanks again.

[KnutAM]

For getting the global dof-numbers, yes: That is unfortunately the way to go for now - but I think this is a feature that would be nice to have a nice API for.

Prescribing the dof values along the normal of curved meshes can be tricky, since, for most meshes, the normal is not well-defined at the nodes. But assuming that you know/approximate the normal, one could get away without Lagrange multipliers by setting up an AffineConstraint between the degrees of freedom at each location on the surface (again, getting these with e.g. 2 above).

If you would like to work with Lagrange multipliers, you don't have to care about the SubDofHandler restrictions, because your additional degrees of freedom wouldn't (for now) even be in the DofHandler if you following Fredrik's suggestion #814 (comment). Even if this would be in from e.g. #596, you would just have to loop over the specific face and integrate/assemble these contributions separately (which I guess you would have to do with a custom solution too).

[jfbarthelemy]

@KnutAM Thank you very much. I understand better now. The impossibility to create variables living on faces (part of boundary or even interface inside the domain) is a limitation for the models I would like to build and that I am already used to build with other libraries (see for instance the case I mention in #815). Maybe this will be available in the future...

[KnutAM]

Yes, that would be nice indeed.
Feel free to open issues as well regarding the functionality you want (at least I look more often at the old open issues than the old discussions). If you also have references like you provided in #815, or even scientific papers, that is really nice for whoever takes on the challenge!

[termi-official]

Having variables on trace spaces should be possible, although it requires some extra work. xref #815 (reply in thread) for how to do it.