Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GeoMechanicsApplication] Add a class for running a time loop #11620

Closed
avdg81 opened this issue Sep 27, 2023 · 1 comment · Fixed by #11677
Closed

[GeoMechanicsApplication] Add a class for running a time loop #11620

avdg81 opened this issue Sep 27, 2023 · 1 comment · Fixed by #11677
Assignees
Labels
Feature GeoMechanics Issues related to the GeoMechanicsApplication

Comments

@avdg81
Copy link
Contributor

avdg81 commented Sep 27, 2023

As a developer, I would like to be able to run a full time loop given a solver strategy and a time incrementor.

Background

The Kratos team at Deltares would like to be able to carry out a time loop in custom workflows. Being able to execute a time loop is one of those components. The time loop itself must be independent of the selected solver strategy and time incrementor. In that way, we can create various compositions that satisfy our requirements of the workflow.

Acceptance criteria

Given a time loop executor, a time incrementor that generates four constant time increments, a solver strategy that always converges, and no start state
When the developer requests to run the time loop (by calling member function TimeLoopExecutor::Run(...))
Then it must return a list of five step states (start state + four increments in time), each one indicating that it converged.

Given a time loop executor, a time incrementor that generates four constant time increments, a solver strategy that always converges, and a start state
When the developer requests to run the time loop (by calling member function TimeLoopExecutor::Run(...))
Then it must return a list of four step states (one for each increment in time), each one indicating that it converged.

@avdg81 avdg81 added Feature GeoMechanics Issues related to the GeoMechanicsApplication labels Sep 27, 2023
@rfaasse
Copy link
Contributor

rfaasse commented Sep 28, 2023

@avdg81 @WPK4FEM It's very clear what this issue should result in, thanks for taking the time to split it all out. Similarly to the other issue #11617, I think the acceptance criteria should be generalized.

Next to that I think it would be nice to define here what would happen if the solver strategy doesn't converge (either immediately or after some steps).

@WPK4FEM WPK4FEM linked a pull request Oct 12, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature GeoMechanics Issues related to the GeoMechanicsApplication
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants