stange error when compiling for compressibleInterFoam with OF v5

[JMM27]

Hi Kevin,

Sorry to cross-post, but I've read in another post you might not check the cfd-online posts too often.

I am having some trouble in getting this to work with compressibleInterFoam in OF v5. The error is as follows:

 --> 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 /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/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 ??:?  

More details on here: https://www.cfd-online.com/Forums/openfoam-verification-validation/124363-interfoam-validation-bubble-droplet-flows-microfluidics-3.html#post735107

A few other things:

• Since 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 'hacking' your code. It would be useful to know whether anyone else has tried it and worked, I wouldn't be surprised to find I am missing something. I did recompile and hash the solver once compilation was complete.

• 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.

Kind regards,

Jacky

[floquation]

You're very right to post this here, as I wouldn't have (ever) seen it on CFDOnline.

The error seems to implicate that there are two different meshes. I reckon that's normal if you have something like dynamic mesh refinement (as in interDyMFoam), or if you're trying to couple particle-based methods (e.g., DSMC) and CFD. To your knowledge, does compressibleInterFoam normally use multiple meshes? I never used it, but I wouldn't expect so.

Or... perhaps this sort of error also appears when a volField is being assigned to a surField (or vice versa). Perhaps in compressibleInterFoam the fieldType is different...?

Can you try to check the following:

1. Can you compile the code successfully with regular interFoam?
2. Does compressibleInterFoam use the interfaceCompression library, just like interFoam does? If so, is it referenced (used) in the solver in the same manner? Or do you see differences? You can compare this by opening both solvers simultaneously, and comparing them line by line where interfaceCompression is used.
3. How does "rho" work in compressibleInterFoam? That is, is it a field, or a scalar?

[JMM27]

Hi Kevin,

Thank you for the super prompt reply!

Yes, it seems that's what the error is suggesting, however, I have never come across this when using OpenFOAM before and I am not using any fancy meshing techniques, just a uniform grid. I am not trying to couple multiple methods either, so I find this error a bit perplexing.

I'll have a go with your suggestions, however, to answer your questions:

1. Yes, code compiled successfully with interFoam and managed to run a couple of tutorials cases and some other simulations I had done in interFoam.
2. Yes, it also uses interfaceCompression library. I'll check the details by comparing the source codes as you suggest.
3. rho is a field, computed according to the equation of state specified in the thermophysicalProperties dict.

In the posts relating to kva_interfaceProperties, I did read however of people managing to make this work for compressibleInterFoam, so perhaps something has changed in this version of OpenFOAM ?

I'll try to find out more and get back to you.

Thanks.

Jacky.

[floquation]

In the posts relating to kva_interfaceProperties, I did read however of people managing to make this work for OpenFOAM, so perhaps something has changed in this version of OpenFOAM ?

If that's the case, I'd try the following:

