Dear Kostas: Thank you very much for confirming and fixing the bug. I will test that.
In addition, could you kindly specify what might be the root of my convergence problem? Is it because that definitions of potential contact areas are too large or small or wrong assignment of master/slave faces? Best regards, Hojae On December 29, 2016 2:12:55 AM EST, Konstantinos Poulios <[email protected]> wrote: >Dear Hojae, > >that was a bug in GetFEM++ that I have just fixed in this commit >http://svn.gna.org/viewcvs/getfem/trunk/getfem/src/getfem_contact_and_friction_nodal.cc?r1=5496&r2=5495&pathrev=5496 > >Thank you for testing this old contact brick. However I would recommend >you >to use the integral contact bricks which are in general superior and >more >heavily tested. The convergence problems that you are experiencing are >not >some intrinsic problem of the integral contact brick but most probably >due >to the way you are setting up your model. > >Best regards >Kostas > > >On Thu, Dec 29, 2016 at 3:25 AM, Dr. Hojae Yi <[email protected]> wrote: > >> Dear Yves and Kostas: >> >> Thank you so much for spending your time on my code. I removed the >> 'lambda_n' definition and ran the code. It runs through without error >on >> that line but now I get an error of 'dimensions mismatch' at >> 'md.solve('max_res', 1E-5, 'max_iter', 100, 'very_noisy' , 'lsearch', >> 'simplest', 'alpha min', 0.8)'. >> >> By the way, the code runs fine when I use >'add_integral_contact_between_nonmatching_meshes_brick(mim1, >> 'u1', 'u2', 'lambda_n', 'r', 'f_coeff', CONTACT_BOUND_WHEEL, >> CONTACT_BOUND_FND)' instead of using >'add_nodal_contact_between_nonmatching_meshes_brick'. >> In this case, I define 'lambda_n' with 'md.add_multiplier('lambda_n', >mfu1, >> 'u1', mim1, CONTACT_BOUND_WHEEL)'. It runs without an error but it >does not >> converge. >> >> I will dig in further to find out where I made a mistake. >> >> Best regards, >> >> Hojae >> >> On 12/28/2016 04:43 PM, Konstantinos Poulios wrote: >> >> Dear Yves and Hojae, >> >> The error "The given name for the multiplier is already reserved in >the >> model" occurs because the brick requires to define the multiplier >> internally. In Hojae's script however, 'lambda_n' is already defined >> earlier. The definition >> md.add_variable('lambda_n', nbc_wheel) ## Number of contact >boundary >> dof for normal contact` >> should be removed. >> >> Best regards >> Kostas >> >> On Wed, Dec 28, 2016 at 3:16 PM, Yves Renard ><[email protected]> >> wrote: >> >>> >>> Dear Hojae, >>> >>> I think the right call should be >>> >>> md.add_nodal_contact_between_nonmatching_meshes_brick(mim1, mim2, >'u1', >>> 'u2', 'lambda_n', 'r', CONTACT_BOUND_WHEEL, CONTACT_BOUND_FND, True, >False, >>> 1) >>> >>> (If you indicate a 'lambda_t' then the friction coefficient is >needed. >>> However, it does not work. The given error is "The given name for >the >>> multiplier is already reserved in the model". Kostas, do you have an >>> explanation for this ? >>> >>> Best regards, >>> >>> Yves. >>> >>> >>> ----- Original Message ----- >>> From: "Hojae Yi" <[email protected]> >>> To: "logari81" < <[email protected]>[email protected]> >>> Cc: "yves renard" <[email protected]>, "getfem-users" < >>> [email protected]> >>> Sent: Saturday, December 24, 2016 3:34:44 PM >>> Subject: Re: [Getfem-users] nodal contact problem >>> >>> Hello Kostas: >>> >>> Thank you for the reply. >>> >>> I tried 'CONTACT_BOUND_WHEEL' AND 'CONTACT_BOUND_FND' before. When I >>> did, I got the error of "Argument 10 must be a string" error with >the >>> region id's. It was same when I added friction coefficient data name >as >>> ''md.add_nodal_contact_between_nonmatching_meshes_brick(mim1, mim2, >>> 'u1', 'u2', 'lambda_n', 'lambda_t', 'r', 'f_coeff', >CONTACT_BOUND_WHEEL, >>> CONTACT_BOUND_FND, True, False, 1)". >>> >>> I tried mesh1.pid_in_regions(CONTACT_BOUND_WHEEL) since I found that >>> those arguments are defined as 'const std::vector<size_type> &rg1' >in >>> the C++ code. >>> >>> I feel like I am missing some obvious mistake I made somewhere in my >code. >>> >>> Kind regards, >>> >>> Hojae >>> >>> >>> >>> >>> On 12/24/2016 3:47 AM, Konstantinos Poulios wrote: >>> > Dear Hojae >>> > >>> > From what I am seeing, you should replace >>> > mesh1.pid_in_regions(CONTACT_BOUND_WHEEL) with >CONTACT_BOUND_WHEEL. >>> > >>> > CONTACT_BOUND_WHEEL is the region id. The same applies to >>> > CONTACT_BOUND_FND. >>> > >>> > Best regards >>> > Kostas >>> > >>> > On Fri, Dec 23, 2016 at 9:56 PM, Hojae Yi < ><[email protected]>[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hello Yves, >>> > >>> > Than you very much for the reply. I thought and tried that rg1 >and >>> > rg2 should be boundary numbers as you explained (and in the >>> > documents). Just in case, I am attaching my code with a >comment to >>> > highlight the line issues an error. It is line number 200. Let >me >>> > know if there is anything unclear about this revised code. >>> > >>> > Best regards, >>> > >>> > Hojae >>> > >>> > >>> > >>> > On 12/23/2016 2:43 PM, Yves Renard wrote: >>> > >>> > >>> > Dear Hojae, >>> > >>> > The best is that you send the lines of your code that are >not >>> > working. >>> > rg1 and rg2 are boundary numbers so that they should be >some >>> > integers. >>> > >>> > Yves. >>> > >>> > ----- Original Message ----- >>> > From: "Hojae Yi" < <[email protected]>[email protected] <mailto: >>> [email protected]>> >>> > To: "getfem-users" < ><[email protected]>[email protected] >>> > <mailto:[email protected]>> >>> > Sent: Thursday, December 22, 2016 8:25:34 PM >>> > Subject: [Getfem-users] nodal contact problem >>> > >>> > Hello, >>> > >>> > First of all, thank you so much for a great FEA package! >>> > >>> > I am currently using GetFEM 5.1 using Python. I have been >>> > toying with >>> > provided 'demo_wheel_contact.py' and trying to apply >>> > add_nodal_contact_between_nonmatching_meshes_brick using >two >>> > contact >>> > surfaces. However, when I run, it complains that rg1 (and >rg2) >>> > should be >>> > a string. Python Interface reference explains that rg1 and >rg2 >>> as >>> > integers while User Document explains them as vectors. >>> > >>> > Can someone kindly point me where I can find further >>> > information on how >>> > these rg1 and rg2 should be defined? Let me know if any >>> > further details >>> > are needed. >>> > >>> > Thank you very much! >>> > >>> > Hojae >>> > >>> > _______________________________________________ >>> > Getfem-users mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://mail.gna.org/listinfo/getfem-users >>> > <https://mail.gna.org/listinfo/getfem-users> >>> > >>> > >>> > >>> > _______________________________________________ >>> > Getfem-users mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://mail.gna.org/listinfo/getfem-users >>> > <https://mail.gna.org/listinfo/getfem-users> >>> > >>> > >>> >> >> >>
_______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
