[stardust111]

Originally Posted by dzordz

I had the same issue with this compilation. For some reason linking in Make/options file to this twoPhaseMixtureThermo folder fails. What solved my problem (probably not smoothest solution) is adding an additional line in options -I/.....path to twoPhaseMixtureThermo folder.... \


Hope it helps.

Hi dzord,
thank you very much for your reply. I tried this too, this can pass the compilation procedure. But then there will be another error when using the new kva_compressibleInterFoam.

keyword water is undefined in dictionary "/home/xxxx/constant/thermophysicalProperties"

Since I used a variable surface tension of water, in the thermophysicalProperties it writes:

phases (water air);
pMin 10000;
sigma
{
type liquidProperties;
phase water;
}


but when I used the standard compressibleInterFoam solver, that error didn't occur. Did you meet this too?

[dzordz]

Hi!
I had not tried this with temperature dependent surface tension via liquid properties, but I had the same problem. The thing is the code has implemented a density weighing and requires the density input for both phases rho1_ and rho2_ in thermophysicalProperties. For example add:

water
{
transportModel Newtonian;
rho [1 -3 0 0 0 0 0] 1000;
}
air
{
transportModel Newtonian;
rho [1 -3 0 0 0 0 0] 1;
}


The issue for me was, that I have highly compressible air phase which density varies throughout my domain. So I turned the weighing off and it principle should work normally. So maybe add a dummy input in there
Cheers.

[stardust111]

Originally Posted by dzordz

Hi!
I had not tried this with temperature dependent surface tension via liquid properties, but I had the same problem. The thing is the code has implemented a density weighing and requires the density input for both phases rho1_ and rho2_ in thermophysicalProperties. For example add:

water
{
transportModel Newtonian;
rho [1 -3 0 0 0 0 0] 1000;
}
air
{
transportModel Newtonian;
rho [1 -3 0 0 0 0 0] 1;
}


The issue for me was, that I have highly compressible air phase which density varies throughout my domain. So I turned the weighing off and it principle should work normally. So maybe add a dummy input in there
Cheers.

Thanks again. I added the densities, but then got some other errors .
I think I should also turn off the DensidyWeighting, as the density is also not constant in my case. Could you please give me a clue about how to turn it off?

BEST


Create time

Create mesh for time = 0


PIMPLE: Operating solver in PISO mode

Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Constructing twoPhaseMixtureThermo

Selecting surfaceTensionModel liquidProperties
Selecting curvatureModel vofsmooth
Selecting surfaceTensionModel CSF(densityWeighted=0)
Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}

Selecting thermodynamics package
{
specie specie;
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
energy sensibleInternalEnergy;
equationOfState perfectGas;
}

Reading thermophysical properties

#0 Foam::error:rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 ? at ??:?
#4 __libc_start_main in "/lib64/libc.so.6"
#5 ? at /home/abuild/rpmbuild/BUILD/glibc-2.22/csu/../sysdeps/x86_64/start.S:121
Segmentation fault (core dumped)

[dzordz]

I suggest that to see how it is done you look at the transportProperties that are included in the library compilation file you downloaded.

Nevertheless if there is no densityWeighted entry, the default is set to no, so you should be working with it turned off. Now I do not know why this error occurs for you. Maybe try compiling it yourself.

[stardust111]

Originally Posted by dzordz

I suggest that to see how it is done you look at the transportProperties that are included in the library compilation file you downloaded.

Nevertheless if there is no densityWeighted entry, the default is set to no, so you should be working with it turned off. Now I do not know why this error occurs for you.

Thanks. I will try to find it out.

[floquation]

I'm sorry, I haven't checked this forum for a while.

densityWeighted
densityWeighted is indeed off by default, but regardless of whether it is on or not, rho1_ and rho2_ are read during construction of the class.
I did implement this feature per some paper from Brackbill... But evidently this only makes sense if rho is constant. (And even if it is, I always leave it off, because I found it to negatively impact my cases.)

You could indeed add the lines @dzordz said to transportProperties, and then my code wills imply read them, but not use them. It's ugly, but it solves the problem...
However, my code is just an extension to OpenFOAM itself, and I do not know whether adding those values to transportProperties will in turn affect compressibleInterFoam aversely...

