Adding element offsets to shell and beam elements

[timryanb]

• Also separating TACSBeamTransform from TACSBeamElement file

[A-CGray]

@timryanb Is this going to require changes to all of the beam and shell constitutive models to account for the thickness offset?

[timryanb]

@A-CGray, no, only for models where the bending axis/plane doesn't align with the nodes. Any constitutive class that doesn't use offsets should continue to work the same

[timryanb]

Hey @gjkennedy, I went through some of the beam code and was trying to understand what the correct ordering for the mass moments array returned by evalMassMoments in the TACSBeamConstitutive class. Based on the snippet of code in the element class here and here, I believe the correct ordering should be:

moments 
= [int[rho*dA], int[rho*y*dA], int[rho*z*dA], int[rho*y^2*dA], int[rho*z^2*dA], int[rho*y*z*dA]] 
= [rho*A, rho*cy*A,  rho*cz*A,  rho*Izz,  rho*Iyy,  rho*Iyz]

But, the snippet of code in the constitutive class here
seems to imply that the correct order is:

moments = [rho*A,  rho*cy*A,  rho*cz*A,  rho*Iyy,  rho*Izz,  rho*Iyz] (Iyy and Izz are swapped)

I'm thinking that my first interpretation is correct and constitutive class has a typo in it, but want to run it by you.

[A-CGray]

@A-CGray, no, only for models where the bending axis/plane doesn't align with the nodes. Any constitutive class that doesn't use offsets should continue to work the same

Right, I get that. What I meant is, isn't the math for computing the change in stiffness/inertia due to the offset general enough that it could be implemented in the parent beam and shell classes rather than in every child constitutive model that we want to support a thickness offset?

[timryanb]

@A-CGray, no, only for models where the bending axis/plane doesn't align with the nodes. Any constitutive class that doesn't use offsets should continue to work the same

Right, I get that. What I meant is, isn't the math for computing the change in stiffness/inertia due to the offset general enough that it could be implemented in the parent beam and shell classes rather than in every child constitutive model that we want to support a thickness offset?

You could move the logic for offsetting completely to the elements. However often times these offsets are tied to design variables (the offset scales with thickness for a shell for instance). Moving these procedures into the element class would require adding more steps to the jacobian and its dv sens that would probably be more work than is worth

[gjkennedy]

Hey @gjkennedy, I went through some of the beam code and was trying to understand what the correct ordering for the mass moments array returned by evalMassMoments in the TACSBeamConstitutive class. Based on the snippet of code in the element class here and here, I believe the correct ordering should be:

moments 
= [int[rho*dA], int[rho*y*dA], int[rho*z*dA], int[rho*y^2*dA], int[rho*z^2*dA], int[rho*y*z*dA]] 
= [rho*A, rho*cy*A,  rho*cz*A,  rho*Izz,  rho*Iyy,  rho*Iyz]

But, the snippet of code in the constitutive class here seems to imply that the correct order is:

moments = [rho*A,  rho*cy*A,  rho*cz*A,  rho*Iyy,  rho*Izz,  rho*Iyz] (Iyy and Izz are swapped)

I'm thinking that my first interpretation is correct and constitutive class has a typo in it, but want to run it by you.

@timryanb I think your interpretation is right - it's a typo in the comment.

[timryanb]

Hey @gjkennedy, I went through some of the beam code and was trying to understand what the correct ordering for the mass moments array returned by evalMassMoments in the TACSBeamConstitutive class. Based on the snippet of code in the element class here and here, I believe the correct ordering should be:

moments 
= [int[rho*dA], int[rho*y*dA], int[rho*z*dA], int[rho*y^2*dA], int[rho*z^2*dA], int[rho*y*z*dA]] 
= [rho*A, rho*cy*A,  rho*cz*A,  rho*Izz,  rho*Iyy,  rho*Iyz]

But, the snippet of code in the constitutive class here seems to imply that the correct order is:

moments = [rho*A,  rho*cy*A,  rho*cz*A,  rho*Iyy,  rho*Izz,  rho*Iyz] (Iyy and Izz are swapped)

I'm thinking that my first interpretation is correct and constitutive class has a typo in it, but want to run it by you.

@timryanb I think your interpretation is right - it's a typo in the comment.

Great, I'll make an update to fix the inconsistency