Hi Mikka, if you could tell us what kind of issue you had with nodal contact in 4.3 we can try to fix it.
Regarding the solver, it is true that direct solvers require more RAM but for your problem size, I guess MUMPS should be able to solve it in less than 1G RAM. By the way, you don't need MPI in order to use MUMPS, it also has a sequential version. If your interference is of 5mm, then, yes you should make the shaft diameter 5mm bigger than the bore diameter and getfem should be able to solve it. At least if your mesh size is of 5mm and higher. As an additional comment, for contact between bodies of circular geometry like the ones you have, second order elements would give you much better accuracy. Best regards Kostas On Wed, Aug 20, 2014 at 8:44 AM, Miikka Väntänen <[email protected]> wrote: > Hi Kostas, and thank You for your immidiate reply! > > My current os is CentOS linux, 6.5 release, with x86x64 (also 32 bit > available). At the time being I'm using only one cpu (no mpi atm), which I > suppose ought to be enough as the model is not a huge one and I'm not in a > hurry... > > I had some problems with getfem version 4.3 (with the nodal contact brick, > actually) and changed to 4.2 just because of that. Now that you recommended > the integral contact, I might give it another go. The contact is what I was > actually interested in, so I was planning to fiddle with different contact > bricks anyway once I get the model working with any one of them. > > I tried the superlu solver but ended up with eating up all the memory and > hence crashing the script. I might try mumps, once I get it installed. The > model has 16500 nodes and I'm using linear hexahedron (8-node) elements so > there should be around 50 k dofs. > > I would like to avoid modifying the mesh geometry because I'm planning on > comparing the getfem contact results with results from other fem software, > and changing the mesh would affect the outcome. But if I that's the only > reasonable way to do it, would I just modify the meshes so that they would > overlap by 5 mm and then let the contact brick handle the rest? Would it > force the surfaces into a contact and apply the contact pressure that is > respective to the overlap distance? > > Br. > Miikka > > > > > > 2014-08-19 16:43 GMT+03:00 Konstantinos Poulios <[email protected]>: > > Hi Miikka, >> >> some questions/comments/recommendations: >> >> - Which version of getfem++ do you use, which operating system? >> - Why don't you use >> "add_integral_contact_between_nonmatching_meshes_brick"? It is normally >> superior to nodal contact. >> - Why don't you use a direct solver like superlu or even better mumps? >> How many degrees of freedom do you have? >> - The easiest way of accounting for the interference fit is by modifying >> the meshes so that they incorporate the fit. You can modify the mesh in >> your mesher software or within getfem, e.g. by using the functions pts() >> and set_pts() of the mesh object in python. >> >> Best regards >> Kostas >> >> >> >> On Tue, Aug 19, 2014 at 2:59 PM, Miikka Väntänen < >> [email protected]> wrote: >> >>> Hi all, >>> >>> >>> >>> I’m relatively new to GetFem, but I’ll try to do my best in explaining >>> what I’m struggling with… >>> >>> >>> >>> I’m trying to solve a linear elastic problem that consists of two parts, >>> a shaft and a bush. Between the two parts I use a contact >>> “add_nodal_contact_between_nonmatching_meshes_brick” (in python api). I’m >>> using a linear gmres solver with either ILU or ILUT preconditioning >>> (probably ilut works better with saddle point problems?). There’s also some >>> loading implemented to the shaft, but I reckon that’s irrelevant at this >>> point. >>> >>> >>> >>> The real problem I’m currently facing is with the shrink fit. The actual >>> shaft-bush contact should have a shrink fit with 5 mm radial difference >>> between the two parts. Is there any way in getfem to implement the shrink >>> fit? Should I, for example, use temperature change to shrink/expand the >>> parts in an individual step before calculating the actual static problem? >>> Or should I implement a radial displacement to either of the faces in >>> contact? Is there any way to do any of this? >>> >>> >>> Br. >>> >>> Miikka V. >>> >>> _______________________________________________ >>> Getfem-users mailing list >>> [email protected] >>> https://mail.gna.org/listinfo/getfem-users >>> >>> >> >
_______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
