[Marc Batlle]

Hi Foamers,

Congratulations for your isoAdvector addition Mr. Roenby, which looks it is working really good in water waves environment, and furthermore, congrats on the adaptation for deformable meshes of this interface method.


Problem:
I am facing a problem these days when running the setAlphaField tool, which allows higher precision when defining the water depths, on OpenFOAM versions 1812 and 1906 but which were not appearing on version 1806. The issue appears when adding the "waveAlpha" boundary condition for alpha.water.

- I added the case from the tutorial (of-v1812) streamFunction with the Allrun switched to run setAlphaField instead of setFields

Question:
I am also really interested in the addition of isoAdvector in compressible two phase solvers as compressibleInterFoam. I will be testing the library from HenningScheufler these days, but I expected the realise on the official 1906 version. Did you found any issue in it you could prevent me from?

Thanks again for your dedication and contributions,

Marc

[roenby]

Hi Marc

setAlphaField issue:

setAlphaField complains about the boundary waveAlpha because it is not aware of it because the libwaveModels.so was not included in the Make/options file of the setAlphaField application (should be in the EXE_LIBS list). Good thing is you can simply add the following line to your case controlDict to make the setAlpahField aware of the waveAlpha BC:

libs ( "libwaveModels.so" );

VoFLibrary of Henning Scheufler:
This has now been added as a community contribution:
https://develop.openfoam.com/Communi...on-vof-library
(you might need to log in and/or request access to the project)
It will now be further tested and will hopefully make it into v1912.

Best regards,
Johan

[navidamin]

Hi Professor Roenby,
Recently I have been struggling with spurrious currents problem for fluid-gas interfaces, which is produced by the surface tension force term in the momentum equation. I was advised that isoAdvector scheme would resolve the random fluctations that occure at the interface.


So I took the sloshingTank2D case from ESIOpenFOAM tutorials, put gravity and movement of the tank to zero and set a value for surface tension. Of course no spurrious currents are produced for the original case, but when I scaled the geometry to the factor of 0.001(2cmX2cm), the spurrious current on the interface appeared as you can see in the attached image.

So, I was wondering if you think there is anything wrong with my setup? And if not, is there any solutions to this problem?

[Arghavani]

Hi everyone,
Does anyone work on the rotation of the slotted disk with IsoAdvector? if so, in which case of interisofoam can I find?

[roenby]

Hi @Arghavani


Test case can be found here:

https://develop.openfoam.com/Develop...idBodyRotation


Youtube video:
https://youtu.be/p03yDzcdv6c


As always: Help the community by filing a bug report if you find something not working properly.


Cheers,
Johan

[Arghavani]

Thanks a lot, Johan for your reply,

I will check as soon as possible.
I did Young's method for the slotted disk via Matlab, and the volume fraction breaks down so quickly. Do you know that this case in Isoadvector can support the interface capturing and reconstructing the interface?

kind regards,
Arghavan

[roenby]

Yes it can. The linked video gives visual evidence. For alpha bounding and volume conservation details, run the case and look in the log file where this info is displayed

[Arghavani]

Thanks, Johan,

yes, you are right. I am going to do that.

Best,
Arghavan

[Arghavani]

Hey Johan,
I ran already the simulation as you told. But I got the error : ./Allrun: 7: ./Allrun: restore0Dir: not found
I download Isoadvector last weak in my tutorial folder but still is not working and in each log files I have these errors : ./Allrun: 93: ./Allrun: interIsoFoam: not found
FOAM FATAL IO ERROR:
keyword centre is undefined in dictionary "/home/izadshenas/notchedDiscInSolidBodyRotation/system/setAlphaFieldDict"

file: /home/izadshenas/notchedDiscInSolidBodyRotation/system/setAlphaFieldDict from line 18 to line 22.

From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const
in file db/dictionary/dictionary.C at line 566.

FOAM exiting


Do you think that these error s are related to the installation?



kind regards,
Arghavan

[Arghavani]

Hi Johan,

for some other projects, I have OpenFoam of5x on my computer at work and until now I didn't need the Isoadvector and InterIsoFoam solvers but now I want to do another project which needs theses solvers but I am not sure that the of5x version of OpenFoam has InterisoFoam solver or not?

