CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   movingWallVelocity BC lead to unphysical pressure (and then velocity) (http://www.cfd-online.com/Forums/openfoam-solving/122541-movingwallvelocity-bc-lead-unphysical-pressure-then-velocity.html)

mechy August 21, 2013 14:42

movingWallVelocity BC lead to unphysical pressure (and then velocity)
 
Hi all

I want to simulate a deformable plate in a flow


when the U BC of flow is set to movingWallVelocity the pressure and velocity become very huge and solution is diverged. but when it is set to fixed value (which it is incorrect ) the U and p have correct values


any help will be appreciated

wyldckat August 22, 2013 06:10

Greetings Mechy,

My guess is that it depends on how exactly the wall is moving.

I remember that there is one or two tutorials with FSI, where the wall is distorted by the flow... the tutorial "stressAnalysis/icoFsiFoam/flappingConsoleSmall/" is one such example. But it does use the "movingWallVelocity" boundary condition.

I think we need to know more about the case, the mesh and the case configuration, as well as the solver being used.

Best regards,
Bruno

mechy August 24, 2013 04:11

Hi
thanks so much for your answer
I create a new FSI solver which used pimpleFoam for fluid flow
in my test case ,for boundary condition on elastic plate I use movingWallVelocity and my testcase contain a cylinder and a elastic plate behind of cylinder(but not attached to it)

if you need more information please let me know

Best REgards

wyldckat August 24, 2013 17:41

Hi mechy,

In either one of the simulations you've done, does either one actually deform the plate?

Because from the description, either:
  • There is a problem with how the dynamic mesh part is prepared in the file "fluid/constant/dynamicMeshDict".
  • Or there is a problem with the mesh resolution.
  • Or issues in the turbulence model configuration.
  • Or maybe you've missed some detail on the creation of the FSI+pimpleFoam solver.
There are several other possibilities, so I'm not even sure what to ask.


Ah, there is one thing you can try: try using your solver with the tutorial "stressAnalysis/icoFsiFoam/flappingConsoleSmall", to see if the same issue occurs or not.

Best regards,
Bruno

pi06jl6 February 17, 2014 08:29

Did you resolve this issue?

I am using the movingWallVelocity which in parallell mode diverges in the PISO step.

I have parallelized my former code and everything works excellent except when at larger displacements the pressure blows up. I have tried all kind of different solvers, under relaxation and finally isolated the issue to the piso loop.

wyldckat February 17, 2014 09:42

Quick question:
Quote:

Originally Posted by pi06jl6 (Post 475313)
except when at larger displacements the pressure blows up.

Larger displacements? Please elaborate.

pi06jl6 February 17, 2014 10:28

Quote:

Originally Posted by wyldckat (Post 475324)
Quick question:

Larger displacements? Please elaborate.

Long story short: For current coarse mesh, it does not matter what displacement, it always diverges but with larger viscosity the larger the displacement before it takes effect. What i can notice that in parallel mode an oscillatory pressure field whose regions is the decomposed zones and hence implicates boundary issue which can be seen in serial mode but it decays quickly [pressure spikes].

There is plenty of documentation of this issue but I cant figure out how to resolve this.

Hjasak pointed out in a post that reference value should be used whenever no dirichlet condition appears since incompressible solver is invariant to constant shift of pressure. How is this resolved when you work in parallell mode?

This seems be off-topic with regards the thread here but the problem sound "similar", I was thinking : what if the problem is elsewhere? This why i were not precise with my issue and tried fishing. :eek:

wyldckat February 17, 2014 11:02

Hi Johan,

I was hoping you could describe in more detail what exactly you're referring to when you say "displacement", because in OpenFOAM there are several contexts for that word :(

Examples:
  1. Do you mean that the "U" field has got very high values? And that this affects the Courant Number and so on?
  2. Do you mean "displaced flow volume"? In the sense that only after several cubic metre flowing within the domain, does it crash?
  3. Or do you mean that there is fluid-solid interaction, and that the displacement is related to the solid?
  4. Or is there any mesh displacement?
Best regards,
Bruno

pi06jl6 February 17, 2014 11:53

Quote:

Originally Posted by wyldckat (Post 475341)
Hi Johan,

I was hoping you could describe in more detail what exactly you're referring to when you say "displacement", because in OpenFOAM there are several contexts for that word :(

Examples:
  1. Do you mean that the "U" field has got very high values? And that this affects the Courant Number and so on?
  2. Do you mean "displaced flow volume"? In the sense that only after several cubic metre flowing within the domain, does it crash?
  3. Or do you mean that there is fluid-solid interaction, and that the displacement is related to the solid?
  4. Or is there any mesh displacement?
Best regards,
Bruno

Hello Bruno,

Thank you for your reply, i shall try to answer to your questions properly, since you are absolutely right, there is many different context my question can be applied to.

Background

I am currently rewriting my FSI solver [staggered] from serial version [OF 1.4: 2009 version, MSc work] into OF 2.2 version, [parallell mode, Phd work]. As structural solver I am using DEAL.II package. I am reproducing the values from my MSc thesis and everything goes fine for small displacements that is smaller than a cell size.

To your questions:

1. U is "unaffected" until PISO dont converge. It doesnt affect Courant number (the pressure shift)
2. No. I am using mesh moving class fvDynamicMesh, the displacementLaplacian.
3. Yes.
4. See point 3.

I am using the older version of pimpleDyMFoam (icoDyMFoam). Have also found several articles about issues in going from serial to parallell and therefore i am using smooth solvers with precondition recommended as well under-relaxation.

To a certain point in displacement the PISO solver dont converge. I have therefore studied the solution in detail in paraview, the pressure get shifted in EACH iteration until it stops, often when the oscillation of pressure occurs. I therefore disabled the structural solver and replaced it with a predefined motion of the moving patch, with movingWallVelocity and this verified my issue, that the pressure dont converge (shifted) to a point when it start oscillates and leaves the velocity fairly unaffected. [to the same order]. It is at this point during oscillation the structural solver diverges, but with prescribed motion i could follow the process to the point when the PISO crashed.

predefined motion: I took the first iterations for my structural solver and by using ROM I let it run until large deformation. This to verify the traction transfer were correct [distance measure].

wyldckat February 22, 2014 11:20

Hi Johan,

OK, the first detail is that I strongly suggest that if you plan on continuing using OpenFOAM 2.2 till the end of the PhD, then I suggest that you use the last version of the bug fix, namely OpenFOAM 2.2.x: http://www.openfoam.org/archive/2.2.2/download/git.php
I suggest this because a lot of bugs have been fixed since OpenFOAM 2.2.2 was released and I have some suspicions that the problem you're observing are related to a few bugs that have already been fixed.

The second detail is that one of the suggestions that sometimes work is to use the cellLimited... uhm... something something... :rolleyes: gotta go search... OK, were we go:
Here's another helpful post: http://www.cfd-online.com/Forums/ope...tml#post358765 post #6


Beyond this, I suggest that you first try using the standard OpenFOAM solvers, for comparing how they work for this kind of simulation, since you're using your own custom solver.

Good luck! Best regards,
Bruno

pi06jl6 March 19, 2014 11:23

Quote:

Originally Posted by wyldckat (Post 476205)
... suggest that you use the last version of the bug fix, namely OpenFOAM 2.2.x: http://www.openfoam.org/archive/2.2.2/download/git.php ...

Thank you Bruno for your valuable input, i managed to remove the larger part of the oscillation, now only a minor issue remains: Small amplitude high frequency oscillation [often every second time step].

Background, for my fsi problem i am using PISO [taken from pimpleDyMFoam, cannot without modification extend it to pimple so restrict the solver to 1 outercorrection, hence PISO] where I am for given time-stamp under-relaxates the mesh until fixed-point is found. For practical reason I am currently working with 2.1.x version [OF 2.2 on this machine dont comply well with one of my Thirdparty package]. During testing I came to the conclusion that the mesh.update() causes my problem:

In Foam::dynamicMotionSolverFvMesh::update() at the call of Foam::fvMesh::movePoints it is clear that if you repeat the update within same time stamp, the oscillation begins.

Hence: Everything works fine whenever I have prescribed or weak coupling (1 iteration) but as soon I am running this in a loop I obtain pressure oscillations. [clarification, i always start each subiteration with the previous time step velocity field/pressure, the only "free" variable is the deformation.]

The question: why do I obtain these oscillations? I have studied my phi/U/V0/meshPhi and neither of them correlates with oscillation.

[Moving this to separate thread]

wyldckat March 23, 2014 16:51

Quote:

Originally Posted by pi06jl6 (Post 480885)
The question: why do I obtain these oscillations? I have studied my phi/U/V0/meshPhi and neither of them correlates with oscillation.

[Moving this to separate thread]

For future reference, Johan is referring to this thread: http://www.cfd-online.com/Forums/ope...pdate-fsi.html


All times are GMT -4. The time now is 19:14.