OpenFOAM - Implement Change To Modelled Term Reynolds Stress Models (LRR & SSG)

dlahaye · February 14, 2024, 07:01

Gotcha.

Quote:

I've also noticed a similar issue compiling the LRR model too

What do you by this sentence?

sr786 · February 14, 2024, 07:22

OpenFOAM failing to compile LRR and outputting error message

Quote:

Originally Posted by sr786

The only deviation is when I compile the SSG model? I've also noticed a similar issue compiling the LRR model too

Code:

 wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file mykinematicMomentumTransportModels.C
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/incompressible/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/transportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/meshTools/lnInclude  -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OSspecific/POSIX/lnInclude   -fPIC -c mykinematicMomentumTransportModels.C -o Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o
In file included from myLRR.H:219:0,
                 from mykinematicMomentumTransportModels.C:49:
myLRR.C: In instantiation of ‘Foam::RASModels::myLRR<BasicMomentumTransportModel>::myLRR(const alphaField&, const rhoField&, const volVectorField&, const surfaceScalarField&, const surfaceScalarField&, const transportModel&, const Foam::word&) [with BasicMomentumTransportModel = Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel>; Foam::RASModels::myLRR<BasicMomentumTransportModel>::alphaField = Foam::geometricOneField; Foam::RASModels::myLRR<BasicMomentumTransportModel>::rhoField = Foam::geometricOneField; Foam::volVectorField = Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>; Foam::surfaceScalarField = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>; Foam::RASModels::myLRR<BasicMomentumTransportModel>::transportModel = Foam::kinematicTransportModel]’:
/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude/RASModel.H:100:9:   required from ‘static Foam::autoPtr<Foam::RASModel<BasicMomentumTransportModel> > Foam::RASModel<BasicMomentumTransportModel>::adddictionaryConstructorToTable<RASModelType>::New(const alphaField&, const rhoField&, const volVectorField&, const surfaceScalarField&, const surfaceScalarField&, const transportModel&) [with RASModelType = Foam::RASModels::myLRR<Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel> >; BasicMomentumTransportModel = Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel>; Foam::RASModel<BasicMomentumTransportModel>::alphaField = Foam::geometricOneField; Foam::RASModel<BasicMomentumTransportModel>::rhoField = Foam::geometricOneField; Foam::volVectorField = Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>; Foam::surfaceScalarField = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>; Foam::RASModel<BasicMomentumTransportModel>::transportModel = Foam::kinematicTransportModel]’
/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude/RASModel.H:100:9:   required from ‘Foam::RASModel<BasicMomentumTransportModel>::adddictionaryConstructorToTable<RASModelType>::adddictionaryConstructorToTable(const Foam::word&) [with RASModelType = Foam::RASModels::myLRR<Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel> >; BasicMomentumTransportModel = Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel>]’
mykinematicMomentumTransportModels.C:50:1:   required from here
myLRR.C:219:14: error: ‘bound’ was not declared in this scope
         bound(epsilon_, this->epsilonMin_);
         ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
myLRR.C:219:14: note: suggested alternative: ‘found’
         bound(epsilon_, this->epsilonMin_);
         ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         found
myLRR.C: In instantiation of ‘void Foam::RASModels::myLRR<BasicMomentumTransportModel>::correct() [with BasicMomentumTransportModel = Foam::IncompressibleMomentumTransportModel<Foam::kinematicTransportModel>]’:
mykinematicMomentumTransportModels.C:50:20:   required from here
myLRR.C:325:10: error: ‘bound’ was not declared in this scope
     bound(epsilon_, this->epsilonMin_);
     ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
myLRR.C:325:10: note: suggested alternative: ‘found’
     bound(epsilon_, this->epsilonMin_);
     ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     found
make: *** [/home/cfd/OpenFOAM/OpenFOAM-9/wmake/rules/General/transform:26: Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o] Error 1

dlahaye · February 14, 2024, 07:29

The output you show is for myLRR.C (emphasis on first two letters).

What happens for the original LRR.C (observe absence of "my")?

