Skip to content

Enable adaptive time stepping for contact and periodic rve boundary condtions - #2105

Open
m-frey wants to merge 3 commits into
4C-multiphysics:mainfrom
m-frey:dev-adaptive-contact
Open

Enable adaptive time stepping for contact and periodic rve boundary condtions #2105
m-frey wants to merge 3 commits into
4C-multiphysics:mainfrom
m-frey:dev-adaptive-contact

Conversation

@m-frey

@m-frey m-frey commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Description and Context

Description

This PR enables adaptive time stepping for contact and the constraint framework by implementing the missing reset_step_state() functionality.

Changes

  • Implement reset_step_state() for the contact model evaluator.
  • Implement reset_step_state() for the constraint framework.
  • Restore the last converged state before retrying a failed adaptive step.

Related Issues and Pull Requests

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@rjoussen rjoussen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks nice!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test should somehow assert that the timestep is actually reliably and predictably adapted in this simulation. Maybe by writing the reaction forces of a DBC and comparing that to a reference with a non-constant timestep?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, I modified the testcase.

@mayrmt mayrmt Jun 30, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@m-frey Why not check the time step size directly with a result test? That tests the quantity of interest directly (instead of relying on a secondary quantity such as reaction forces).
And that's how we do it for adaptive time stepping based on error estimation, as far as I know.

}

/*----------------------------------------------------------------------*
| Reset contact after failed trial time step |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This documentation belongs into the header file to be processed by doxygen.

SPECIAL: true
QUANTITY: "num_iter_step_15"
VALUE: 3
TOLERANCE: 1e-20

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following result description would check for the time step size directly:

Suggested change
TOLERANCE: 1e-20
TOLERANCE: 1e-20
- STRUCTURE:
SPECIAL: true
QUANTITY: "time_step_size"
VALUE: 0.123456789
TOLERANCE: 1e-14

Note: This is not actual 4C-ready code. It requires to expose the time step size of the final time step within the result test, which has not been done for the solid time integration, yet.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if you could add a test description.

Comment on lines +26 to +27
SOLVER 9:
SOLVER: "UMFPACK"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am not mistaken, this is unused. I would recommend removing all unnecessary inputs. Same e.g. for the IO/MONITOR STRUCTURE DBC condition, you don't need this feature to test the time adaptivity, right?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lauraengelhardt I assume this is my fault: #2105 (comment)

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.

5 participants