Re: [Getfem-users] API improvements for contact bricks

[Yves Renard]

Dear Kostas,

I agree with all your suggestions. Thank you for them.
On the filename "getfem_Coulomb_friction", of cours it would be renamed in 
"getfem_contact_and_friction" or something like that. By the way, the main 
interest of Tresca friction is to provide a fixed point for the Coulomb 
friction case (except for a very small number of modelisation, as far as I 
know).

It would be interesting of course to treat the non-matching meshes case for 
the continuous versions. Indeed, it would be a first step to treat large 
defromation contact, which is also my long term goal. The advantage of these 
continuous versions is that it is not necessary to explicit in what sense the 
multiplier (and/or the gap) is non-positive. I explicited the formulations in 
the documentation (except for the last one)
 My lonh term goal would be to find a implementation of large deformation 
contact where it is not necessary to  differentiate a slave and a master 
surface (for instance to treat automatically some auto-contacts).
An important point of course is to obtain a method which is sufficiently robust.

Best Regards,

Yves.


On vendredi 14 octobre 2011, you wrote:
> Hi Yves,
> 
> I have seen that you have implemented the continuous contact bricks and
> I would like to extend them to non-matching meshes. I would also like to
> give another try to implementing a large displacements version.
> 
> But before doing any real work on this maybe it would make sense to
> clean up some inconsistencies in the API:
> 
> 1. The filename "getfem_Coulomb_friction" indicates that there will be
> no tresca version in this file. Is that correct?
> 
> 2. As it is now, we have the following function names:
> 
> add_basic_contact_brick
> add_basic_contact_with_friction_brick
> 
> add_Hughes_stab_basic_contact_brick
> add_Hughes_stab_friction_contact_brick
> 
> add_contact_with_rigid_obstacle_brick
> add_contact_with_friction_with_rigid_obstacle_brick
> 
> add_continuous_contact_with_rigid_obstacle_brick
> add_continuous_contact_with_friction_with_rigid_obstacle_brick
> 
> add_nonmatching_meshes_contact_brick
> add_nonmatching_meshes_contact_with_friction_brick
> 
> it would be logical to rename "add_Hughes_stab_friction_contact_brick"
> to "add_Hughes_stab_with_friction_contact_brick"
> 
> 3. In the new continuous contact with friction bricks there is only one
> multiplier variable for both the normal and tangential directions. It
> would make sense to call it "multname_lambda" instead of "multname_n".
Yes, of course. There is only one multiplier because the normal can change and 
thus, a normal component on a part of the domain can be a tengential one on 
another part.

> Moreover, is it possible to use one single variable "multname_lambda"
> instead of "multname_n" and "multname_t" also for the non-continuous
> bricks?
It would be possible, of course. I don't know if it is necesseray to change 
it. The problem is for the basic brick, the normal field is not known.


> 
> Best regards
> 
> Kostas


-- 

  Yves Renard (address@hidden)       tel : (33) 04.72.43.87.08
  Pole de Mathematiques, INSA-Lyon             fax : (33) 04.72.43.85.29
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE
  http://math.univ-lyon1.fr/~renard

---------