Use overlapping schwarz for oscillator tutorial#391
Conversation
|
Decision after discussion with @uekerman: Similar to #381 this modification of the case should go into
I will also modify #388 to work with the overlapping schwarz-version of the tutorial, because this is also the case I'm investigating for my thesis. |
Isn't the "overlapping" part easier to understand from the top-view? So, |
Probably yes. I think "Schwarz" is also a broader term and might refer to completely different setups. With "Overlap" the main feature is clear. |
Yeah. Felt like a déjà vu to me :) Then all good? Can you ✔️ ? |
uekerman
left a comment
uekerman
left a comment
There was a problem hiding this comment.
Name and README is good to go IMO (besides last edits below).
I did not run the case.
|
|
||
|  | ||
|
|
||
| Note that this case applies an overlapping Schwarz-type coupling method and not (like most other tutorials in this repository) a Dirichlet-Neumann coupling. This results in a symmetric setup of the solvers. We will refer to the solver computing the trajectory of $m_1$ as `Mass-Left` and to the solver computing the trajectory of $m_2$ as `Mass-Right`. For more information, please refer to [1]. |
There was a problem hiding this comment.
| Note that this case applies an overlapping Schwarz-type coupling method and not (like most other tutorials in this repository) a Dirichlet-Neumann coupling. This results in a symmetric setup of the solvers. We will refer to the solver computing the trajectory of $m_1$ as `Mass-Left` and to the solver computing the trajectory of $m_2$ as `Mass-Right`. For more information, please refer to [1]. | |
| Note that this case applies an overlapping Schwarz-type coupling method and not (like most other tutorials in this repository) a Dirichlet-Neumann coupling. This results in a symmetric setup of the solvers. We refer to the solver computing the trajectory of $m_1$ as `Mass-Left` and to the solver computing the trajectory of $m_2$ as `Mass-Right`. |
There is no [1] on this page and the paper does also not discuss this case. We could maybe refer to BR's thesis here later.
There was a problem hiding this comment.
Not a concrete suggestion, but a brainstorming idea: In principle, you can even use references to the literature cards we render on the website. They will not render correctly outside the repository, but we could later find a solution for that.
MakisH
left a comment
MakisH
left a comment
There was a problem hiding this comment.
I have not tried to run it, but it looks clean. 👍
I would just really like that, since we already converged in different occasions on why it makes sense that we stick to the standard tutorial structure, that we try to enforce it.
Co-authored-by: Gerasimos Chourdakis <[email protected]>
MakisH
left a comment
MakisH
left a comment
There was a problem hiding this comment.
The new structure makes looks nice! It is fine to not have dedicated config files for such a simple solver. The command-line arguments in the run.sh scripts are enough of a configuration.
I have ran the tutorial and I get the following errors:
- Left:
0.01,0.02597530032202172 - Right:
0.01,0.025058100518940307
3 participants
Exchange displacement instead of forces. This leads to identical results, but makes the modelling a bit clearer and fits better into the domain decomposition framework.
What we did before:
What we do now:
Inside of each participant, we still translate the displacement of the other participant to a force, because this fits better into the generalized alpha framework. This, however, is an implementation detail of the solver and does not really interfere with the coupling scheme.