Skip to content

Improve some modal feature - #693

Open
WangHu1996 wants to merge 13 commits into
projectchrono:mainfrom
WangHu1996:main
Open

WangHu1996 wants to merge 13 commits into
projectchrono:mainfrom
WangHu1996:main

Conversation

@WangHu1996

Copy link
Copy Markdown

This PR introduces several modifications and improvements to the modal analysis.

1.Internal force accuracy:

  • Added a new method to update internal node state for ChModalAssembly, named UpdateInternalStateWithStaticEquilibrium(too long... but I haven't thought of a shorter suitable function name yet), it solves the deformation of internal nodes by static equilibrium using m_solver_invKIIc. It works like a static correction, but doesn't change modal matrix. This function needs to be called manually now, only before retrieving internal loads. If this method proves stable for a time, Chrono's maintainers may consider merging it to UpdateInternalState.

  • Added a function for euler and timoshenko beam. These functions ensure that the beam's reference rotation follows the modal rotation, and are critical for accurate beam internal force results, especially for axial force of elements near boundary nodes. The core reason is that the current modal assembly is completely linear, and its deformation results are based on the undeformed system matrix, whereas the co-rotational coordinate system of the beam is nonlinear. Therefore, it is necessary to restore the co-rotational coordinate system to the undeformed state that follows the modal. Currently, these functions need to be called manually, which is not an ideal design, but at least does not affect other code, welcome any suggestions from the maintainers.

2.Numerical convergence

  • Added a new floating frame update method. In my test, the default FFR method did not perform well, leading to non-convergent Newton-Raphson iterations. For 10min simulation of 1000 cases, approximately half of the cases failed to converge. The new method makes the FFR follow the movement of its attached frame, similar to the corotational formulation of beams. This method has been mentioned in many papers. Although it does not have a direct theoretical unique solution, it demonstrates good numerical convergence.

3.New modal demo about internal force

  • Added a new demo to demonstrating the internal force extraction method and its accuracy. The model represents a support structure, and gravity load is applied to all components, and an external load is applied to the top node. The calculation results show that the difference between the new internal force extraction method and the co-rotation method is less than 2%.

4.other issues

  • Corrected function names in parsers' CMakeLists.txt to lowercase

Welcome and appreciate any feedback. Best regards,

@rserban
rserban requested a review from dariomangoni March 4, 2026 12:44
@rserban
rserban requested a review from tasora March 4, 2026 12:45
@dariomangoni

Copy link
Copy Markdown
Member

Hi @WangHu1996 thanks for the PR and especially to keep it up to date with main branch. We are glad to have some help from external developers, especially for this complicated module for which very few people can understand the math behind, the code and even fewer could help improving it!
Unfortunately we didn't have much time in the past months to look at this module at all!

We have discussed few points for which you may have some opinion as well:

  1. are you sure that, in UpdateInternalStateWithStaticEquilibrium, by just solving the static equilibrium once the results are properly converged? isn't there the risk that inertia terms of internal nodes are not caught in this way? I'm asking this because you proposed it as something that could be potentially merged into UpdateInternalState
  2. we understand the purpose of just adding a method to ChElementBeamXXX to update the rotation and we agree with you that it's not totally elegant; we might discuss this internally; a minor detail: it's better to avoid any term related to "modal" things in FEA e.g. the argument q_modal is better renamed as q_abs
  3. in the ATTACHED frame case, is there a way (algorithm/heuristic) to set the weight automatically? I might not be immediate to the user its value. Is there a default value?

Please consider that I'm not fully in the topic so some question/doubts might not be so meaningful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants