[AlmostSurelyRob]

Dear All,

I am trying to rewrite turbulence models library for multiphase flows. To this end I have created my own library libInterRASModels.so and with its own turbulenceModel definition. I wanted it to be seperate from incompressible and compressible turbulence models so I created my onw namespace: multiphase.

The library compiles but for some reason I cannot link it to my customised interFoam. The only part that I changed is:

  // Construct incompressible turbulence model
    autoPtr<multiphase::turbulenceModel> turbulence
    (
            multiphase::turbulenceModel::New(U, rhoPhi, rho, twoPhaseProperties)
    );

The program itself compiles but it doesn't link:

g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-40 -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/transportModels     -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/transportModels/incompressible/lnInclude     -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/transportModels/interfaceProperties/lnInclude     -I/home/c111269/OpenFOAM/c111269-1.7.1/src/turbulenceModels/multiphase/turbulenceModel     -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/c111269/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC Make/linux64GccDPDebug/interFoam.o -L/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug \
     -linterfaceProperties     -lincompressibleTransportModels     -lfiniteVolume     -L/home/c111269/OpenFOAM/c111269-1.7.1/lib/linux64GccDPDebug/     -lInterRASModels  -lOpenFOAM -liberty -ldl  -ggdb3 -DFULLDEBUG -lm -o /home/c111269/OpenFOAM/c111269-1.7.1/applications/bin/linux64GccDPDebug/cIFp1