Instead, I propose hacking my code (which is, of course, also dirty, but it's at least guaranteedly safe).
Disclaimer: I did not try these changes, and it's been a while since I did this, so I might have made a syntax error:
In "interfaceProperties.C", rho1_ is read at line 135.
Replace the lookup statement:

transportPropertiesDict_.subDict( wordList(transportPropertiesDict_.lookup("phases"))[0] )

by

1

. (Here I assume that the dimensionedField constructor can also take a constant value, rather than a dictionary. I hope it can.)

Secondly, on line 235 it is also read. Replace:

transportPropertiesDict_.subDict( wordList(transportPropertiesDict_.lookup("phases"))[0] ).lookup("rho") >> rho1_; // KVA

by

rho1_ = 1;

. That should fix the values just in my code to one, which doesn't do anything as they aren't used if densityWeighted=off, while you leave the rest of OpenFOAM unaffect because your transportProperties file is now "clean".

Finally, do the same for rho2_.
Final-finally, recompile.

twoPhaseMixtureThermo

Originally Posted by dzordz

I had the same issue with this compilation. For some reason linking in Make/options file to this twoPhaseMixtureThermo folder fails. What solved my problem (probably not smoothest solution) is adding an additional line in options -I/.....path to twoPhaseMixtureThermo folder.... \

It looks like twoPhaseMixtureThermo resides in a subfolder of the solver... But my automated getSolverMake.sh did not take that into account.
Without hacking my automated script, manually adding the absolute path to "twoPhaseMixtureThermo" is indeed the most elegant solution you can achieve.

of40-dev branch
For those of you who hadn't seen it, the GitHub has multiple branches: of40, of50 and of40-dev: my development branch with much more features.
In the meantime, I have ceased development as the focus of my work has changed considerably... But there are many useful additions in there, amongst which:

• weighted smoothing (e.g., weighted to smooth in the interface-normal direction)
• piece-wise continuous calculation of the interface's "Dirac function"

The relevant papers are referenced in the .H files of each operator, being primarily:
Raeini, Ali Q., Martin J. Blunt, and Branko Bijeljic.
"Modelling two-phase flow in porous media at the pore scale using
the volume-of-fluid method."
Journal of Computational Physics 231, no. 17 (2012): 5653-5668

Perhaps those features can still be of use for someone.

[Enrico Segre]

I git-cloned the branch of50 and gave a blind try in compiling with OF6. I stumble on the solver compilation step. I just try to recompile interFoam to kva_interfoam to stay low. Allmake (that is wmake in recompileSolvers/kva_interfoam) fails with the error below. Any idea about what to do next?
Thx...

Making dependency list for source file interFoam.C
*** Error in `/opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep': free(): invalid next size (fast): 0x0000000000788670 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f9f109a47e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f9f109ad37a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f9f109b153c]
/opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep[0x401023]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f9f1094d830]
/opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep[0x401199]
======= Memory map: ========
00400000-00405000 r-xp 00000000 08:01 3043213                            /opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep
00604000-00605000 r--p 00004000 08:01 3043213                            /opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep
00605000-00606000 rw-p 00005000 08:01 3043213                            /opt/openfoam6/wmake/platforms/linux64Gcc/wmkdep
00606000-00607000 rw-p 00000000 00:00 0 
00788000-007ca000 rw-p 00000000 00:00 0                                  [heap]
7f9f0c000000-7f9f0c021000 rw-p 00000000 00:00 0 
7f9f0c021000-7f9f10000000 ---p 00000000 00:00 0 
7f9f10717000-7f9f1072d000 r-xp 00000000 08:01 6034606                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9f1072d000-7f9f1092c000 ---p 00016000 08:01 6034606                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9f1092c000-7f9f1092d000 rw-p 00015000 08:01 6034606                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9f1092d000-7f9f10aed000 r-xp 00000000 08:01 6034654                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9f10aed000-7f9f10ced000 ---p 001c0000 08:01 6034654                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9f10ced000-7f9f10cf1000 r--p 001c0000 08:01 6034654                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9f10cf1000-7f9f10cf3000 rw-p 001c4000 08:01 6034654                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9f10cf3000-7f9f10cf7000 rw-p 00000000 00:00 0 
7f9f10cf7000-7f9f10d1d000 r-xp 00000000 08:01 6034650                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9f10ed7000-7f9f10eda000 rw-p 00000000 00:00 0 
7f9f10f1a000-7f9f10f1c000 rw-p 00000000 00:00 0 
7f9f10f1c000-7f9f10f1d000 r--p 00025000 08:01 6034650                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9f10f1d000-7f9f10f1e000 rw-p 00026000 08:01 6034650                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9f10f1e000-7f9f10f1f000 rw-p 00000000 00:00 0 
7ffd6c67a000-7ffd6c69c000 rw-p 00000000 00:00 0                          [stack]
7ffd6c775000-7ffd6c778000 r--p 00000000 00:00 0                          [vvar]
7ffd6c778000-7ffd6c77a000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
make: *** Deleting file 'Make/linux64GccDPInt32Opt//opt/openfoam6/applications/solvers/multiphase/interFoam/interFoam.C.dep'
 make: *** No rule to make target 'Make/linux64GccDPInt32Opt//opt/openfoam6/applications/solvers/multiphase/interFoam/interFoam.C.dep', needed by 'Make/linux64GccDPInt32Opt//opt/openfoam6/applications/solvers/multiphase/interFoam/interFoam.o

ETA: discussion on https://github.com/floquation/OF-kva...rties/issues/3

[JM27]

Hi Kevin,

First of all thank you for sharing this code. It is in the spirit of the open-source community to share experience and knowledge.


I have followed the steps outlined in this blog post as well as on the git page to compile this library for use with OpenFOAM v5.



I am using compressibleInterFoam. I manage to compile this by inserting the absolute path to twoPhaseMixtureThermo.H. I have tried implementing the changes you suggested to eliminate the reading of rho1 and rho2 from thermophysicalProperties. Unfortunately this does not seem to solve the issue, so I still have to specify the phases in thermophysicalProperties despite 'hackiing' your code. It would be useful to know whether anyone else has tried it, I wouldn't be surprised to find I am missing something. I did recompile and hash the solver once compilation was complete.

However, there is an error that I have not been able to make sense of:

--> FOAM FATAL ERROR: 
different mesh for fields interfaceProperties:K and -div(nHatf) during operatrion =

    From function void Foam::GeometricField<Type, PatchField, GeoMesh>::operator=(const Foam::tmp<Foam::GeometricField<Type, PatchField, GeoMesh>> &) [with Type = double, PatchField = Foam::fvPatchField, GeoMesh = Foam::volMesh]
    in file /blablabla/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/src/OpenFOAM/lnInclude/GeometricField.C at line 1201.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::operator=(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#3  Foam::curvatureModels::vofsmooth::calculateK(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&) const at ??:?
#4  Foam::twoPhaseMixtureThermo::correct() at ??:?
#5  ? at ??:?
#6  __libc_start_main in "/lib64/libc.so.6"
#7  ? at ??:?

I have tried having a search on this forum, but only found one post experiencing the same error with no solution provided. Could you provide some suggestions as to what might be causing this? I understand the library dependency of compressibleInterFoam is a bit more involved than for interFoam, but I do not see why it should not work. (P.S. the code works fine for use with interFoam).



Also, with regards to the interfaceCompression scheme - turns out that I am also using this scheme (tbh, surprised to hear it is not really in use anymore!). How difficult is it to implement the functionality of this scheme for use with your dynamic library and compressibleInterFoam? Could you perhaps provide some guidance? I have some experience in OpenFOAM but it is my first time trying to tweak a solver, so any help is appreciated



Thanks in advance for your help on this.


Regards,


Jacky

[UKARUN]

Mr. Sripadraja were you able to solve the problem you mentioned. I am also facing a similar problem. reading file p_rgh and then fatal error. What could have gone wrong? How to overcome this error? Can anyone help?

[Venky_94]

Originally Posted by duongquaphim

Indeed you can also use that function. And it is much simpler I agree.

At the time I implemented that, I would like to have controls on the level of smoothing (averaging) and also to be able to implement different smoothers (which I did not find superior to that simple Laplacian). So that's why you have such a piece of code.

Best,

Duong

Sorry to dig this up after so long. I wanted to confirm something. From your agreement in quoted post, are you saying that I can use the below code snippet within interfaceProperties.C file and carry on with the curvature calculation by taking the gradient of alpha1_smooth instead of alpha1_ as in the default header, without even including the smooth_function.H file from your files? Would that give the same results?

alpha1_smooth = fvc::average(fvc::interpolate(alpha));

[farzadmech]

Dear Kevin
Thanks for sharing your code which I am going to test it with OF21 to see if it is compatible or not. I just have a simple question which anyone with bubble simulation experiment can answer; how many cell per bubble diameter is good enough to see the bubble shape changes? Also, do you recommend AMR (adaptive refined mesh) alongside your smoothing code or not?


Thanks,
Farzad

Originally Posted by floquation

Have a look at the following.


OF-4.x implementation of 'vofsmooth':
I have implemented Duong's "vofsmooth" in OF-4.x.
It was implemented using OF's run-time selection mechanism and a dynamic library trick, such that it should work with any solver (that uses OF's libinterfaceProperties.so: inter(DyM)Foam, compressibleInter(DyM)Foam, multiphaseInter(DyM)Foam, interPhaseChange(DyM)Foam and very likely some more.)
[Disclaimer: I have only tried inter(DyM)Foam in my work.]

See the README.md on GitHub:
https://github.com/floquation/OF-kva...faceProperties

[JM27]

Hi,

I would start with a static mesh. In terms of required resolution, this also depends on the change in radius (delta R) you wish to capture in your simulation. If your grid is not fine enough, then you will not be able to capture any changes in bubble shape, irrespective of whether you are using AMR or not. I would start with static grid.

Good luck!

[farzadmech]

Thanks, I will do so.


Farzad

Originally Posted by JM27

Hi,

I would start with a static mesh. In terms of required resolution, this also depends on the change in radius (delta R) you wish to capture in your simulation. If your grid is not fine enough, then you will not be able to capture any changes in bubble shape, irrespective of whether you are using AMR or not. I would start with static grid.

Good luck!

[farzadmech]

Dear Kevin and all others
This is a cross-post; https://github.com/floquation/OF-kva...rties/issues/6

I have installed OpenFoam4x in order to use your "kva_interfaceProperties", and I tested and Openfoam4x works fine. When I want to compile the, below sections works fine and generates a folder named "farzad-4.x", and I have it here;

OpenFOAM/farzad-4.x/libraries/kva_interfaceProperties

So your commands worked up to here;

of40
mkdir -p $FOAM_RUN/../libraries
cd $FOAM_RUN/../libraries
---------------------------------------------------
git clone https://github.com/floquation/OF-kva_interfaceProperties
mv OF-kva_interfaceProperties kva_interfaceProperties
cd kva_interfaceProperties
---------------------------------------------------
git checkout of40
---------------------------------------------------
wmake
---------------------------------------------------

Now I want to recompile my solver and as you suggested, I did this;

cd recompileSolvers 

//And I used your original suggestion;

# FULL_PATH_to_solver; optional_new_solver_name
$FOAM_SOLVERS/multiphase/interFoam; kva_interFoam
$FOAM_SOLVERS/multiphase/interFoam/interDyMFoam; kva_interDyMFoam

but here, below code does not work;

./Allget && ./Allwmake

which gives below error;

bash: ./Allget: /usr/bin/sh: bad interpreter: No such file or directory

why? and what should I do?
just as a reminder, For openfoam4x I have these 3 main folders;

farzad-4.x OpenFOAM-4.x  ThirdParty-4.x

Thanks,
Farzad

Originally Posted by floquation

Have a look at the following.


OF-4.x implementation of 'vofsmooth':
I have implemented Duong's "vofsmooth" in OF-4.x.
It was implemented using OF's run-time selection mechanism and a dynamic library trick, such that it should work with any solver (that uses OF's libinterfaceProperties.so: inter(DyM)Foam, compressibleInter(DyM)Foam, multiphaseInter(DyM)Foam, interPhaseChange(DyM)Foam and very likely some more.)
[Disclaimer: I have only tried inter(DyM)Foam in my work.]

See the README.md on GitHub:
https://github.com/floquation/OF-kva...faceProperties

[farzadmech]

I start with static grid but I do not know why AMR does not work. I tested with original interFoam (in OF4) and still AMR is not working. Is AMR implemented in OF4?

Thanks,
Farzad

Originally Posted by JM27

Hi,

I would start with a static mesh. In terms of required resolution, this also depends on the change in radius (delta R) you wish to capture in your simulation. If your grid is not fine enough, then you will not be able to capture any changes in bubble shape, irrespective of whether you are using AMR or not. I would start with static grid.

Good luck!