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

FSI3 deal.II-OpenFOAM #105

Closed
wants to merge 9 commits into from
Closed

FSI3 deal.II-OpenFOAM #105

wants to merge 9 commits into from

Conversation

davidscn
Copy link
Member

@davidscn davidscn commented Sep 8, 2020

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.

Copy link
Member

@uekerman uekerman left a 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"/>
Copy link
Member

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:

Suggested change
<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"/>
Copy link
Member

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:

Suggested change
<extrapolation-order value="2"/>
<extrapolation-order value="0"/>

Comment on lines +45 to +60
# 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
Copy link
Member

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?

Comment on lines +56 to +58
<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"/>
Copy link
Member

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"/>
Copy link
Member

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;
Copy link
Member Author

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.

Copy link
Member

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.

@precice-bot
Copy link
Collaborator

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

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.

3 participants