Principal stress directions for fatigue

Hi to all,

I have 2 doubts regarding principal stress directions in post-processing evaluation:

• I don’t understand why the magnitude of the vector given by the 3 component
VECT_1_X, VECT_1_Y , VECT_1_Z seems to be not equal to one

and

-the vectors seem to be not orthogonal, ie the scalar product is not equal to zero

here is an example

Points:0 Points:1 Points:2 Principal stress:0 Principal stress:1 Principal stress:2 Principal stress:3 Principal stress:4 Principal stress:5 Principal stress:6 Principal stress:7 Principal stress:8 Principal stress:9 Principal stress:10 Principal stress:11
-0.04619 -0.1972 -0.0015713 -1.24E+05 -12731 1.57E+05 0.115 -0.085874 -0.13017 0.95672 0.21066 0.15838 -0.0020531 0.30154 -0.20803

I suppose
VECT_1_X, is Principal stress:3…VECT_3_Z is Principal stress:11

from this example results are:
Vect 1 ,2, 3 magnitude: 0.193761639 0.992358311 0.366342828
scalar products xy,xz,yz 0.214192475 0.242509159 0.028610383

what is it wrong?

I am working on a python script for paraview in order to calculate the principal stress vectorial difference for fatigue following the method of principal stress difference

and I appreciate a lot who would like to help me in this task.

many thanks

Gp

Hey there, can you also include the link to your project as well?

Cheers!

Hi @gvolante and @tsite,

Thanks for reporting this bug, I have been facing exactly the same problem in my last simulations for some days and now I am doubting on the validity of the results since the non-orthogonality of the principal stress vectors. Did you find any solution?

In my case I created the vector fields for the principal stress vectors in paraview just to check if they were orthogonal, as they should, and although many of them seem to be orthogonal (I didn’t check it with the dot products) many of them are visually completely non-orthogonal.

In my case, when I export the results to a CSV from paraview the vector coordinates I get are even more messy as it can be seen in the table below. The first two values are the principal stresses along with the Principal stress_2, but in between two more columns are found…

Principal stress_0 Principal stress_1 Principal stress_10 Principal stress_11 Principal stress_2 Principal stress_3 Principal stress_4 Principal stress_5 Principal stress_6 Principal stress_7 Principal stress_8 Principal stress_9
-2255680 -1196040 -0,0154126 0,308762 -687783 0,099797 0,206791 0,370522 0,216537 0,622758 0,196603 0,729076

It looks even more ridiculous when seen in Paraview. All columns are named with the same name and the second and third columns are kind of joined together in only one column.

Why principal vectors are not normalized? Why are they not orthogonal?

I would apreciate some help with this issue.

Many thanks in advance!

Thanks @alex_roque and @gvolante for bringing this up.

I am going to forward this issue to the dev team so they investigate what is happening.

Thanks @ggiraldof for forwarding this issue since it is an extrange behavior that needs to be analyzed in detail.

1 Like

Hi @ggiraldof and the rest of the staff involved in this issue,

I have been researching a little bit about my case that can be found here and some information regarding itself can be found in this other topic.

I have represented the absolute value of the dot products of the principal vectors in paraview so as to find the points where orthogonality is not reached. Representation is by means of spherical 3D Glyphs , scaled by module, so the bigger (and redder) the spheres are the further we are from orthogonality. Below some screenshots are presented.

v1·v2

v2·v3

v3·v1

Furthermore, I summed all the results and got surprised to see that some points had a value close to 3, which means that all 3 principal vectors are close to be parallel. Something completelly unexpected…

v1·v2+v2·v3+v3·v1

I also investigated the histograms of the dot product values since in the previous images only the boundary values were represented. Only the histogram for v1·v2 is shown since the other two look very similar.

Historgram of v1·v2

Histrogram with the sum of dot products

Finally, as a crosscheck, I extracted the tetrahedrons containing values greater that 2.25 of the sum of the 3 dot products and represented the principal vectors as glyphs. Tets are colored with the sum of the dot products so as to ease the search for the most critical points.

Below a couple of critical points (orange to red values) are highlighted to demonstrate that the 3 principal vectors are far from being orthogonal.

I hope that the information shared here can be helpful to illustrate the problem and to find a solution to it. If I can do something to help, just let me know.

Best,

Alex

1 Like

Hey Alex,

Thank you so much for such a wonderful research on the issue!

It will surely be very useful for the dev team.

1 Like

Hey Alex, have you tried performing a mesh independence analysis and see if the issue is related to discretization error?

Hi @ggiraldof ,

Thanks for asking. No, I haven’t and it could be a good starting point but, first, let me give you some information regarding the mesh. The mesh has been created in Salome and imported to Simscale, not without problems, as it is stated in this other thread. The mesh is made of tets, except for the region of contact between both solids, where I defined the interface to be made of squares to make it even more structured. Actually, both parts of the interface have been meshed with the same parameters so that the contact interface is “quasi-conformal” (if this word exists… ). This point is important as I mention in the other thread which link I already posted above. This gives an interface made up of pyramids instead of tets, not sure if it can be causing the problem (or part of it), but investigating the mesh I found something interesting regarding the pyramids that I will mention later.

Now let’s go to see the mesh in detail. Below some pictures will tell you more about the mesh than I can write!

The mesh

Detail of the mesh of the lens in the area of contact

Mesh information

I think the histogram says that the mesh is of reasonable quality. However, to have a closer look into it I grouped all the volumes with an Aspect Ratio 3D greater than 2 and the histogram of it looks quite interesting… Let’s see it!

Cutting the group up to an Aspect Ratio 3D of 2.64 one can see the following.

Only ALL the pyramids and some degenerated tets are showing up and it makes me wonder if 2.64 is the lower bound for the aspect ratio of a pyramid, is it?

Now that you know better my mesh, what changes to the mesh you recomend me in order to perform the mesh sensitivity analysis?

Just to give you more information, in a previous simulation with exactly the same geometry but meshed in the standard mesher (unstructured mesh, especially in the contact interface) I got non-orthogonal principal vectors aswell. Right now I am analyzing the previous simulation in the same manner I did with the mesh built in Salome, but, so far it seems that the location of the non-orthogonal principal vectors is alike. I will give you more information once I finish the analysis.

Thanks.

Best,

Alex

1 Like

Here come the histograms of the standard mesher results. The mesh had a similar size than the external mesh meshed in Salome (around 67k nodes)

The locations of the non-orthogonal principal vectors follow the same pattern: the most of them are near (or at) the contact surfaces and some in the lens body in degenerated tets. The mesh can be found here (Mesh 2_v11).

1 Like

Hey Alex, and thanks again for the detailed analysis, good stuff.

I think that you should perform a mesh refinement analysis, by refining the mesh around the areas with the non orthogonal principal vectors, and checking the orthogonality again. This is to know if this has an impact.

Please perform such study and let me know of the results.

I have been trying to recompute the refined mesh in Salome following the same steps I did previously but now it doesn’t allow me to import it. It gives an “internar error” message when importing…