kind regards,
Arghavan

[roenby]

IsoAdvector from github.com/isoAdvector works with OpenFOAM-5.x.

The isoAdvector solver in that repo is called interFlow - not interIsoFoam. If you have the Foundation version of OpenFOAM loaded (the one from openfoam.org) that would explain the error "./Allrun: 93: ./Allrun: interIsoFoam: not found" in your previous post.

interIsoFoam is the name of the corresponding solver using isoAdvector in the ESI-OpenCFD version of OpenFOAM (openfoam.com). That OpenFOAM version has a restore0Dir function to restore the 0 directory from the 0.orig directory. The Foundation version of OpenFOAM (openfoam.org) does not have that. Hence the first error in your previous post: "./Allrun: 7: ./Allrun: restore0Dir: not found".

Originally Posted by Arghavani

Hi Johan,

for some other projects, I have OpenFoam of5x on my computer at work and until now I didn't need the Isoadvector and InterIsoFoam solvers but now I want to do another project which needs theses solvers but I am not sure that the of5x version of OpenFoam has InterisoFoam solver or not?

kind regards,
Arghavan

[wdx_cfd]

Hi Johan,

I am wondering whether this beautiful scheme can be used with OversetMesh embedded in OFv1906 or v1912?

Anyway, thank you for your work.

Best regards,

WDX

[roenby]

Hi WDX


In the official OF release overset with isoAdvector is not currently supported. However, in principle, if you have an overset mesh solver working with MULES, it should be a simple matter to replace MULES with isoAdvector. I am not aware of any attempts to implement this. It has been on my todo list for a while, but so far it hasn't been prioritized.



In other words: The floor is open for you to do it :-)


Cheers,
Johan

[wdx_cfd]

Originally Posted by roenby

Hi WDX


In the official OF release overset with isoAdvector is not currently supported. However, in principle, if you have an overset mesh solver working with MULES, it should be a simple matter to replace MULES with isoAdvector. I am not aware of any attempts to implement this. It has been on my todo list for a while, but so far it hasn't been prioritized.



In other words: The floor is open for you to do it :-)


Cheers,
Johan

Thank you Johan, I will try it on OF1906 or 1912 recently .

[wdx_cfd]

Originally Posted by roenby

Hi WDX


In the official OF release overset with isoAdvector is not currently supported. However, in principle, if you have an overset mesh solver working with MULES, it should be a simple matter to replace MULES with isoAdvector. I am not aware of any attempts to implement this. It has been on my todo list for a while, but so far it hasn't been prioritized.



In other words: The floor is open for you to do it :-)


Cheers,
Johan

OK，I have done it on OFv1906. As you said, it was not difficult. The case (floatingbody) is running now. Further valiadation will be conducted, i think

Again, thank you for your reply and work! I think I will keep programming based on your work.

Best regards,

WDX

[wdx_cfd]

Originally Posted by roenby

Hi WDX


In the official OF release overset with isoAdvector is not currently supported. However, in principle, if you have an overset mesh solver working with MULES, it should be a simple matter to replace MULES with isoAdvector. I am not aware of any attempts to implement this. It has been on my todo list for a while, but so far it hasn't been prioritized.



In other words: The floor is open for you to do it :-)


Cheers,
Johan

Hi Johan,

I also face the problem of air bubbles when using IsoAdvector with oversetMesh. The bubbles appear beneath the water level where the alpha should always be 1. I found that using a larger surfCellTol can alleviate this problem. For example, the result by using 1e-6 is better than that of using 1e-8. I think this is reasonable because using a smaller value makes the algorithm more sensitive to the cells whoes alpha are not 1.

Currently, I introduce a relaxation to mildly adjust those cells of air bubbles, and it works well. But I still don't know where these bubbles come from. Could you give me some advices? I use OF1906 and interFlow to simulate the case with the name of 'floating object'.

Thank you
WDX

[roenby]

Hi WDX


This is why isoAdvector can produce air bubbles:

It roughly solves something like this equation to update the volume fraction field in the i'th cell:

alpha_i(t+dt) = alpha_i(t) - 1/V_i*sum(alpha_f*phi_f*dt)

