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 ([email protected]) 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 --------- _______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