sr786 · February 14, 2024, 07:39

LRR.C is already compiled in the source code, I need to compile a new LRR model. Changing the name from LRR.C to myLRR.C shouldn't be the root cause of the issue because I've done the same for kOmega.C to mykOmega.C with zero incidence.

sr786 · February 14, 2024, 07:52

Okay I appear to have resolved the compilation issue but I'm unsure why.

In the .H file, I commented out the final few lines

Code:

//#ifdef NoRepository
//    #include "myLRR.C"
//#endif

This resulted in successful compilation:

Code:

 wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file mykinematicMomentumTransportModels.C
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/cfd/OpenFOAM/OpenFOAM-9/src/transportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/meshTools/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/incompressible/lnInclude  -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OSspecific/POSIX/lnInclude   -fPIC -c mykinematicMomentumTransportModels.C -o Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/cfd/OpenFOAM/OpenFOAM-9/src/transportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/meshTools/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/incompressible/lnInclude  -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OSspecific/POSIX/lnInclude   -fPIC -fuse-ld=bfd -shared -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o -L/home/cfd/OpenFOAM/OpenFOAM-9/platforms/linux64GccDPInt32Opt/lib \
    -ltransportModels -lmomentumTransportModels -lfiniteVolume -lmeshTools  -o /home/cfd/OpenFOAM/OpenFOAM-9/platforms/linux64GccDPInt32Opt/lib/mykinematicMomentumTransportModels.so

dlahaye · February 14, 2024, 08:01

Your goal is clear to me.

The way you reason about reaching that goal is *not* yet entirely clear to me.

The compiler tells you that it is looking for the symbol bound.o. It is therefore likely that when compiling myLRR.C, some header files (*.H files) are missing.

Four questions thus emerge:

1/ what header files are required to compile the original unmodified LRR.C file?

2/ does the command "nm -g LRR.o" show the presence of the symbol LRR.o?

3/ are the files LRR.C and myLRR.C the same?

4/ how do the compilation of LRR.C and myLRR.C differ?

Good luck. Domenico.

sr786 · February 14, 2024, 08:11

Hi,

No worries just seen your edit. Yeah it appears someone has already tried this approach before with compilation issues, i.e., error message in terminal, and has resolved them.

Please refer to video by trushar gobil, minute 19:55 https://www.youtube.com/watch?v=kfsh...t_aqf&index=14

sr786 · February 14, 2024, 09:21

Okay,

Now I'm trying to run the new LRR model (without modifying code) to see if it works. I get the following error message:

Code:

 simpleFoam: symbol lookup error: /home/cfd/OpenFOAM/OpenFOAM-9/platforms/linux64GccDPInt32Opt/lib/libsimpleLRRMomentumTransportModels.so: undefined symbol: _ZN4Foam9RASModels9simpleLRRINS_36IncompressibleMomentumTransportModelINS_23kinematicTransportModelEEEEC1ERKNS_17geometricOneFieldES8_RKNS_14GeometricFieldINS_6VectorIdEENS_12fvPatchFieldENS_7volMeshEEERKNS9_IdNS_13fvsPatchFieldENS_11surfaceMeshEEESL_RKS3_RKNS_4wordE

Tobermory · February 14, 2024, 12:59

Very strange - I have just tested it on my implementation (Foundation, v8) and it works fine - I didn't have to comment out the lines that you highlighted. Must be a problem with v9. Can you use v8?

PS - just in passing - I note that you are editing your version of the LRR models etc in the OF distribution folder, rather than under your user directory. This is really dangerous, since you can unwittingly overwrite something in the OF distribution. I'd strongly suggest you using the USER folder ... i.e. create $FOAM_RUN/../src, $FOAM_RUN/../applications and compile any libraries and apps into $FOAM_LIBBIN and $FOAM_APPBIN. Your choice though.

sr786 · February 14, 2024, 13:22

Hi,

Thank you for the suggestions! I thought I was modifying the code in the user directory as I pulled all the relevant files (.C .H, Make, etc) in a separate folder where I run all my simulations and not the src file in the OpenFOAM folders

