Periodicity of finite element model

[Hemanth_T_N]

Hi Dr. Louise and everyone,

I am analyzing 2D biaxial 30 degree braided textile composites. For my analysis the Representative Volume Element (RVE) needs to meet the following two criteria (Lx, Ly are the dimension of RVE in X and Y)
1) The number of yarn elements at apposite faces like X=0 & X=Lx (also Y=0 and Y=Ly) should be same.
2) The yarn elements at apposite faces should take up identical positions so that if RVE is repeated in its planar directions, I get the actual structure of braided composite textile.
These conditions allow me to carry out periodic analysis. I have attached the script file which I used to generate model for my braided textile composite. I exported it as abaqus input file (as a voxel file). However, my results were not periodic. Upon investigation I found that the number of yarn elements are not same as detailed below
1) Number of yarn_0 elements at X=0 is 263 while there are 262 elements at x=1. In addition
there are 257 elements of yarn_0 at Y=0 and 252 elements at Y=1.
2) Number of yarn_1 elements at X=0 is 238 while there are 240 elements at x=1. In addition
there are 262 elements of yarn_1 at Y=0 and 252 elements at Y=1.

am I missing something in my script file. Can someone help me rectify this?

Appreciate your feedback.

Regards,
-Hemanth T N

[louisepb]

Hi Hemanth,

As far as I can tell your script looks ok and the textile looks as though it's periodic.

I'm out of the office today so don't have access to Abaqus to be able to check the number of elements on the yarn surfaces in the exported file. I'll take a look at it tomorrow. Could you tell me how many voxels you were exporting so that I know I'm replicating your problem.

Best wishes,
Louise

[Hemanth_T_N]

Hello Dr. Louise,

I have used 125000 voxels (50 voxels along each direction of X, Y, Z).


Best Regards,
Hemanth T N

[louisepb]

Hi Hemanth,

I've taken a look at this and consulted with one of my colleagues who is an expert on unit cells etc.

The reason that the yarn meshes are different at either end of the unit cell is because of the angle of the yarn across the boundary. Whether a voxel is assigned to the yarn or the matrix is based on which of these the centre point of the voxel is located in. Because the yarn is at an angle across the boundary this changes in the layers at either end of the unit cell (the centre point being half a voxel length inside the domain at either end). If you put these models back-to-back however the yarn will be periodic and the voxel mesh will correctly represent the yarn. Clearly the resolution of the mesh will affect how abruptly the yarn mesh changes from one layer to the next.

In terms of periodicity, my colleague assures me that this is correct as the tesselation of the elements matches at the two end surfaces of the domain.

It's not clear exactly what analysis you're doing so it may be that you require the same number of yarn elements on opposite surfaces. If this is the case then I think that you would need to generate the voxels in such a way that the matrix/yarn assignments were made based on points actually on the boundary.

Hope that helps,
Louise

[Hemanth_T_N]

Hi Dr. Louise,

Yes, that information was very insightful.
I was a little concerned as there were some minor differences in stress results across the edges of apposite faces even after imposing periodic boundary conditions through MPC equations in Abaqus. The figures and plotted graphs of stress results across the two edges are in the attached document.

Is there a quick fix that I can try to generate voxels so that yarn/matrix assignments are made based on the points actually on the boundary?

Thanks for your continued help. Have a great weekend.

Best Regards,
Hemanth T N

[louisepb]

Hi Hemanth,

I can't really think of a 'quick fix' that you could do. You could write a script to do the equivalent of CRectangularVoxelMesh::OutputNodes in Python but with the starting points offset by half a voxel. The point information would then coincide with the boundaries but you'd have to use this information to rewrite the nodes section of the inp file and the orientations. The domain would be slightly offset but still periodic. The elements should be the same and the equations, faces etc still the same. You'd need to adjust the yarn and matrix element sets accordingly.

If you've built the C++ code then you would just write an alternative version of the Output Nodes function and then everything else would work.

Best wishes,
Louise