search

fppimenta / rheoTool

Toolbox to simulate GNF and viscoelastic fluid flows in OpenFOAM®
GNU General Public License v3.0
159 stars 66 forks source link

Issue with rheoInterFoam - dripping doplet does not leave the domain #55

Closed ptorres-uom closed 3 years ago

ptorres-uom commented 3 years ago

Hi Francisco,

I just submitted this to the cfd-online forum, but I'll also leave the question here:

All the files I will be talking about can be found here: https://github.com/ptorres-uom/rheoI...am-drippingBUG And some snapshots here: https://imgur.com/a/tw9x9VD

Essentially I have an axisymmetric simulation of a channel dispensing fluid in an air chamber where I define the boundary conditions for alpha.water and velocity in the air chamber to be essentially zeroGradient in the outlet "walls", and pressure=0 in the same boundaries. I have done this for jets with no issues, but at lower speeds we have dripping instead of jetting and the droplet does not leave the domain smoothly - instead having a small "bounce" and then exploding all over the domain and creating nonsensical results. I have tried setting the lower boundary to alpha.water=0 and this does not solve the problem.

What do you think I might be doing wrong? Or can this be an issue with the package?

Thank you for any help,

Pedro Torres

fppimenta commented 3 years ago

Warning (disclaimer): rheoInterFoam is under development (it can have bugs, inaccurate/unstable methods, etc.)

rheoInterFoam should give equal results to interFoam for Newtonian fluids if SIMPLEC = false. Try your case with interFoam to check if the problem persists. If this is so, then it is not specific to rheoInterFoam.

fppimenta commented 3 years ago

I had a closer look to your case and in fact I suspect it is not specific to rheoInterFoam, i.e. you should get the same behavior with interFoam. This is because the reason is almost certainly the outflow BC. When the drop reaches the outlet, the artificial (wrong) BC assigned to alpha.water (zG ~ 90º contact angle) leads to an artificial surface tension force that makes the patch react like kind of a wall. Then, the droplet spreads and merges with the main jet, giving the numerical garbage you saw. I did not run the case, but I guess that if you restart your simulation from the time-step just before the droplet reaches the outlet and disable surface tension (sigma = 0), then the result should be ok. Also, if your domain was longer in the vertical direction, your droplet could reach the outlet patch with higher speed (due to gravity) and eventually overcome the artificial surface tension force experienced there, i.e. a (much?) longer domain might solve your problem. Assigning a flux-dependent outflow U may also be a fix.

I also saw one or two settings that I would not use, but they are not the reason for the specific behavior being reported, which, as said, comes from the artificial BCs attributed to the outlet in a truncated domain.

ptorres-uom commented 3 years ago

Hello Francisco,

First of all, thank you for your replies! I just finished running a simulation with OpenFOAM’s interFoam and indeed the problem I get is the same – although for some reason the adjustedTimeStep option can be on with interFoam where with rheoInterFoam there was no issue. Do you think I should report it as a bug in OpenFOAM’s website or it is not really a case of it being a bug, but instead just how the solver treats the surfaces in these conditions?

I can tell you that our objective would be to analyse the second droplet being formed, so the solution of deactivating sigma may not be the best one for our objective. I am trying now a fluxCorrectedVelocity to see if it helps, although I’m not very familiar with the BC. We tried a longer domain but we saw that it would have to be much longer to allow for a second drop to form, which perhaps wouldn’t be the ideal solution in terms of computational resources, for several simulations.

I would be very thankful to hear your suggested settings! I did base this case on a rheoInterFoam tutorial – not sure if dieSwell or ImpactingDrop -, so that’s why you see schemes and solvers for tau and theta, as I eventually would like to run this case with VE fluids.

Again, thank you for your informative and quick replies! Any further help would be much appreciated!

Kind regards,

Pedro

PS: Se preferir discutir este assunto em português, estou completamente disponível para o fazer!

