Dear Pablo, The idea with the augmentation parameter is that the result should be rather independent once you get a converged solution. If you have penetration though, this cannot be considered as a converged solution. Another possible option for overcoming convergence issues is to reduce the load/time step size.
If you could just send us a picture of your mesh, maybe we could comment on that. Best regards Kostas On Wed, Apr 3, 2019 at 10:17 AM Pablo Arturo Alvarez Corrales < [email protected]> wrote: > Dear Konstantinos, > > Thank you for your quick response. As for the note in the documentation, I > found it in this page > http://getfem.org/userdoc/model_contact_friction_large_sliding.html > <http://getfem.org/userdoc/model_contact_friction_large_sliding.html?highlight=large>. > It reads "Sorry, for the moment the brick is not working". However, now > that I double check it, it actually appears to be related to the nodal > contact brick with projection, I may have thought it to be related somehow > to large sliding bricks in general at some point. > > Regarding the problem with contacts, I did use the example you provided as > a baseline for my code. I tried new values for the augmentation parameter > as you recommended and now I am obtaining better results. The solution > appears to be highly sensible to this parameter since I get either > penetration or unexpected deformation after relatively small changes. > > I'm still getting lots of these warning messages while solving > > Level 1 Warning in getfem_contact_and_friction_common.cc, line 47: > Inverted element !-0.20579 > > Is there a way of getting rid of it or is this normal behavior? > > As a related question, is there a way for specifying the normals of the > master surface? My meshes are highly irregular and I think it may also be > a source of problems. > > Thank you very much for your help. > > Regards, > > Pablo > > > > > On Tue, Apr 2, 2019 at 3:04 PM Konstantinos Poulios < > [email protected]> wrote: > >> Dear Pablo, >> >> First of all I want to ask you about where you have read the statement >> that the brick is not functional. This must be some old leftover that we >> have to remove. The brick is in quite reasonable state and has been used to >> produced many different results. >> >> The main trick for using the brick is the choice of the augmentation >> parameter and the release distance. The augmentation parameter should be in >> the order of the modulus of elasticity of the materials in contact (you can >> try values from 1000 times smaller to 1000 times larger). Your choice about >> the release distance sounds reasonable, maybe to be on the safe side you >> could increase it to 10 times the element size instead of 3 time the >> element size. >> >> Have you checked the corresponding included demo >> >> http://git.savannah.nongnu.org/gitweb/?p=getfem.git;a=blob;f=interface/tests/python/demo_large_sliding_contact.py >> ? >> >> BR >> Kostas >> >> On Tue, Apr 2, 2019 at 10:46 AM Pablo Arturo Alvarez Corrales < >> [email protected]> wrote: >> >>> Dear getfem users, >>> >>> I've been trying to implement an elastostatic problem with contacts >>> using the python wrapper for GetFEM v5.3. At first, I tried the contact >>> bricks with non-matching meshes without any issues. However, since my >>> problem considers large deformation, this approximation to contacts is not >>> satisfying. >>> >>> I then tried the large sliding large deformation contact brick as >>> following: >>> >>> md.add_filtered_fem_variable('lambda_n', mfu, CONTACT) >>> contact_bid = >>> md.add_integral_large_sliding_contact_brick_raytracing('r', release_dist) >>> md.add_slave_contact_boundary_to_large_sliding_contact_brick(contact_bid, >>> mim, CONTACT, 'u', 'lambda_n') >>> md.add_master_contact_boundary_to_large_sliding_contact_brick(contact_bid, >>> mim_c, CONTACT_C, 'u_c') >>> >>> where u, u_c, CONTACT and CONTACT_C represent the displacements and >>> contact boundaries for the slave and master meshes respectively. >>> >>> Even though I get no errors at solving, the result appears to be >>> incorrect. After deformation, penetration between slave and master meshes >>> is significant, and changing the release distance for the raytracing >>> transformation does not seem to help (here I used three times the mean >>> element size). Also, I get a bunch of these in the console: >>> >>> Level 1 Warning in getfem_contact_and_friction_common.cc, line 47: >>> Inverted element !-0.20579 >>> >>> I did read the note in the documentation saying that the brick is not >>> working. However, it does not specify for which version so I wanted to be >>> sure. >>> >>> Is this brick working properly and if not, is there any version of >>> GetFEM in the repository that has one working version ? >>> >>> Thank you in advance, >>> >>> Pablo >>> >>> PD. Keep up the good work, this is an amazing library ! >>> >>
