Nodal BC (index-based)

[Jfrisch]

Dear FEAP users,

I am trying to simulate a cracktip-problem (standard Griffith crack) and just encountered some issues on my boundary conditions. As you can see in the attached inputfile I am trying to restrict the displacements of the first two dof's at the cracktip (located at the origin (0,0)) and the displacement of the second dof at the rightside edge of the mesh (canceling out rigid body rotations). Unfortunately FEAP has some issues with my node placement without telling me so. If I declare the BC's like in my inputfile a whole region of nodes is matched for the BC at the origin (up to nodes located at a range of ~1e-6 to the origin) as you can see in the attached outputfile. My definition of a tolerance of 1e-9 isn't working/matching.

Is there a way to declare boundary conditions for a specific nodal index (e.g. node with index 1 has to be restricted) or at least declare the tolerance up to which nodes are matched by the CBOUndary statement?

Kind regards,
Jan

[Prof. S. Govindjee]

To declare that node 1 is to be fully restrained you can use the command

Code: [Select]

BOUNdary
1,,1,1


[Jfrisch]

Ah yeah, thanks a lot ... I was thinking of the complex ones and forgot this standard statement. But is there a possibility to adjust the tolerance of CBOU (and as I would guess EBOU as well) statements? because if I want to declare a bunch of nodes with modifying indices the BOUN-statement is quite unhandy.

[FEAP_Admin]

You can set the search tolerance for cbou as

Code: [Select]

cbou
gap,value
node,(x(i),i=1,ndm),(ibc(j),j=1,ndf)
etc.  See appendix A of the user manual.

[Jfrisch]

Thank you, I overread this passage of the cbou-statement - sorry! But unfortunately FEAP is doing some weird calculations I can't quite explain to me and have no clue why FEAP behaves like it is.

I adjusted my inputfile to the attached state and looked up the BC's in the Ofile and they look quite good (or at least as I am intending them to be). If I look up the contour-plots of e.g. u_2 it looks good as well (see attached screenshot). But now the weird things happen. If I am looking at the displacement u_2 alongside the x-axis it should vanish because of the symmetry of the problem. But if you look at the nodes 970 to 988 in the Ofile or at the also attached plot u2.ps you can see that the solution isn't symmetric and oscillates really weird. I tried some given displacements of top and bottom edge and all solutions behave like that. Has anyone an idea what's wrong with my setup or the FEAP-element for this purpose?

[Prof. R.L. Taylor]

I have a couple of comments:

1. Use "opti" to speed the computations.

2. Your coordinates are only accurate to about 5 digits which might explain some of the lack of symmetry.  If you use COOR ALL option for input of nodal data, feap allows full precision in the data.

3. 2-d elements in Cartesian coordinates have properties independent of the size of the element, only its shape and aspect ratio matter.  Thus, no matter how many times you refine the last refinement has the same gradient at the tip as earlier ones would have.  Thus, stress usually will always oscillate around the tip due to the high gradient.

4. If you read some old literature (say by T. Ingrafia) you should find a discussion on this.   One proposal was to use
quadratic order elements and place the midside nodes around the tip at the 'quarter point' of each side -- this introduces a singularity there, but not the fully correct one.

5. Another option is to build in the crack-tip intensity by adding its displacement function to the normal FE one.  Much like XFEM does.

[Jfrisch]

I have a couple of comments:

1. Use "opti" to speed the computations.

Thanks for this advice, I will give it a try. But even if I use my own material routine with five dof's the calculations aren't that long, but mor speed is always good!

2. Your coordinates are only accurate to about 5 digits which might explain some of the lack of symmetry.  If you use COOR ALL option for input of nodal data, feap allows full precision in the data.

Ah ok, I didn't knew that. I will adjust my inputfile accordingly.

3. 2-d elements in Cartesian coordinates have properties independent of the size of the element, only its shape and aspect ratio matter.  Thus, no matter how many times you refine the last refinement has the same gradient at the tip as earlier ones would have.  Thus, stress usually will always oscillate around the tip due to the high gradient.

But I do see a refinement in the solution if I refine my mesh (not at the cracktip, but in the outer region of my problem). I am trying to rebuild the mesh of a former colleague to do analogous calculations and he had used this refinement.

4. If you read some old literature (say by T. Ingrafia) you should find a discussion on this.   One proposal was to use
quadratic order elements and place the midside nodes around the tip at the 'quarter point' of each side -- this introduces a singularity there, but not the fully correct one.

I am using quadratic order elements but no quarterpoint-elements yet. I have read about them but want to try to reach an acceptable accuracy without editing my code again to introduce these quarterpoints. But this concept is for a better approcimation at the cracktip and the oscilations I am concerned about take place far away from the cracktip somewhere in "nowhere".

5. Another option is to build in the crack-tip intensity by adding its displacement function to the normal FE one.  Much like XFEM does.

I don't know XFEM yet and don't have the time right now to learn and use a whole new theory, so it has to work for my code (modulo quarterpoints if I can't avoid them).

[Prof. R.L. Taylor]

I tried to look at the last refinement around the crack tip and it seemed to be with triangles -- is this correct.

Also, one other comment is the use of 8-node elements may be an issue.  Can you try using 9-node ones as they have better properties - especially with non-rectangular shape.

[Jfrisch]

I tried to look at the last refinement around the crack tip and it seemed to be with triangles -- is this correct.

I am using degenerated quadrangles (a side is collapsed into a point: the cracktip), because according to the literature I read that should give more stable result than using triangles.

Also, one other comment is the use of 8-node elements may be an issue.  Can you try using 9-node ones as they have better properties - especially with non-rectangular shape.

In the PhD-Thesis I am using as a reference the former colleague used 8-node-elements (at least he wrote that he did so). It should therefore suffice to use 8-node-elements but I can give it a try with 9-node-ones.