1D Stiffness Matrix Indefinite in Some Cases

[JohnDN90]

It seems that the stiffness matrix for 1D structural elements is becoming indefinite in some cases. Similar to the issue we saw with the 1D mass matrix.

The specific case I found is a 1D elment with Euler-Bernoulli bending and the shear coefficient kappa set to zero to disable transverse shear stiffness. So this element should only have extension stiffness, bending stiffness, and coupled extension-bending stiffness. Some test results are below:

Offset_y	Offset_z	Element Stiffness Matrix
0.0	0.0	Positive Semi-definite
hy/2	0.0	Indefinite
-hy/2	0.0	Indefinite
0	hz/2	Positive Semi-definite
0	-hz/2	Positive Semi-definite

I'm still trying to track the issue down.

Edit: Remove an incorrect statement.

[manavbhatia]

Euler-Bernoulli beam does not use kappa since the governing equation does not account for transverse shear.

I will look into the parametric combinations you described.

[JohnDN90]

I noticed that the offset_z is not having any effect on the stiffness matrix

Correction: Offset_z DOES have an effect on the stiffness matrix.

I've edited my first post to remove the incorrect statement. So I'm not sure where the stiffness matrix is becoming negative definite due to offsets.

[manavbhatia]

I figured out the issues with this. There had been a set of changes that I had made sometime ago that led to relatively incompatible changes in beam internal residual and jacobian definition. These did not show up so far since I was not using offsets, except in a few cases with y-offsets.

Now that this has come to the forefront, I am making some changes to enforce consistency, with some minimal changes in element section property as well. I will keep you posted on what changes, so that you can track those back into your section card updates.

[manavbhatia]

I pushed a branch with changes in the #75. Could you please verify if this fixes the issues you were seeing.

[JohnDN90]

Yes, I was picking up this issue in a unit test. I'll apply your changes and run the tests again to see if the issue is resolved.

[manavbhatia]

I tried to verify the use of the updated stiffness terms in a nonlinear analysis, modal analysis and sensitivity analysis, which seemed to work fine. However, a standardized testing procedure of Jacobian and sensitivity quantities would be of considerable value here. Once the catch/ctest framework is established, it would be good to start adding some tests for verification of element Jacobians and sensitivity terms.

[JohnDN90]

Agreed.

There's already some tests for for element Jacobians in the add_catch2_tests branch which we haven't merged into master yet, still working towards that.

[JohnDN90]

I pushed a branch with changes in the #75. Could you please verify if this fixes the issues you were seeing.

I just cherry-picked your commit into my branch with the unit tests for the 1D Jacobian. It looks like the Jacobian is now showing the appropriate eigenvalue characteristics, 12 eigenvalues, 6 very close to zero, and 6 positive ones.

It looks like your changes to the 1D element also took care of Issue #43 as well, is that correct?

[manavbhatia]

I am not sure what/why the cherry-picking involves. :-) All changes in #75 should only be relevant to providing the bug-fix.

Yes, this should also fix the issues with #43.

[JohnDN90]

Cherry-picking is a quick way of moving one commit from one branch into another, thus avoiding having to merge an entire branch into another.

Anyway, the tests are passing with these changes, so the bugs I encountered are fixed. Thank you for looking into this.

[manavbhatia]

I understand. You should also be able to create a patch from one branch and apply it to another: for example

[jdeaton]

Closed by PR #75

[jdeaton]

I didn't see all this discussion earlier, but just wanted to follow-up saying that I was able to get these changes (as well as picking up a couple others) from v2 into master in #78. I did the merge locally of v2 into a new branch off of master then opened a PR. I think this effectively did the same thing as a patch.