Make/linux64GccDPDebug/interFoam.o: In function `main':
/home/c111269/OpenFOAM/c111269-1.7.1/solvers/marking/createFields.H:95: undefined reference to `Foam::multiphase::turbulenceModel::New(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::transportModel&)'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::correct()'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::incompressible::autoCreateLowReNut(Foam::word const&, Foam::fvMesh const&)'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::destroyturbulenceModelConstructorTables()'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::turbulenceModelConstructorTablePtr_'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::turbulenceModel(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::transportModel&)'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::typeName'
/home/c111269/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPDebug/libInterRASModels.so: undefined reference to `Foam::multiphase::turbulenceModel::constructturbulenceModelConstructorTables()'
collect2: ld returned 1 exit status
make: *** [/home/c111269/OpenFOAM/c111269-1.7.1/applications/bin/linux64GccDPDebug/cIFp1] Error 1

If you have any insights, please let me know. Many thanks.

[MartinB]

Hi Robert,

I suppose you must edit your Make/options and add for example
-lincompressibleRASModels \
to the LIB_LIBS settings.

Martin

[AlmostSurelyRob]

Thanks. I have already edited Make/options. Here's what it looks like:

EXE_INC = \
    -I$(LIB_SRC)/transportModels \
    -I$(LIB_SRC)/transportModels/incompressible/lnInclude \
    -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I/home/c111269/OpenFOAM/c111269-1.7.1/src/turbulenceModels/multiphase/turbulenceModel \
    -I$(LIB_SRC)/finiteVolume/lnInclude

EXE_LIBS = \
    -linterfaceProperties \
    -lincompressibleTransportModels \
    -lfiniteVolume \
    -lInterRASModels

[AlmostSurelyRob]

@MartinB: One more thing: the ldd command for libInterRASModels.so gives:

linux-vdso.so.1 =>  (0x00007fff97648000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b85274fc000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b8527824000)
        libgcc_s.so.1 => /applic64/matlabr2010a/sys/os/glnxa64/libgcc_s.so.1 (0x00002b8527a7c000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b8527c89000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b8526fd7000)

and also it is my modification of interFoam that fails to link... So should I really use LIB_LIBS or EXE_LIBS? I understand that the first goes with libraries whilst the latter with executables, but what is the actual difference?

[wyldckat]

Greetings to all!

@Robert: Two possibilities come to mind:

1. You indicated the proper namespace in the header file, but not in the .C code file.
2. You're still including either the .C code or the .H header from the original path to the original turbulent models.

If you could post your changes to that library (without the super turbulence code you're writing) and an example application that should be able to use it, then it should be easier to help you.

Best regards,
Bruno

[AlmostSurelyRob]

Thank you for your comment. Sorry I didn't reply instantaneously. Temporarily I used a workaround by lumping together the code with the library code. It's not very elegant so I am still interested in sorting it out. So if you can spare the time please let me know what you think.

Originally Posted by wyldckat

You indicated the proper namespace in the header file, but not in the .C code file.

I have doubled checked and this is not the case.

Originally Posted by wyldckat

You're still including either the .C code or the .H header from the original path to the original turbulent models.

This is quite possible. How can I check this?

Originally Posted by wyldckat

If you could post your changes to that library (without the super turbulence code you're writing) and an example application that should be able to use it, then it should be easier to help you.

Many thanks for your assistance. The background of my simulation is the following. I wish to simulate multiphase, stratified, flows e.g. liquid/air. Both flow at relatively low velocities and it's an isothermal case. The standard incompressible models give a very large values of turbulence at the interface due to large sheer stress (production term large). This effect is artificially caused by inadequately chosen equations.

Therefore, I wish to dampen turbulence by introducing density rho to my incompressible turbulence model but I don't want to use thermo dynamical models.


I am using interFoam. Turbulence model is invoked only twice:

Initialisation

   autoPtr<multiphase::turbulenceModel> turbulence
    (
            multiphase::turbulenceModel::New(U, rhoPhi, rho, twoPhaseProperties)
    );

and correction

        turbulence->correct();

The only thing I really want to change in the model is inclusion of interface treatment. So far I am doing it through an artificial source term in omega equation of kOmega model.

   tmp<fvScalarMatrix> omegaEqn
    (
        fvm::ddt(rho_, omega_)
      + fvm::div(phi_, omega_)
      - fvm::Sp(fvc::div(phi_), omega_)
      - fvm::laplacian(DomegaEff(), omega_)
     ==
        rho_ * alpha_*G*omega_/k_
      - fvm::Sp(rho_ * beta_*omega_, omega_)
    //interface treatment
      + normrG * beta_ * rho_ * sqr(6 * nu()/ (beta_ * sqr(magDh)))
    );

If you require any additional information please let me know. I would be very obliged for your assistance.

[wyldckat]

Hi Robert,

This is so funny You did the exact opposite of what I asked you I wanted the modifications to the library without the new turbulence model itself

OK, if you can, please pack the code of your modified library into a tarball and attach it to your next post. If not, no problem, we'll try to figure it out just the same


To check if your still linking to the original files, it seems that the only place that there might be some confusion would be in the modified interFoam Make/options file. The original file looks like this:

EXE_INC = \
    -I$(LIB_SRC)/transportModels \
    -I$(LIB_SRC)/transportModels/incompressible/lnInclude \
    -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude \
    -I$(LIB_SRC)/turbulenceModels/incompressible/turbulenceModel \
    -I$(LIB_SRC)/finiteVolume/lnInclude

EXE_LIBS = \
    -ltwoPhaseInterfaceProperties \
    -lincompressibleTransportModels \
    -lincompressibleTurbulenceModel \
    -lincompressibleRASModels \
    -lincompressibleLESModels \
    -lfiniteVolume

If by any chance you still have that line in bold in your modified version, and if it's before the line that includes the folder for the new library code, then that's one of the problems.

Another thing that might be making things difficult is if there are any left overs from the original objects. In other words, when you copied the source code folder, did you run:

wclean all
#or
wclean libso

Or even simply removed the folders that were inside the library's Make folder!?

Best regards,
Bruno

[AlmostSurelyRob]

Hello,

and thanks again for your comments.

Originally Posted by wyldckat

This is so funny You did the exact opposite of what I asked you I wanted the modifications to the library without the new turbulence model itself

That's so embarrassing. Although I have to say that I still don't understand. The library I am writing is actually a library with turbulence models. One super object turbulenceModel and then interface turbulence models below it.

Anyway, thanks for your patience.

Originally Posted by wyldckat

OK, if you can, please pack the code of your modified library into a tarball and attach it to your next post. If not, no problem, we'll try to figure it out just the same

Done!

Originally Posted by wyldckat

To check if your still linking to the original files, it seems that the only place that there might be some confusion would be in the modified interFoam Make/options file. The original file looks like this:

My thoughts exactly. But I have been also reading on the Internet that sometimes this error appears when the libraries are linked in the wrong order. Apparently, the linker goes sequentially through files and discards the files processed. This means that if the library is actually before my application it's going to be discarded since there are no unresolved references yet. I am not sure if this is relevant in the context of wmake.


I have double double checked by running wclean all on both library and application. Alas, it didn't help. Please find the sources attached.

[wyldckat]

Hi Robert,

I was worried about confidentiality issues about the code changes you were making. That's why I was asking for only the stuff that you changed, without the modelling changes themselves.

Originally Posted by AlmostSurelyRob

I have double double checked by running wclean all on both library and application. Alas, it didn't help. Please find the sources attached.

This is good for a good laugh A good laugh because I could probably have made the same mistake myself So many times code I made had a bug due to a missing +1 or -1

OK, what I sometimes do is run ./Allwmake or wmake all two times in a row, because the second run will give me the summary of what went wrong or right. And I got this when running for the library folder:

'/home/me/OpenFOAM/me-1.7.x/lib/linux64GccDPOpt/libInterRASModels.so' is up to date.
'/home/me/OpenFOAM/me-1.7.x/lib/linux64GccDPOpt/libInterRASModels.so' is up to date.

And I thought to myself: «wait, I'm seeing double?»

So I went to check things in the "Make/files" and both RAS and turbulenceModel have:

LIB = $(FOAM_USER_LIBBIN)/libInterRASModels

And then both are built, but only the last one is left to be used. Well, this is one of the problems Either you name them differently or put all of the code into a single library.

I haven't checked the rest of the code, because I'm guessing this was the only problem.

Best regards,
Bruno

[AlmostSurelyRob]

Hello!

Thank you. Your last comment set me on the right track. I was separately compiling two different sets of C files to the same library. So instead of making, say libmultiphaseTurbulenceModels.so and libinterTurbulenceModels.so, and then linking the former to the latter through LIB_LIBS, I was making libinterTurbulenceModels.so twice!

That was not very brilliant of me but you've shown me the light (pun intended ).

Also, I was not concerned with confidentiality issues since the things I implemented so far are in the public domain. Actually, now I have a much more convenient framework to start writings more original things.

Many, many thanks!

[wyldckat]

Hi Robert,

I'm glad I could help

Best regards,
Bruno

[jasonchen]

Hello,

@Robert: currently I'm implementing quite similar turbulence models for two-phase flows. Regarding your statement below, do you have any papers come out? That'll be a good reference for me.

"The standard incompressible models give a very large values of turbulence at the interface due to large sheer stress (production term large). This effect is artificially caused by inadequately chosen equations. Therefore, I wish to dampen turbulence by introducing density rho to my incompressible turbulence model but I don't want to use thermo dynamical models."

@ Bruno: When implementing my own turbulence models, the wall functions related classes will also have to be changed. Otherwise it will complain while lookupObject<RASModel>... If I'm not correct, please correct me. Thanks.

Regards,
Jason

[wyldckat]

Greetings Jason,

Originally Posted by jasonchen

@ Bruno: When implementing my own turbulence models, the wall functions related classes will also have to be changed. Otherwise it will complain while lookupObject<RASModel>... If I'm not correct, please correct me. Thanks.

I think it shouldn't need to re-adapt all wall functions. But I would need an example to prove/check this myself, so if you could provide one, it would be easier to confirm this myself.

I checked this page I saw today: http://openfoamwiki.net/index.php/Ho..._wall_function - and it pointed to this thread: http://www.cfd-online.com/Forums/ope...-function.html - but the instructions there are for OpenFOAM 1.1... so I can only guess that this has changed a lot since 2005/2006.

Best regards,
Bruno

[jasonchen]

Hi Bruno,

I adapted only those wall functions I need, like epsilon, omega, nut. I use of211. I guess the source code directories for RAS and wall functions has changed a lot. Actually I think whether or not to change the wall functions depends on how you implement your own turbulence models. In my case, I renamed RASModel as myRASModel. So every time a lookupObject<RASModel> is called, I have to rename the class name.

Regards,
Jason

[wyldckat]

Hi Jason,

Originally Posted by jasonchen

In my case, I renamed RASModel as myRASModel.

I've never done this myself, but from what I know about OpenFOAM, you should not create a variant named "myRASModel". That enforces you to have to reimplement a ton of code.

I suggest that in this case, you take the easy road: hack directly on OpenFOAM's source code. In addition, I advise you to use OpenFOAM 2.1.x and to learn how to use git: http://git-scm.com/docs/gittutorial

The reason for these two suggestions is simple:

1. You'll get a better relation with OpenFOAM's source code and avoid having to reimplement a ton of code.
2. With git, you can keep track of your changes and later on adapt to newer versions of OpenFOAM, if necessary.

In addition, I advise you to keep both versions, 2.1.1 and 2.1.x, so that you can compare results.
On the other hand, if you truly want to use only OpenFOAM 2.1.1, then have both the Deb/RPM version installed and the source code version installed as well, in order to compare results of simulations. Then use git for keeping track of your changes to the source code.

As for having more than one OpenFOAM version around, read this blog post of mine: Advanced tips for working with the OpenFOAM shell environment

Best regards,
Bruno

[jasonchen]

Originally Posted by wyldckat

The reason for these two suggestions is simple:

1. You'll get a better relation with OpenFOAM's source code and avoid having to reimplement a ton of code.
2. With git, you can keep track of your changes and later on adapt to newer versions of OpenFOAM, if necessary.

In addition, I advise you to keep both versions, 2.1.1 and 2.1.x, so that you can compare results.
Bruno

Hi Bruno,

That's a very easy to alter the code. Thanks for pointing that out for me, as I just try to alter the source code by myself.

I mainly use OF 211 now. It will be a lot easier to compare simulations if the code is altered in the corresponding version of 2.1.x. But do you think is there any need to use OF 2.2.x instead, since this is the newest version?
Thanks

Regards,
Jason

[wyldckat]

Hi Jason,

The advantage of using the latest 2.2.x version are three-fold, as far as I can imagine:

1. It'll be easier to upgrade the code changes, for when the next release of OpenFOAM appears. Otherwise you'll have a bigger jump to perform.
2. I vaguely remember that OpenFOAM 2.2 has some better modular capabilities, although I might be confusing with the thermodynamics part: http://www.openfoam.org/version2.2.0....php#x10-40000
3. Any bugs that you might find, will likely only be fixed on the latest OpenFOAM versions.

Best regards,
Bruno

[AleDR]

Dear All,

I'm just facing a similar problem when implementing an extension to the incompressibleLESModels library which I hope to link to my custom solver. I attach here both folders.

Since my solver needs an additional member function from the turbulenceModel class, I copy/edited the turbulenceModel files and built a custom library called 'libextIncompressibleTurbulenceModel' (and BTW this is a good way to practice library implementation in OF...).

Then I copy/edited the LESModel folder, now keeping only Smagorinsky for simplicity, and built another custom library 'libextIncompressibleLESModels' by linking the one above via LIB_LIBS. Everything seems fine up to this point, and 'ldd' returns a complete list of dependencies, including 'libLESdeltas.so' and 'libLESfilters.so'.
Additionally by 'nm -D libextIncompressibleLESModels.so | grep LESdelta' I have

                 U _ZN4Foam14incompressible8LESdelta3NewERKNS_4wordERKNS_6fvMeshERKNS_10dictionaryE
000000000008b230 V _ZTSN4Foam8LESdeltaE

The problem comes when I try to build the application instancing an object of type 'extTurbulenceModel, since it seems that 'libextIncompressibleLESModels.so' odes not contain any reference to 'LESdelta::New' selector...

/home/ale/OpenFOAM/ale-2.3.x/platforms/linux64GccDPOpt/lib/libextIncompressibleLESModels.so: undefined reference to `Foam::incompressible::LESdelta::New(Foam::word const&, Foam::fvMesh const&, Foam::dictionary const&)'
collect2: error: ld returned 1 exit status
make: *** [/home/ale/OpenFOAM/ale-2.3.x/platforms/linux64GccDPOpt/bin/boxFsCNFoam] Error 1

