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] Orchestrator-based multistage #13042

Open
indigocoral opened this issue Jan 27, 2025 · 1 comment
Open

[GeoMechanicsApplication] Orchestrator-based multistage #13042

indigocoral opened this issue Jan 27, 2025 · 1 comment
Labels
Multistage Tag anything related to multistage simulation

Comments

@indigocoral
Copy link
Contributor

indigocoral commented Jan 27, 2025

The pull request for the Orchestrator-based multistage can be found here: Orchestrator-based multistage

Next steps would be to assess how it will affect the products and also adding it into the C++ route.

@indigocoral indigocoral converted this from a draft issue Jan 27, 2025
@indigocoral indigocoral added the Multistage Tag anything related to multistage simulation label Jan 27, 2025
@markelov208
Copy link
Contributor

Two stage test_line_loads is converted to be used with orchestrator sucessfully.
Converting Quay_Wall_4Stage_quadratic_master_slave_interface_with_anchor_reset_displacement met the following issues.

  1. assing_master_slave_constraints_to_neighbours_process.py cannot import numpy, which is not needed. This is solved by removing import numpy statement
  2. After modeling the first stage, Kratos crashes down at saving data. It should be possible to ignore this.
  3. After modeling the second stage, Kratos crashes down at LinearTimoshenkoCurvedBeamElement2D3N::Check as during the multi stage case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Multistage Tag anything related to multistage simulation
Projects
None yet
Development

No branches or pull requests

2 participants