where V_i is the volume of cell i, alpha_f is some measure of the time and area averaged "area fraction" on face f, and phi_f is the flux on face f. The sum is over all cell i's faces (and here for convenience we assume the face normals to point out of the cell, in OpenFOAM speak, the cell "owns" all its faces).

As you say, in the bulk of the fluid, alpha_i and alpha_f are supposed to be 1, and they generally are, when we start our simulation.
Then for bulk fluid cells the above equation becomes:

alpha_i(t+dt) = 1 - dt/V_i*sum(phi_f)

Theoretically sum(phi_f) = 0, which is just the face flux version of div(U) = 0. But the PISO algorithm only ensures this down to the tolerance you set for p_rgh. So if you set this tolerance to 1e-6 we can have sum(phi_f) = epsilon > 0 in which case the updated alpha value becomes

alpha_i(t+dt) = 1 - epsilon < 1.

Suppose this results in alpha_i(t+dt) = 1 - 2e-6 and you have set the surfCellTol to 1e-6 in fvSolution, so that cells with 1e-6 < alpha < 1-1e-6 are regarded as interface cells by isoAdvector. Then obviously in the next time step isoAdvector will try to treat the cell as a surface cell, even though it obviously shouldn't. This is what causes spurious air bubbles appearing in the bulk of the fluid. The solution (or at least a workaround) is to ensure that surfCellTol is larger than p_rgh tolerance in fvSolution by 1-2 orders of magnitude. In an upcoming update of isoAdvector, we will incorporate that isoAdvector only works on existing interface cells or their point neighbours which will eliminate the problem more rigorously.

Best,
Johan

[wdx_cfd]

Originally Posted by roenby

Hi WDX


This is why isoAdvector can produce air bubbles:

It roughly solves something like this equation to update the volume fraction field in the i'th cell:

alpha_i(t+dt) = alpha_i(t) - 1/V_i*sum(alpha_f*phi_f*dt)

where V_i is the volume of cell i, alpha_f is some measure of the time and area averaged "area fraction" on face f, and phi_f is the flux on face f. The sum is over all cell i's faces (and here for convenience we assume the face normals to point out of the cell, in OpenFOAM speak, the cell "owns" all its faces).

As you say, in the bulk of the fluid, alpha_i and alpha_f are supposed to be 1, and they generally are, when we start our simulation.
Then for bulk fluid cells the above equation becomes:

alpha_i(t+dt) = 1 - dt/V_i*sum(phi_f)

Theoretically sum(phi_f) = 0, which is just the face flux version of div(U) = 0. But the PISO algorithm only ensures this down to the tolerance you set for p_rgh. So if you set this tolerance to 1e-6 we can have sum(phi_f) = epsilon > 0 in which case the updated alpha value becomes

alpha_i(t+dt) = 1 - epsilon < 1.

Suppose this results in alpha_i(t+dt) = 1 - 2e-6 and you have set the surfCellTol to 1e-6 in fvSolution, so that cells with 1e-6 < alpha < 1-1e-6 are regarded as interface cells by isoAdvector. Then obviously in the next time step isoAdvector will try to treat the cell as a surface cell, even though it obviously shouldn't. This is what causes spurious air bubbles appearing in the bulk of the fluid. The solution (or at least a workaround) is to ensure that surfCellTol is larger than p_rgh tolerance in fvSolution by 1-2 orders of magnitude. In an upcoming update of isoAdvector, we will incorporate that isoAdvector only works on existing interface cells or their point neighbours which will eliminate the problem more rigorously.

Best,
Johan

Hi Johan,

Thank you for your detailed reply. It is quite useful. But I am still wondering if this spurious air bubble problem is partly related to mesh motion?

By the way, maybe a mass source will be contained in my future work. The velocity near the source region is not divergence free, and thus I think I still need a relaxation to adjust the unwanted alpha value....

Again, thank you very much!

WDX

[roenby]

Regarding source terms for isoAdvector, see this reply.

[Fauster]

Dear Johan Roenby,

Isoadvector is very very cool ! Awesome job. I was wondering if there is a member function available in the code to obtain the position of the free surface ? For example as a surfaceScalarField or a volScalarField ?

Best regards,