Error when running interFoam

[akesm]

for a stationary bubble case with interFoam I am trying to use the interfaceproperties. I believe I have it compiled already and ready to use, since running
ldd $(which interFoam) | grep "interfaceProperties
gives the report
libinterfaceProperties.so => /home//OpenFOAM/platforms/linux64GccDPInt32Opt/lib/libinterfaceProperties.so (0x00007f7711a00000)

By the way, when running interFoam I get the error

PIMPLE: Operating solver in PISO mode

Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting curvatureModel normal
kva: curvatureModel::read(normal);
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigSegv::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
Segmentation fault (core dumped)

What is wrong that it is not working?
I have just added

curvatureModel normal; // normal;
vofsmoothCoeffs
{
numSmoothingIterations 2; // default: 2
}

to the transport properties.

[floquation]

Yes, interFoam does see kva_interfaceProperties. After all, your error message refers to my new class!
You did also correctly add the correct lines to transportProperties. (Note: you selected OF's default model, not the smoothed model "vofsmooth".)
That's the good news...

=============

Now the bad news is your segfault...
That's the problem with segfaults: I do not get any, whereas you clearly do.
I do not know what is wrong, but I do have a strong suspicion.

With the new version of this library (not yet on GitHub) I am also facing segfaults that appear inexplicably out of nowhere. It turned out that this was not a C++/code issue, but a linker issue. I am still trying to figure out what exactly I did wrong, but I'm fairly sure it is related to the ABI having changed compared to OF's libinterfaceProperties.so.
The solution is to relink your solver. The easiest way to do this is to simply recompile your solver in the OF tree... But then you must, of course, have writing rights to the main source tree.

=============

So let me assume that you do not have those rights, or you simply don't want to do that (after all: it would be bad practice!). Then do the following:
1a) Copy your solver (presumably interFoam) to a directory in which you have writing rights. For example:
mkdir -p $FOAM_RUN/../applications/solvers/multiphase/kva_interFoam
cd $FOAM_RUN/../applications/solvers/multiphase/kva_interFoam
cp -r $FOAM_SRC/../applications/solvers/multiphase/interFoam/Make .
Note that I only copied the Make directory. That is, we would like to recompile interFoam, but there is of course no reason to copy the entire source code, as we are not changing it! We can just link to it.
1b) Link kva_interFoam to the interFoam source
i) in Make/files replace
interFoam.C
by
$(FOAM_SOLVERS)/multiphase/interFoam/interFoam.C
and
EXE = $(FOAM_APPBIN)/interFoam
by
EXE = $(FOAM_USER_APPBIN)/interFoam
ii) in Make/options add
-I$(FOAM_SOLVERS)/multiphase/interFoam \
just below EXE_INC = \,
(and certainly above -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \)
add
-I$(FOAM_RUN)/../libraries/kva_interfaceProperties/lnInclude \
Please adapt that line to where you decided to install kva_interfaceProperties.
iii) in Make/options add
-L$(FOAM_USER_LIBBIN) \
-linterfaceProperties \
just below EXE_LIBS = \, such that it can correctly link against kva_interfaceProperties.
2) Compile
wclean && wmake
3) Check
And check if it's there:
ls $FOAM_USER_APPBIN
Also make sure that it links to the new interfaceProperties (so the one in $FOAM_USER_LIBBIN):
ldd $FOAM_USER_APPBIN/interFoam | grep "interfaceProperties"
4) Re-log
To use your newly compiled interFoam, we must rebuild the hash for interFoam. This is equivalent to re-logging.
hash interFoam
5) Check again
Does type interFoam point to the interFoam which resides in $FOAM_USER_APPBIN?
Then everything is set!

=============

Now you will have a new interFoam in $FOAM_USER_APPBIN which is identical to interFoam (after all, we did not change its source code), but linked to my version of libinterfaceProperties.so.

Let me know if this works for you. If it does, I will update the installation instructions by a slightly more proper way than what I just told you here.

[akesm]

Thanks for your detailed explanation to work it out, yes now it runs without errors. Just for the last point to mention that after "hash"ing interFoam and checking it, it says
interFoam is hashed (/home/OpenFOAM/platforms/linux64GccDPInt32Opt/bin/interFoam)
which I think is fine.

P.S. Do you have an informal or internal report that shortly explains how you implemented your smoothing in VOF to add here? I know you have referred to two papers, but a brief and explicit description would be great. That would be nice since people can be aware of the implementations, and even help to improve it further :)

Thanks
Akesm

[floquation]

I do not have any such report, no; only some rough design drawings and notes on paper.

What the smoother does mathematically is applying a Laplacian smoothing filter This means that the cell centre values and interpolated to the cell face values, and then the cell face values are interpolated back to the cell centre values. This process is repeated twice (2 iterations). That is described in those papers. In fact, I only ported Hoang's implementation to OF4x: I did not write that part myself.
What he, in turn, did to implement his smoother is simply copying a part of OF's interpolation classes, which he put in a function called smoothen(). Then, inside the calculateK() function, instead of computing the curvature from the alpha field, the alpha field is first smoothened, and then that smoothened field is used to calculate the curvature. That curvature calculation is still identical to what OF is doing (the only difference is that the smoothed alpha field is now used).

