The problem regarding the distinction between positive openings and negative openings

General
1

hi, I’m currently using this example to account for compressive and tensile forces in the cohesive model Cohesive zone modeling restricted to an interface — Computational Mechanics Numerical Tours with FEniCSx.
Consider a very simple case consisting of two blocks. The upper block is numbered 2, and the lower block is numbered 1. A vertical displacement is applied to block 2.

image
image462×470 1.92 KB

In the previous code, the following line was added to calculate the normal relative displacement.

def normal_opening(v, n):
    opening = ufl.max_value(0.0,ufl.dot(v,n))

However, I’ve noticed an issue: the direction of the normal vector seems to be incorrect. The calculation of the normal displacement is as follows: (u2(+)-u1(-))*facetnormal(-). When I make changes to the positive directions of these three quantities, I’ve found the following problems
when using:
(u2(+)-u1(-))*facetnormal(-)
(u2(-)-u1(-))*facetnormal(-)
the results seem to be right
but when:
(u2(+)-u1(-))*facetnormal(+)
(u2(-)-u1(-))*facetnormal(+)
The normal direction is constantly in a damaged state, which indicates that it is in a compression process, suggesting that there is an issue with the direction of the normal vector. The load - displacement curves are shown in the following two figures. This seems to contradict the way the positive and negative directions are written in this paper.

image
image586×447 17.7 KB

image
image606×446 16.1 KB

2

Have you seen that in the mentioned demo: “Moreover, we also consistently switch the orientation of the facets so that cells in subdomain 1 correspond to the "+" side of the interface and cells in subdomain 2 to the "-" side.” which might be the source of your issue

3

Oh, I got that.But by what means can I ensure this, or is it already determined by Fenicsx itself?

4

It is enforced in the function interface_int_entities but you can modify it if you want.