Also, could I have access to your setup? I want to see if I can get it to run on OPENFOAM-9.

Tobermory · February 14, 2024, 13:26

Aaah okay - then it's just that you are dumping your final library in the distribution folder. My Make/files is:

Code:

myKinematicMomentumTransportModels/myKinematicMomentumTransportModels.C
LIB = $(FOAM_USER_LIBBIN)/libmyIncompressibleMomentumTransportModels

(note the use of FOAM_USER_LIBBIN) and my Make/options is:

Code:

EXE_INC = \
    -I../momentumTransportModels/lnInclude \
    -I$(LIB_SRC)/transportModels/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude \
    -I$(LIB_SRC)/MomentumTransportModels/momentumTransportModels/lnInclude \
    -I$(LIB_SRC)/MomentumTransportModels/incompressible/lnInclude \
    -I$(LIB_SRC)/MomentumTransportModels/incompressible/kinematicMomentumTransportModels \
    
LIB_LIBS = \
    -lincompressibleTransportModels \
    -lmomentumTransportModels \
    -lfiniteVolume \
    -lmeshTools

All the best.

sr786 · February 14, 2024, 14:50

Hi,

I've tried out with your set-up. It doesn't appear to work for me at all. I appreciate your help, just seems to be going wrong for me for some reason.

sr786 · February 15, 2024, 08:28

I've tried it out with OpenFOAM-10 using the same strategy. Find the same situation where mykOmega or mykEpsilon compiles perfectly and myLRR or mySSG fail to compile.

sr786 · February 15, 2024, 09:47

I've even tried other models such as LaunderSharmaKE which also work fine. It seems OpenFOAM can compile anything but the LRR and SSG models.

Compilation:

Code:

 wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file mykinematicMomentumTransportModels.C
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/incompressible/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/transportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/meshTools/lnInclude  -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OSspecific/POSIX/lnInclude   -fPIC -c mykinematicMomentumTransportModels.C -o Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/MomentumTransportModels/incompressible/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/transportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/meshTools/lnInclude  -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-9/src/OSspecific/POSIX/lnInclude   -fPIC -fuse-ld=bfd -shared -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/mykinematicMomentumTransportModels.o -L/home/cfd/OpenFOAM/OpenFOAM-9/platforms/linux64GccDPInt32Opt/lib \
    -ltransportModels -lmomentumTransportModels -lfiniteVolume -lmeshTools  -o /home/cfd/OpenFOAM/cfd-9/platforms/linux64GccDPInt32Opt/lib/mykinematicMomentumTransportModels.so

Options

Code:

 EXE_INC = \
    -I$(LIB_SRC)/MomentumTransportModels/momentumTransportModels/lnInclude \
    -I$(LIB_SRC)/MomentumTransportModels/incompressible/lnInclude \
    -I$(LIB_SRC)/transportModels/lnInclude \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude \

LIB_LIBS = \
    -ltransportModels \
    -lmomentumTransportModels \
    -lfiniteVolume \
    -lmeshTools

Files

Code:

 mykinematicMomentumTransportModels.C


LIB = $(FOAM_USER_LIBBIN)/mykinematicMomentumTransportModels

sr786 · February 16, 2024, 08:51

Appear to have resolved issue. Spoke to someone with experience in modifying source code for OpenFOAM. For myLRR.C file had to include a bound.C file in order to successfully compile.

Code:

#include "myLRR.H"
#include "fvModels.H"
#include "fvConstraints.H"
#include "wallDist.H"
#include "bound.C

This resulted in myLRR being successfully recognised