Hoang wrote this at a solver-level. I wrote it at a library-level instead, which makes it usable for any (VoF) solver (although you sadly need to recompile your solver... but I'm looking into that).
In the header of the file interfaceProperties.H I wrote what exactly I changed to the interfaceProperties class w.r.t. the one of OF40. Those notes allow easy porting to future versions of OF. My changes here basically boil down to forwarding the call of calculateK() to a class curvatureModel which is inherited by normal and vofsmooth. I have made those run-time selectable. In turn, normal simply does what OF was already done, whereas vofsmooth has the smoother in place.

[akesm]

Thanks for explanation,
But now there has happened a problem when I went through setting up the solver as you described above.
First, using the interFoam I set up as above I could run a case of 2d stationary air bubble. In the magnitude of spurious velocity changes could be observed by changing the number of iterations say from 1 to 3 which makes sense, also there was a difference when using vofsmooth of when not using it and set it to normal.

But, weird is that, if I for the same case put sigma1000 or even \sigma1e-3 or even \mu_air or \mu_water *1000 or 1e-3 spurious velocities are exactly the same magnitudes at similar time steps. To me, it seems somehow you implementation has made interFoam insensitive to \sigma and/or \mu, and maybe it takes them some default values from somewhere that changing their values by the user does not affect the simulation results.

Getting to know this I wanted to reproduce one of my interFoam simulations I had before, and found out that in fvSchemes "interfaceCompression" was not defined so I had to change it to something else to have it running, so I changed it to Gauss linear, to have the interFoam run, but since I changed to Gauss linear I could not make comparison and reproduce my previous results. (Seems interfaceCompression is not included in your vofsmooth! is it?)

So now I decided to go back to my original default interFoam :) so I
cd $FOAM_USER_APPBIN
then wanted to delete the interFoam we added so I did
rm -r interFoam
then I went back to the directory of default OF solvers and made wclean and wmake.
But seems interFoam did not go back to it's previous state and when running I get the error

--> FOAM Warning : 
 From function static Foam::autoPtr<Foam::curvatureModel> Foam::curvatureModel::New(const Foam::word&, const Foam::interfaceProperties&)
 in file curvatureModel/curvatureModel.C at line 87
 Keyword "curvatureModel" not found in transportProperties dictionary. Using the default instead.
Selecting curvatureModel normal
kva: curvatureModel::read(normal);
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigSegv::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
Segmentation fault (core dumped)

Seems either the original implementation or the above one has modified the default OF lib files, how can I go back now?

[floquation]

Alright, one thing at a time.

Firstly, you say that it becomes insensitive to sigma? Did you also try that for the original interFoam? I am asking, because "vofsmooth" is about the curvature calculation; not about the surface tension force directly. That is, I do not touch sigma at all compared to the original OF. So if something is still wrong here, it might be related to the original segfault still not being resolved, but merely hidden. However, I don't think something is wrong, given the validations I did myself.
I have ran a case with sigma=0.07 and sigma=1110 (so 5 orders apart), which correspond to two different cases on the Clift map (Re=11.4 and Re=160; both nearly-spherical). Both resulted in a different terminal rising velocity, in reasonable agreement with experiments. (By "reasonable" I mean that a 2D simulation won't be perfect, even after correcting its cylindrical shape to a spherical shape.)
I'll have to think about why it is insensitive, but I reckon the key here is that you were performing a zero gravity simulation? In zero-gravity you will get a spherical bubble regardless of the value of sigma, right? So the mistake made in the curvature calculation will be the same... However, that should be amplified by sigma to form spurious currents.... Then I currently also fail to see why it would be insensitive...

Secondly, you talk about the "interfaceCompression" scheme. Personally, I have not been using that scheme. In fact, not a single tutorial in OF40 uses it, as "grep" returns empty-handed.
So you'll have to help me here: is it still being used in the new OF versions? That is, were "one of your interFoam simulations" also in the newest version? After all, in fvSolutions you can specify the cAlpha coefficient, which takes care of the interfacial compression, does it not?
The reason why it is gone is obvious for me though: it is part of OF's interfaceProperties library, but we injected kva_interfaceProperties in the place of OF's interfaceProperties library, so we lost that scheme in the process. It is very easy for me to add it back in though, I just need to add it to Make/files of my library.

Finally, to "go back", you should also remove (or move) libinterfaceProperties.so from $FOAM_USER_LIBBIN, which is kva_interfaceProperties. By deleting your new interFoam, you simply moved back to your first post here: the segmentation fault. The default OF lib files were not harmed in the process ;): that's where $FOAM_USER_LIBBIN is for!
What my library (kva_interfaceProperties) does is merely overshadowing OF's interfaceProperties by having the same name (libinterfaceProperties.so), but being in a location ($FOAM_USER_LIBBIN) that is checked before OF's library's location is checked ($FOAM_LIBBIN). This, in theory, allows you to very easily use my library, without doing complicated things. However, since you are the first person to try my code, you are sadly facing its child diseases now. But I'm helping you out to resolve these, and you help me fix those child diseases!

Since I have only just learned that we must also recompile the solver, I am considering changing this structure... I plan to look into that the coming few workdays.

[floquation]

Did everything work out?

[floquation]

I have improved the library to fix the SegFault. (That is, I do not get a SegFault, but that could still be luck. So I consider it fixed until someone presents me with another SegFault.)

It was impossible for me to write it in an ABI-independent manner. Therefore, it is mandatory to recompile your solver as to prevent the SegFault from occurring.
I have facilitated the recompilation by an automated script that can recompile (presumably) any solver with an optionally different name. This script follows the same steps as I had outlined for you above.

[floquation]

Since we are one month further, and this issue no longer occurs for me, I assume that this is fixed for everyone. If not, feel free to tell me.