From: Francisco Pimenta @.> Sent: 17 May 2021 21:15 To: fppimenta/rheoTool @.> Cc: Jose Pedro Nunes Da Silva Torres @.>; Author @.> Subject: Re: [fppimenta/rheoTool] Issue with rheoInterFoam - dripping doplet does not leave the domain (#55)

I had a closer look to your case and in fact I suspect it is not specific to rheoInterFoam, i.e. you should get the same behavior with interFoam. This is because the reason is almost certainly the outflow BC. When the drop reaches the outlet, the artificial (wrong) BC assigned to alpha.water (zG ~ 90º contact angle) leads to an artificial surface tension force that makes the patch react like kind of a wall. Then, the droplet spreads and merges with the main jet, giving the numerical garbage you saw. I did not run the case, but I guess that if you restart your simulation from the time-step just before the droplet reaches the outlet and disable surface tension (sigma = 0), then the result should be ok. Also, if your domain was longer in the vertical direction, your droplet could reach the outlet patch with higher speed (due to gravity) and eventually overcome the artificial surface tension force experienced there, i.e. a (much?) longer domain might solve your problem. Assigning a flux-dependent outflow U may also be a fix.

I also saw one or two settings that I would not use, but they are not the reason for the specific behavior being reported, which, as said, comes from the artificial BCs attributed to the outlet in a truncated domain.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/fppimenta/rheoTool/issues/55#issuecomment-842600570, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUCOXCFDJITP6BXRBFA2UEDTOF2LDANCNFSM445H75IQ.

fppimenta commented 3 years ago

I just finished running a simulation with OpenFOAM’s interFoam and indeed the problem I get is the same – although for some reason the adjustedTimeStep option can be on with interFoam where with rheoInterFoam there was no issue. Do you think I should report it as a bug in OpenFOAM’s website or it is not really a case of it being a bug, but instead just how the solver treats the surfaces in these conditions?>

I don't understood your comment about adjustedTimeStep. The behavior you observe, although unphysical, cannot be considered a bug. It is just an unwanted side effect. I guess it can be solved with a new BC for alpha, but that would be an 'improvement', not a bug fix.

I can tell you that our objective would be to analyse the second droplet being formed, so the solution of deactivating sigma may not be the best one for our objective. I am trying now a fluxCorrectedVelocity to see if it helps, although I’m not very familiar with the BC. We tried a longer domain but we saw that it would have to be much longer to allow for a second drop to form, which perhaps wouldn’t be the ideal solution in terms of computational resources, for several simulations.>

Disabling the surface tension was just a suggestion to confirm that this force is indeed the responsible for what you see. However, you can still use it locally, i.e. have a longer domain and modify the solver such that for y < tresh -> STforce = 0 (the solution would be locally wrong, but would allow the drop to leave the domain and not interfere with the upstream solution).

You can also try these BCs for the outflow:

I would be very thankful to hear your suggested settings! I did base this case on a rheoInterFoam tutorial – not sure if dieSwell or ImpactingDrop -, so that’s why you see schemes and solvers for tau and theta, as I eventually would like to run this case with VE fluids.>

Major: (1) You should use fixedFluxPressure as the wall BC for pressure for no-slip walls when you have surface tension and/or gravity.
(2) Using this: relaxationFactors { equations { ".*" 1; } }

doesn't ensure that under-relaxation is not being applied, which shouldn't for transient solution. Rather, use this:

relaxationFactors {

} (2.5) rheoInterFoam is safe to use with any GNF model, but might inaccurate/unstable for viscoelastic cases. Use it only if you know what the code is doing.

Minor: (3) for axisymmetric cases: grad(U) leastSquares; (4) div(phirb,alpha) Gauss interfaceCompression; might be more stable than 'Gauss linear' (5) SIMPLEC true; is not well-tested for cases with surface-tension and/or gravity. Using PIMPLE with nCorrectors>1 is safer. (6) your settings are 1st order in time (not necessarily an issue). (7) GAMG for pressure will probably speedup your simulations. (8) I would use a larger and longer domain (with more compression of cells, inclusive at inlet) to ensure a minimal effect from artificial BCs.

fppimenta commented 3 years ago

Re-open if needed.