-
-
Notifications
You must be signed in to change notification settings - Fork 116
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
FSI3 deal.II-OpenFOAM #105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The results look already pretty good. Really going until 19s is normally not necessary. So, what you do there is pretty standard.
However, the coupling iterations are indeed too high.
Please try first to add the missing data field in the acceleration. This should have a huge effect. Maybe also on the lift and drag. Afterwards please try the other suggestions one by one.
<time-windows-reused value="0"/> | ||
</acceleration:IQN-IMVJ--> | ||
<acceleration:IQN-ILS> | ||
<data name="Displacement" mesh="Solid_mesh"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A parallel-implicit coupling scheme needs both data vectors in the acceleration:
<data name="Displacement" mesh="Solid_mesh"/> | |
<data name="Displacement" mesh="Solid_mesh"/> | |
<data name="Stress" mesh="Fluid-Mesh-Centers"/> |
<relative-convergence-measure limit="5e-5" data="Stress" mesh="Fluid-Mesh-Centers"/> | ||
<!--relative-convergence-measure limit="5e-5" data="Displacement" mesh="Solid_mesh"/--> | ||
<absolute-convergence-measure limit="1e-7" data="Displacement" mesh="Solid_mesh"/> | ||
<extrapolation-order value="2"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extrapolation does not always help. Try:
<extrapolation-order value="2"/> | |
<extrapolation-order value="0"/> |
# Linear solver residual (scaled by residual norm) | ||
set Residual = 1e-6 | ||
|
||
# Linear solver: CG or Direct | ||
set Solver type = Direct | ||
end | ||
|
||
subsection Nonlinear solver | ||
# Number of Newton-Raphson iterations allowed | ||
set Max iterations Newton-Raphson = 10 | ||
|
||
# Displacement error tolerance | ||
set Tolerance displacement = 1.0e-6 | ||
|
||
# Force residual tolerance | ||
set Tolerance force = 1.0e-9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The nonlinear tolerances are for absolute residuals, right? And the linear for a relative residual.
The linear residual should be tighter (by one or two orders of magnitude) than the nonlinear one. This is easier to specify if all use the same kind. I recommend to use only relative residuals. And why do we need the force residual?
<relative-convergence-measure limit="5e-5" data="Stress" mesh="Fluid-Mesh-Centers"/> | ||
<!--relative-convergence-measure limit="5e-5" data="Displacement" mesh="Solid_mesh"/--> | ||
<absolute-convergence-measure limit="1e-7" data="Displacement" mesh="Solid_mesh"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those appear too tight compared to the solvers' internal criteria. The internal ones should be 1 to 2 orders of magnitude tighter. I recommend to use only relative criteria.
<acceleration:IQN-ILS> | ||
<data name="Displacement" mesh="Solid_mesh"/> | ||
<preconditioner type="residual-sum"/> | ||
<filter type="QR2" limit="1.2e-2"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filter appears to be too tight. Too many columns get deleted. But this could be due to the tight convergence criteria and the missing data field in the acceleration.
|
||
gradSchemes | ||
{ | ||
default cellLimited Gauss linear 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to track this:
Removing here the cellLimited
keyword results in similar amplitudes, but the result is phase shifted. Thus, it would be indeed a good idea to perform the simulation until 20 sec to see, where the oscillations are located in time as compared to the reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, the phase shift is rarely analyzed in publications using the FSI3. Normally, people only look at the frequency and the amplitude. Depends on the ramp and the initial conditions (e.g. precomputed flow field), of course. So, yes we can look at this, but should not have the highest priority.
This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there: https://precice.discourse.group/t/force-post-processing-with-the-force-functionobject/349/1 |
Results and configuration of the deal.II-OpenFOAM FSI3 tutorial. Reference data has been taken from the original paper of Hron and Turek. I used groovyBC (swak4foam) in order to apply the correct parabolic velocity profile and ramp it via consine function.
I uploaded in this PR also some result data such as the watchpoint, the forces, and the Solid-iteration.log file. The simulation was performed in serial and until a final time of 10 sec. The overall computational time was around two days. Since the reference comprises only qualitative data above 19 sec. the results of our simulation have been shifted by approximately 15 sec. in order to compare magnitude and frequency. I think the precice configuration could still be improved (cf. precice-Solid-iterations)
We see that x- and y-displacement results are in a good agreement, magnitude of lift and drag are still slightly different.

It would be interesting to use this setup with other structure codes in order to compare the results.