Code:

 SIMPLE: Convergence criteria found
        U: tolerance 1e-05
        p: tolerance 1e-05
        k: tolerance 1e-05
        epsilon: tolerance 1e-05
        R: tolerance 1e-05
        omega: tolerance 1e-05

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model myLRR
RAS
{
    model           myLRR;
    turbulence      on;
    printCoeffs     on;
    couplingFactor  0;
    Cmu             0.09;
    C1              1.8;
    C2              0.6;
    Ceps1           1.44;
    Ceps2           1.92;
    Cs              0.25;
    Ceps            0.15;
    wallReflection  true;
    kappa           0.41;
    Cref1           0.5;
    Cref2           0.3;
}

Creating MRF zone list from MRFProperties
    creating MRF zone: SRF
No fvModels present
No fvConstraints present

Starting time loop

Tobermory · February 16, 2024, 08:51

Well, I can confirm that I get the same error message as you (complaining about bound being out of scope) in my implementation of v10, so it's not your setup that is at fault.

I spent 10mins looking at this and managed to get LRR to compile with the simple expedient of adding:

Code:

#include "bound.H"

after the other include declarations at the top of my version of LRR.C. This compiled and ran, albeit with a bunch of warnings about duplicate hash table entries ... I haven't had a chance to sort them out, and this clearly is not the pukka way to resolve your problem, but it might allow you to get up and running in the meantime.

Tobermory · February 16, 2024, 08:52

Quote:

Originally Posted by sr786

Appear to have resolved issue. Spoke to someone with experience in modifying source code for OpenFOAM. For myLRR.C file had to include a bound.C file in order to successfully compile.

Code:

#include "simpleLRR.H"
#include "fvModels.H"
#include "fvConstraints.H"
#include "wallDist.H"
#include "bound.C

This resulted in myLRR being successfully recognised

Code:

 SIMPLE: Convergence criteria found
        U: tolerance 1e-05
        p: tolerance 1e-05
        k: tolerance 1e-05
        epsilon: tolerance 1e-05
        R: tolerance 1e-05
        omega: tolerance 1e-05

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model myLRR
RAS
{
    model           myLRR;
    turbulence      on;
    printCoeffs     on;
    couplingFactor  0;
    Cmu             0.09;
    C1              1.8;
    C2              0.6;
    Ceps1           1.44;
    Ceps2           1.92;
    Cs              0.25;
    Ceps            0.15;
    wallReflection  true;
    kappa           0.41;
    Cref1           0.5;
    Cref2           0.3;
}

Creating MRF zone list from MRFProperties
    creating MRF zone: SRF
No fvModels present
No fvConstraints present

Starting time loop

Haha - you posted the same fix at exactly the same time as me!

sr786 · February 16, 2024, 10:48

Hi Tobermory,

I want to thank you and dlahaye so much for your patience.

I have managed to get simpleLRR (changed name from myLRR) to run with my modifications. It was really simple, all I did was simplify DREff() and DepsEff() based on this paper by Lien & Leschnizer (1994) https://doi.org/10.1016/0045-7930(94)90001-9.

The new terms are

Code:

 template<class BasicMomentumTransportModel>
tmp<volScalarField> simpleLRR<BasicMomentumTransportModel>::DREff() const
{
    return volScalarField::New
    (
        "DREff",
        (this->nut_/sigmak_ + this->nu())
    );
}


template<class BasicMomentumTransportModel>
tmp<volScalarField> simpleLRR<BasicMomentumTransportModel>::DepsilonEff() const
{
    return volScalarField::New
    (
        "DepsilonEff",
        (this->nut_/sigmaEps_ + this->nu())
    );
}

Where I have added new constant terms sigmak (0.82) and sigmaEps_ (1). Also as I removed the R term to simplify the equations I had to change from symmtensor to scalar in both .C and .H files. This is very similar in principle to how diffusivities are defined in a eddy viscosity model such as kEpsilon.

Tobermory · February 16, 2024, 10:50

Well done!

sr786 · February 16, 2024, 10:54

My only one uncertainty is the terminal spits out the following warning when doing a parallel run (serial run no warning shows up):

