Issue with rheoInterFoam - dripping doplet does not leave the domain about rheotool

[fppimenta]

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]

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]

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 GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUCOXCFDJITP6BXRBFA2UEDTOF2LDANCNFSM445H75IQ>.

[fppimenta]

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:

• alpha: zeroGradient or linearExtrapolation (will not be locally conservative);
• U: fluxCorrectedVelocity;
• p_rgh: fixedFluxPressure.

They are not very 'physical' but they might work, although I would not recommend to use them in general (e.g. if you are trying to identify the transition from jetting to dripping they can influence, unless the domain is very long).

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]

Re-open if needed.