Issue with getfem.Model().add_Nitsche_fictitious_domain_contact_brick() in getfem 5.4.2

Questions and issues
1

Hello everyone,

I’d like to use the method add_Nitsche_fictitious_domain_contact_brick() of the Model class. The problem is that with my version of GetFEM (5.4.2), it returns a “Bad command name” error, which makes me think that this method is not defined in this version of GetFEM.

Could you please confirm whether the issue comes from the method definition itself and not from a misuse on my part? Also, if the method indeed doesn’t work in GetFEM 5.4.2, has the bug been fixed in GetFEM 5.4.4?

Cheers,
Pierre

2

in the code is marked as deprecated

#if (0) // Deprecated brick : uses the old Neumann terms

  /*@SET ind = ('add Nitsche fictitious domain contact brick',

from gf_model_set.cc « src « interface - getfem.git -

What do you need this term for?

3

Thank you for your response.

I needed this brick to solve a contact problem between two deformable bodies using the Nitsche’s method…

4

I see it is still in this outdated example

how about this?

have you tried to adapt this approach to your case?

Edit: I see, this is the paper you are trying to implement

let’s see if @yves.renard can help with this.

5

This brick has been indeed deprecated because it used the old fashion generic assembly. I don’t think it is possible to make it work again easily.

It should be easier to use the existing possibilities of the generic weak form langage together with level set tool. All is available to define a Nitsche’s method for a fictitious domain contact condition (at least for small displacement small strain) : integration method on the level-set, cut-elements …

6

Thank you very much for your two very interesting responses.

@yves.renard As a beginner in contact problems, my main motivation for using this brick was precisely to avoid having to deal directly with the contact detection implementation. However, I found the bricks add_raytracing_transformation and add_projection_transformation, which seem relevant to combine with the Generic Weak Form Language.

@Konstantinos.Poulios The code you kindly provided may not correspond exactly to the specific problem I am addressing, but it is extremely helpful to me and will serve for building my GWFL implementation.

Thank you again for the time and effort you devoted to helping me.

7

Yes, the brick add_raytracing_transformation and add_projection_transformation can be used for defining large displacement / large strain contact conditions (of course it has a relatively high cost, so if you have a small displacement contact, it is more convenient to define by hand the contact pairing).

However, infortunately, the master surface (where the contact is detected) is implicitely a domain boundary on these bricks. So they have to be adapted for a fictitious domain approach if the master surface is defined by a level set inside a fictitious domain.