Code:

 --> FOAM Warning : 

    From function void* Foam::dlOpen(const Foam::fileName&, bool)

    in file POSIX.C at line 1247

    dlopen error : /home/cfd/OpenFOAM/cfd-9/platforms/linux64GccDPInt32Opt/lib/libsimpleLRRMomentumTransportModels.so: undefined symbol: _ZTIN4Foam36incompressibleMomentumTransportModelE

--> FOAM Warning : 

    From function bool Foam::dlLibraryTable::open(const Foam::fileName&, bool)

    in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 106

    could not load "libsimpleLRRMomentumTransportModels.so"

This warning does not appear to influence the simulation run as it still recognises simpleLRR and will run (i.e., it doesn't stop simulating) and someone commented that he got something similar https://www.reddit.com/r/OpenFOAM/co...ryso_warnings/ and he suggested the warning signs didn't make any difference as he could still run his simulations.. Is there anyway to get rid of these warnings. I've cleaned all my libraries from test cases so only the simpleLRR is running.

February 14, 2024, 08:01		#26
dlahaye Senior Member Domenico Lahaye Join Date: Dec 2013 Posts: 798 Blog Entries: 1 Rep Power: 17	Your goal is clear to me. The way you reason about reaching that goal is not yet entirely clear to me. The compiler tells you that it is looking for the symbol bound.o. It is therefore likely that when compiling myLRR.C, some header files (.H files) are missing. Four questions thus emerge: 1/ what header files are required to compile the original unmodified LRR.C file? 2/ does the command "nm -g LRR.o" show the presence of the symbol LRR.o? 3/ are the files LRR.C and myLRR.C the same? 4/ how do the compilation of LRR.C and myLRR.C differ? Good luck. Domenico. Last edited by dlahaye; February 14, 2024 at 08:03. Reason: Pls ignore this message. Issue resolved. Congrats!*

February 16, 2024, 10:48		#38
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	Hi Tobermory, I want to thank you and dlahaye so much for your patience. I have managed to get simpleLRR (changed name from myLRR) to run with my modifications. It was really simple, all I did was simplify DREff() and DepsEff() based on this paper by Lien & Leschnizer (1994) https://doi.org/10.1016/0045-7930(94)90001-9. The new terms are Code: template<class BasicMomentumTransportModel> tmp<volScalarField> simpleLRR<BasicMomentumTransportModel>::DREff() const { return volScalarField::New ( "DREff", (this->nut_/sigmak_ + this->nu()) ); } template<class BasicMomentumTransportModel> tmp<volScalarField> simpleLRR<BasicMomentumTransportModel>::DepsilonEff() const { return volScalarField::New ( "DepsilonEff", (this->nut_/sigmaEps_ + this->nu()) ); } Where I have added new constant terms sigmak (0.82) and sigmaEps_ (1). Also as I removed the R term to simplify the equations I had to change from symmtensor to scalar in both .C and .H files. This is very similar in principle to how diffusivities are defined in a eddy viscosity model such as kEpsilon. Tobermory likes this.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Map of the OpenFOAM Forum - Understanding where to post your questions!	wyldckat	OpenFOAM	10	September 2, 2021 06:29
STATEMENT about how to implement new turbulent models in OpenFOAM	PeterShi	OpenFOAM Running, Solving & CFD	0	February 28, 2017 08:18
Suggestion for a new sub-forum at OpenFOAM's Forum	wyldckat	Site Help, Feedback & Discussions	20	October 28, 2014 10:04
Reynolds Stress Model in OpenFOAM	harsha_kulkarni	OpenFOAM Pre-Processing	0	August 3, 2014 03:23
How the trace term of SGS stress tensor implemented in Openfoam	star shower	OpenFOAM Running, Solving & CFD	0	March 3, 2012 09:56

February 14, 2024, 07:29		#23
dlahaye Senior Member Domenico Lahaye Join Date: Dec 2013 Posts: 798 Blog Entries: 1 Rep Power: 17	The output you show is for myLRR.C (emphasis on first two letters). What happens for the original LRR.C (observe absence of "my")?

February 14, 2024, 07:39		#24
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	LRR.C is already compiled in the source code, I need to compile a new LRR model. Changing the name from LRR.C to myLRR.C shouldn't be the root cause of the issue because I've done the same for kOmega.C to mykOmega.C with zero incidence.

February 14, 2024, 08:11		#27
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	Hi, No worries just seen your edit. Yeah it appears someone has already tried this approach before with compilation issues, i.e., error message in terminal, and has resolved them. Please refer to video by trushar gobil, minute 19:55 https://www.youtube.com/watch?v=kfsh...t_aqf&index=14

February 14, 2024, 12:59		#29
Tobermory Senior Member Join Date: Apr 2020 Location: UK Posts: 737 Rep Power: 14	Very strange - I have just tested it on my implementation (Foundation, v8) and it works fine - I didn't have to comment out the lines that you highlighted. Must be a problem with v9. Can you use v8? PS - just in passing - I note that you are editing your version of the LRR models etc in the OF distribution folder, rather than under your user directory. This is really dangerous, since you can unwittingly overwrite something in the OF distribution. I'd strongly suggest you using the USER folder ... i.e. create $FOAM_RUN/../src, $FOAM_RUN/../applications and compile any libraries and apps into $FOAM_LIBBIN and $FOAM_APPBIN. Your choice though.

February 14, 2024, 13:22		#30
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	Hi, Thank you for the suggestions! I thought I was modifying the code in the user directory as I pulled all the relevant files (.C .H, Make, etc) in a separate folder where I run all my simulations and not the src file in the OpenFOAM folders Also, could I have access to your setup? I want to see if I can get it to run on OPENFOAM-9.

February 14, 2024, 14:50		#32
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	Hi, I've tried out with your set-up. It doesn't appear to work for me at all. I appreciate your help, just seems to be going wrong for me for some reason.

February 15, 2024, 08:28		#33
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	I've tried it out with OpenFOAM-10 using the same strategy. Find the same situation where mykOmega or mykEpsilon compiles perfectly and myLRR or mySSG fail to compile.

February 16, 2024, 08:51		#36
Tobermory Senior Member Join Date: Apr 2020 Location: UK Posts: 737 Rep Power: 14	Well, I can confirm that I get the same error message as you (complaining about bound being out of scope) in my implementation of v10, so it's not your setup that is at fault. I spent 10mins looking at this and managed to get LRR to compile with the simple expedient of adding: Code: #include "bound.H" after the other include declarations at the top of my version of LRR.C. This compiled and ran, albeit with a bunch of warnings about duplicate hash table entries ... I haven't had a chance to sort them out, and this clearly is not the pukka way to resolve your problem, but it might allow you to get up and running in the meantime.

February 16, 2024, 10:50		#39
Tobermory Senior Member Join Date: Apr 2020 Location: UK Posts: 737 Rep Power: 14	Well done!

February 16, 2024, 10:54		#40
sr786 Member ASR Join Date: Jan 2023 Location: Leeds, UK Posts: 52 Rep Power: 3	My only one uncertainty is the terminal spits out the following warning when doing a parallel run (serial run no warning shows up): Code: --> FOAM Warning : From function void* Foam::dlOpen(const Foam::fileName&, bool) in file POSIX.C at line 1247 dlopen error : /home/cfd/OpenFOAM/cfd-9/platforms/linux64GccDPInt32Opt/lib/libsimpleLRRMomentumTransportModels.so: undefined symbol: _ZTIN4Foam36incompressibleMomentumTransportModelE --> FOAM Warning : From function bool Foam::dlLibraryTable::open(const Foam::fileName&, bool) in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 106 could not load "libsimpleLRRMomentumTransportModels.so" This warning does not appear to influence the simulation run as it still recognises simpleLRR and will run (i.e., it doesn't stop simulating) and someone commented that he got something similar https://www.reddit.com/r/OpenFOAM/co...ryso_warnings/ and he suggested the warning signs didn't make any difference as he could still run his simulations.. Is there anyway to get rid of these warnings. I've cleaned all my libraries from test cases so only the simpleLRR is running.