I am not sure if this comes from the RTS mechanism active in both LESdelta and extLESModel classes, or to some silly mistake in 'options' files...
-> I would be happy to receive your suggestions!

Thanks for your help,

a quite confused Alex.

[floquation]

What exactly is the error you are given?
"ld returned exit status 1" is not the error. The real error is above it.

If the error is "undefined symbol", which I assume it is, as you are giving us 'nm' output, then I have recently had a similar problem.
This was not related to a turbulence model, and I don't think it was related to RTS either.
This problem arose because I declared a virtual destructor in the .H file, but I did not implement it in the .C file (in a class that was going to be instantiated).
For a library, this did not give a compilation error, but linking couldn't be done. (If I recall correctly.)

[AleDR]

Hi Kevin,

and thanks for your quick reply! Actually you pointed me in the right direction...

Problem solved: the issue arising from LESdelta::New was connected to the fact that I incorrectly assumed that LESdelta object would be constructed by using the corresponding libraries... which is NOT what actually happens inside incompressible::LESmodel.
An additional class incompressible::LESdelta is derived from LESdelta (note the nested namespaces) which actually renders the RTS machinery from libLESdeltas available inside libincompressibleLESModels. It is by this mechanism that the "virtual" constructor in the factory are completed in all the details, including the selector for autoPtr<LESdelta> data member inside LESModel.

Thanks again!!

Ciao,
Alex