Turbine Pressure Displacement Comparison

Coreform IGA
#1

I have acquired a generic turbine to try out a comparison between my Abaqus evaluation and my Coreform _IGA trials (geometry comes from GrabCad). Each of the interior facing surfaces of the turbine has a 5 psi pressure applied to it (there are 3 blades in this design). FEA took about 400k- 600k 2nd order tetrahedral elements to mesh confidently. With the Coreform_IGA flex method I choose ~18k 2nd order elements for a first test.

Typical aluminum properties: Modulus - 10e6 psi, Poisson’s ratio - 0.33
Boundary condition is held in all 3 DOF through the center of the turbine blade.

Upon looking at the results there seems to be a discrepancy between the FEA result and the IGA result. FEA predicts a maximum displacement of ~ 20.3 inches whereas the IGA predicts 1e12 inches.

Perhaps I am missing something in the setup? I am getting an error in my job execution about the linear algebra library no loading. Could this be a/the problem? Json5 file attached for convenience.

Thank you!

Turbine_Pressure.txt.json5 (2.0 KB)

image
image822×716 81.2 KB

image
image864×646 94.7 KB

image
image879×716 93.3 KB

image
image697×197 7.92 KB

#2

Looks like your boundary conditions for the Coreform IGA analysis are only holding it in the x direction:

boundary_condition_definitions:
{
	Hold_BC: {
		type: "fixed",
		variable: "displacement",
		components: [ "x" ],
		function: "constant_1",
		set: "Hold",
		magnitude: 0.0,
		penalty: 1e10,
	},
},

Probably want that to be

components: [ "x", "y", "z" ],
#3

:tired_face: Sigh… I could blame the children, but that wouldn’t be right. Thank you =D

#4

And just to follow up - as I’m sure you’ve seen, the displacement is still a fair bit off (14 vs 20.3), but I thought I’d take a deeper look. As you’ve mentioned the entire envelope domain was meshed with 18k Bezier elements, however, if you open the Turbine_Pressure_envelope.pvd file you will see only the elements that contain part of the physical domain – there’s only 1972 of these elements.

image
image855×788 124 KB

And the physical domain is considerably thinner than the elements:

image
image855×788 142 KB

This is a great example of why we’re working on local U-spline adaptivity. But I’m also quite impressed that this result is as “close” (less than factor of 2) as it is, considering its coarseness (again, there’s really only 2k Bezier elements involved in the calculation).

1 Like
#5

Indeed a very coarse mesh when looked at it from the perspective of ‘working elements’. I look forward to a local adaptivity. I might try a third order approach to this problem. Although that cubit process will be left to happen over night as the uspline operations on this particular design took a long time. I will see what happens and update as I see new results.

#6

You might grab the latest development build of Cubit – We’ve had some performance improvements make their way into the dev builds recently.

1 Like