1. Test to see whether it works in OF4.
2. Send a private message on the forum to the person(s) who managed to achieve this. (Note: a private message sends people an email, so they will probably get to see it, even if they don't check the forum anymore (like me).)

rho is a field, computed according to the equation of state specified in the thermophysicalProperties dict.

That could be the critical difference between interFoam and compressibleInterFoam, as in interFoam rho is computed from rho_1 and rho_2 (two scalars) using the alpha-field as weighting factor. Perhaps this causes the error, since "nHatf" is computed from the gradient of rho... Perhaps something goes wrong in that calculation, resulting in a different type of field, and hence the error.

[JMM27]

Hi Kevin,

I will try asking the other users, hopefully they are as helpful as you are.

I am getting a different error now (I deleted everything and recompiled from scratch. Again, kva_interFoam works fine, but not kva_compressibleInterFoam):

This what I get upon trying to run the depthCharge2D tutorial (with the added entries in thermophysicalProperties):

--> FOAM FATAL ERROR: 
object of type N4Foam9rhoThermoE is not allocated

    From function T &Foam::autoPtr<T>::operator()() [with T = Foam::rhoThermo]
    in file /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/src/OpenFOAM/lnInclude/autoPtrI.H at line 139.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  ? at ??:?
#3  ? at ??:?
#4  __libc_start_main in "/lib64/libc.so.6"
#5  ? at ??:?

I think this confirms that it is something related to rho, however I have absolutely no idea what N4Foam9rhoThermoE is.

[floquation]

Regarding the first error you were getting: do you use densityWeighted=False? In that case, rho is not used explicitly in the curvature calculation of kva_interfaceProperties. Perhaps that gets rid of the error.

I copy these links, such that I can easily open them again later, if I need to do further comparing: https://github.com/OpenFOAM/OpenFOAM-5.x/blob/master/src/transportModels/interfaceProperties/interfaceProperties.C https://github.com/floquation/OF-kva_interfaceProperties/blob/of50/interfaceProperties.C https://github.com/floquation/OF-kva_interfaceProperties/blob/of50/curvatureModel/vofsmooth/vofsmooth.C

Getting a new error after recompiling is weird. That must imply you did something differently either the first time or the second time. What happens if you give it a third go?

I don't know the origin of the second error. "Not allocated" seems to imply a programming error, but "rhoThermo" (or anything like that) is not part of kva_interfaceProperties. I reckon you're missing a dependency of compressibleInterFoam during compilation? Compare the make/files files of the original compressibleInterFoam and kva_compressibleInterFoam.

[JMM27]

Hi Kevin,

Yes, the first error was obtained using densityWeighted set to "no". In any case, the default is set to false, right? So it shouldn't make much of a difference I believe.

Previously I had compiled kva_interfaceProperties only for interFoam and interDyMFoam. I tried doing the same for compressibleInterFoam and compressibleInterDyMFoam in a separate directory, but it wasn't quite working well so I thought to restart from scratch with all kva_interfaceProperties linked to all 4 solvers at one go.

I've checked the dependencies, and it look fine to me. Including these below for your info:

kva_compressibleInterFoam make/options:

EXE_INC = \
    -I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam \
    -I../../lnInclude \
    -I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/../VoF \
    -I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo \
    -I$(LIB_SRC)/transportModels/compressible/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/transportModels/twoPhaseMixture/lnInclude \
    -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/compressible/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -L$(FOAM_USER_LIBBIN) \
    -lkva_interfaceProperties \
    -ltwoPhaseMixtureThermo \
    -ltwoPhaseSurfaceTension \
    -lcompressibleTransportModels \
    -lfluidThermophysicalModels \
    -lspecie \
    -ltwoPhaseMixture \
    -ltwoPhaseProperties \
    -linterfaceProperties \
    -lturbulenceModels \
    -lcompressibleTurbulenceModels \
    -lfiniteVolume \
    -lfvOptions \
    -lmeshTools

for the native compressibleInterFoam in /src, make/options:

EXE_INC = \
    -I. \
    -I../VoF \
    -ItwoPhaseMixtureThermo \
    -I$(LIB_SRC)/transportModels/compressible/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/transportModels/twoPhaseMixture/lnInclude \
    -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/compressible/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -ltwoPhaseMixtureThermo \
    -ltwoPhaseSurfaceTension \
    -lcompressibleTransportModels \
    -lfluidThermophysicalModels \
    -lspecie \
    -ltwoPhaseMixture \
    -ltwoPhaseProperties \
    -linterfaceProperties \
    -lturbulenceModels \
    -lcompressibleTurbulenceModels \
    -lfiniteVolume \
    -lfvOptions \
    -lmeshTools

[JMM27]

Hi Kevin,

A small update (also for future reference and as info to other users).

• from my understanding, interFoam and compressibleInterFoam link to the same interfaceProperties library, so I do not see why the issue would arise with kva_interfaceProperties if the density weighting is off.

• In your previous replies, you wrote " "nHatf" is computed from the gradient of rho ". I cannot seem to find this in your code. Can you indicate where this is?

• I am getting confused with the linking to interfaceProperties under EXE_INC = \ in Make/options. Should this be:

-I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \

or the absolute path to kva_interfaceProperties?

It seems that if I use ./Allget and ./Allmake I would get -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude . However, I tried manual compilation (I'm using a managed desktop) and if I use the absolute path to kva_interfaceProperties I get a missing dependency to surfaceTensionModel.H :

[esrfbq@totanus kva_compressibleInterFoam]$ could not open file surfaceTensionModel.H for source file /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/compressibleInterFoam.C due to No such file or directory
In file included from /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo/twoPhaseMixtureThermo.H(42),
                 from /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/compressibleInterFoam.C(46):
../../lnInclude/interfaceProperties.H(54): catastrophic error: cannot open source file "surfaceTensionModel.H"
  #include "surfaceTensionModel.H"
                                  ^

compilation aborted for /desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/compressibleInterFoam.C (code 4)
make: *** [Make/linux64IccDPInt32Opt//desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/compressibleInterFoam.o] Error 4

I'll post solution once resolved.

[floquation]

In your previous replies, you wrote " "nHatf" is computed from the gradient of rho ". I cannot seem to find this in your code. Can you indicate where this is?

That was a slip-up. It's the gradient of alpha: https://github.com/floquation/OF-kva_interfaceProperties/blob/of50/curvatureModel/vofsmooth/vofsmooth.C

I am getting confused with the linking to interfaceProperties under EXE_INC = \ in Make/options. Should this be: -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \

or the absolute path to kva_interfaceProperties?

It seems that if I use ./Allget and ./Allmake I would get -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude . However, I tried manual compilation (I'm using a managed desktop) and if I use the absolute path to kva_interfaceProperties I get a missing dependency to surfaceTensionModel.H :

An absolute or relative path does not matter. Note, however, that we include both kva_interfaceProperties and the original interfaceProperties lnInclude directories, in precisely that order. In that way, the classes I overwrite in kva_interfaceProperties are found in kva_interfaceProperties, whereas the classes I do not alter (and thus aren't present in kva_interfaceProperties) are found in the original lnInclude directory of interfaceProperties. One such class is surfaceTensionModel.H (i.e., your error). So when you changed to the "absolute path", you accidentally changed the real interfaceProperties reference to kva_interfaceProperties. kva_interfaceProperties is currently referenced relatively using -I../../lnInclude, which you'll see appearing before -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude. So if you want to make it absolute, you should change -I../../lnInclude (but there really is no need to!).

So that solves your latest "missing surfaceTensionModel.H" error.

from my understanding, interFoam and compressibleInterFoam link to the same interfaceProperties library, so I do not see why the issue would arise with kva_interfaceProperties if the density weighting is off.

Can you try setting the smoothing method to "normal" in transportProperties? Then kva_interfaceProperties should do the very same thing as the original interfaceProperties. Do you then still get an error?

[floquation]

I do remember someone had a weird error I could not explain in the past... That was with OF50, but regular interFoam if I recall correctly. He solved it by copying the entire solver source code, instead of using my referencing to the original solver location (which should work fine, as that source code needs not be altered; just recompiled with kva_interfaceProperties as dynamic library linked; that's why we couldn't understand why this solved his problem). That is, you copy compressibleInterFoam.C etc. (everything) to the new kva_compressibleInterFoam directory.

[JMM27]

Hi Kevin,

Thank you for clarifying. However, this does not seem to be an issue for interFoam. For the record, in another error on the github page (https://github.com/floquation/OF-kva_interfaceProperties/issues/2#issuecomment-309375167) step ii) says these two lines should be replaced so you might want to update that? My Make/options now looks like this:

EXE_INC = \
-I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam \
    -I../../lnInclude \
    -I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/../VoF \
    -I/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo \
-I$(LIB_SRC)/transportModels/compressible/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/transportModels/twoPhaseMixture/lnInclude \
-I/home/eng/esrfbq/OpenFOAM/esrfbq-5.0-20180108/kva_smoothingFn_compressibleInterFoam/kva_interfaceProperties/lnInclude \    
-I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/compressible/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
-L$(FOAM_USER_LIBBIN) \
-lkva_interfaceProperties \
    -ltwoPhaseMixtureThermo \
    -ltwoPhaseSurfaceTension \
    -lcompressibleTransportModels \
    -lfluidThermophysicalModels \
    -lspecie \
    -ltwoPhaseMixture \
    -ltwoPhaseProperties \
-linterfaceProperties \
    -lturbulenceModels \
    -lcompressibleTurbulenceModels \
    -lfiniteVolume \
    -lfvOptions \
    -lmeshTools

which compiles successfully with no missing header files. However, trying to run this for the "normal" method still gives the error I quoted earlier:

--> FOAM FATAL ERROR: 
object of type N4Foam9rhoThermoE is not allocated

    From function T &Foam::autoPtr<T>::operator()() [with T = Foam::rhoThermo]
    in file /warwick/desktop/2018/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/src/OpenFOAM/lnInclude/autoPtrI.H at line 139.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  ? at ??:?
#3  ? at ??:?
#4  __libc_start_main in "/lib64/libc.so.6"
#5  ? at ??:?

I think I will try copying the entire solver source code and hope it works. I suspect I am messing something up in terms of dependencies. I do expect this to work as posts #38 to #44 in https://www.cfd-online.com/Forums/openfoam-verification-validation/124363-interfoam-validation-bubble-droplet-flows-microfluidics-2.html seem to suggest it is possible, although one user does point out persisting issues. I have messaged them privately like you suggested but so far no replies.

Your help on this is very much appreciated, so thank you.

[floquation]

For the record, in another error on the github page (#2 (comment)) step ii) says these two lines should be replaced so you might want to update that?

I updated it. That was from "back in the days", when it was done slightly differently.

as posts #38 to #44

Post #38: multiphaseInterFoam will never work, as it has a different curvature calculation entirely. (P.S.: he is correct that adding an arbitrary rho_1 and rho_2 with densityWeighted=false will have no effect.) Post #39: That was the error you were facing just now, and is now resolved. Post #40: He seems to imply that he got it working (but possibly in OF40! - you could try that just to see), so that'd be great.

I think I will try copying the entire solver source code and hope it works.

I'll wait for that outcome.

[JMM27]

The curvature calculation in compressibleInterFoam is still the CSF model of Brackbill which is why I think it should work.

I think I will leave OF40 as a last resort - given it is a managed desktop I would need to ask IT to have it installed on my desktop so ideally I would manage to get it work in OF50. I do have access to OF6, although it seems that this does not work for that version?

So I copied everything in applications/solvers/multiphase/compressibleInterFoam and like dependencies to /VoF and /twoPhaseMixtureThermo to the /src directory and error persists. I'm getting a bit dispirited now... do you have any other ideas I could try?

[JMM27]

Hi Kevin,

Just for your info.

I have managed to make kva_interfaceProperties work with OFv4 on our cluster. which is reassuring.

• It seems that the algorithm and file structure for compressibleInterFoam has changed slightly between v4 and v5. e.g. there is no /solvers/multiphase/VoF in v4. I suspect compatibility with OF v6 fails for similar reasons.

• This confirms it is implementable with compressibleInterFoam however I would still like to make it work with OFv5 (I am using PBiCGStab which seems to not be supported in v4). I have tried several alternative ways of installation, including manual compilation, and modifying the code directly as in Hoang's original code. However none seems to have worked for v5 just yet.

It would be good to find out what the issue with the never versions is.

Regards,

Jacky

Update. Differences in compilation using ./Allget && ./Allwmake scripts for OFv4 and OFv5:

In both cases, the absolute path to twoPhaseMixtureThermo was manually modified.

OFv4 (cluster):

EXE_INC = \
    -I/software/MPI/intel/2016.3.210-GCC-5.4.0-2.26/impi/5.1.3.181/OpenFOAM/4.0/OpenFOAM-4.0/applications/solvers/multiphase/compressibleInterFoam \
    -I/software/MPI/intel/2016.3.210-GCC-5.4.0-2.26/impi/5.1.3.181/OpenFOAM/4.0/OpenFOAM-4.0/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo \
    -I$(LIB_SRC)/transportModels/compressible/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/transportModels/twoPhaseMixture/lnInclude \
    -I../../lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/compressible/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -L$(FOAM_USER_LIBBIN) \
    -lkva_interfaceProperties \
    -ltwoPhaseMixtureThermo \
    -lcompressibleTransportModels \
    -lfluidThermophysicalModels \
    -lspecie \
    -ltwoPhaseMixture \
    -ltwoPhaseProperties \
    -linterfaceProperties \
    -lturbulenceModels \
    -lcompressibleTurbulenceModels \
    -lfiniteVolume \
    -lfvOptions \
    -lmeshTools

OFv5 (cluster):

EXE_INC = \
    -I/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam \
    -I../../lnInclude \
    -I/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/../VoF \
-I/software/MPI/intel/2018.1.163-GCC-6.4.0-2.28/impi/2018.1.163/OpenFOAM/5.0-20180108/OpenFOAM-5.0-20180108/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo \
    -I$(LIB_SRC)/transportModels/compressible/lnInclude \
    -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude \
    -I$(LIB_SRC)/transportModels/twoPhaseMixture/lnInclude \
    -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude \
    -I$(LIB_SRC)/TurbulenceModels/compressible/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -L$(FOAM_USER_LIBBIN) \
    -lkva_interfaceProperties \
    -ltwoPhaseMixtureThermo \
    -ltwoPhaseSurfaceTension \
    -lcompressibleTransportModels \
    -lfluidThermophysicalModels \
    -lspecie \
    -ltwoPhaseMixture \
    -ltwoPhaseProperties \
    -linterfaceProperties \
    -lturbulenceModels \
    -lcompressibleTurbulenceModels \
    -lfiniteVolume \
    -lfvOptions \
    -lmeshTools

v5 compiles on the cluster but with some warnings:

[login1 recompileSolvers]$ Make/options:4: warning: backslash and newline separated by space
ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1
ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1

I do not see why it should work on the cluster but not on my desktop. However, no harm in trying. I am testing now.

[floquation]

So I copied everything in applications/solvers/multiphase/compressibleInterFoam and like dependencies to /VoF and /twoPhaseMixtureThermo to the /src directory and error persists. I'm getting a bit dispirited now... do you have any other ideas I could try?

So every single .C and .H file, including all subdirectories of the solver were copied? If so, I have nothing to add.

I have managed to make kva_interfaceProperties work with OFv4 on our cluster. which is reassuring.

That's great! An advantage of v4, is that in my of40-dev branch I have implemented more advanced algorithms (papers referenced in the README of that branch), that are not yet in the master branch, nor the of50 branch. However, I stopped working on this, so unless someone else does it, those changes won't be incorporated into the master branch.

v5 compiles on the cluster but with some warnings:

[login1 recompileSolvers]$ Make/options:4: warning: backslash and newline separated by space ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1 ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1

First warning is a "spacebar" on line #4 as last character, after the backslash. Remove it, and the warning disappears. I don't know where the linking (ld) errors come from. That seems openfoam-related, and not my-library-specific.

I am testing now.

So... did it run without error?

however I would still like to make it work with OFv5

So, had you checked whether the way compressibleInterFoam uses interfaceProperties in v4 versus v5 has changed? If so, there must be a hint in that difference as to how to make it working.

Alternatively, you could start with my of40 (or of40-dev) branch. Then replace my interfaceProperties.C and interfaceProperties.H with the ones from OFv5. Then open my changed interfaceProperties, the original OFv4 interaceProperties, and the OFv5 interfaceProperties that you just copied into kva_interfaceProperties. By comparing the three of them, perhaps you can implement the calls to my other classes (e.g., curvatureModel)? In that manner, you should at least have the interfaceProperties.[CH] files as they should be in OFv5 as a starting point.

[JMM27]

Hi Kevin,

Sorry for the delay in replying.

So I copied everything in applications/solvers/multiphase/compressibleInterFoam and like dependencies to /VoF and /twoPhaseMixtureThermo to the /src directory and error persists. I'm getting a bit dispirited now... do you have any other ideas I could try?

So every single .C and .H file, including all subdirectories of the solver were copied? If so, I have nothing to add.

This does not seem to solve the issue. It seems that the implementation is slightly different in v5 so I need to go through it.

I have managed to make kva_interfaceProperties work with OFv4 on our cluster. which is reassuring.

That's great! An advantage of v4, is that in my of40-dev branch I have implemented more advanced algorithms (papers referenced in the README of that branch), that are not yet in the master branch, nor the of50 branch. However, I stopped working on this, so unless someone else does it, those changes won't be incorporated into the master branch.

I'll have a look at these algorithms. I did run some static bubble simulations in OFv4 with kva_interfaceProperites, and I can see that the parasitic currents reduce with time - which is great! However, implementing it for more advanced cases, (e.g. oscillatory pressure boundary) I am still getting unphysical behaviour at the bubble interface... which seems to indicate that there might be some numerical issues arising from this kind of boundary.

v5 compiles on the cluster but with some warnings: [login1 recompileSolvers]$ Make/options:4: warning: backslash and newline separated by space ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1 ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1

First warning is a "spacebar" on line #4 as last character, after the backslash. Remove it, and the warning disappears. This is fine, I was more asking about the 'ld' errors. I don't know where the linking (ld) errors come from. That seems openfoam-related, and not my-library-specific.

I am testing now.

So... did it run without error?

Nope! Strangely enough, now the error that crops up is the one I had quoted in my first post,

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

however I would still like to make it work with OFv5

So, had you checked whether the way compressibleInterFoam uses interfaceProperties in v4 versus v5 has changed? If so, there must be a hint in that difference as to how to make it working.

Alternatively, you could start with my of40 (or of40-dev) branch. Then replace my interfaceProperties.C and interfaceProperties.H with the ones from OFv5. Then open my changed interfaceProperties, the original OFv4 interaceProperties, and the OFv5 interfaceProperties that you just copied into kva_interfaceProperties. By comparing the three of them, perhaps you can implement the calls to my other classes (e.g., curvatureModel)? In that manner, you should at least have the interfaceProperties.[CH] files as they should be in OFv5 as a starting point.

Thanks for these tips! I will try it out and let you know how I get on with this implementation. I think I have a better understanding of the implementation in v4 so it shouldn't be too difficult to get it done for v5. However, at the moment I am trying to pin point whether the issues I am experiencing are solely a result of the parasitic currents or whether there are some other issues (e.g. reflections from the domain boundaries that are causing the bubble interface to become unstable)...so it might be a while before I get this done.

If it works, I am more than happy to share the changes needed for v5.

Thanks again :)

[floquation]

I'm sorry, I've been horribly short on time the past two weeks (and time is still scarce).

How is it going? Are your previous questions still relevant at present?

[JMM27]

I'm sorry, I've been horribly short on time the past two weeks (and time is still scarce).

How is it going? Are your previous questions still relevant at present?

Hi, thanks for following up! It has been the same for me. Still having the same questions. I am trying to model bubble oscillations but it seems that the problem is quite unstable and the bubble breaks up after the first oscillations. So not sure it is worth the effort to modify the code for v5 just yet. I haven't forgotten about this though, so I will let you know if I implement for compressibleInterFoam in v5.