CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Custom Boundary Condition with OpenFOAM (https://www.cfd-online.com/Forums/openfoam-programming-development/72434-custom-boundary-condition-openfoam.html)

trusharg February 5, 2010 07:54

Custom Boundary Condition with OpenFOAM
 
Hi

I am, new user of OpenFOAM.
I want to apply user defined boundary conditions.

I want to solve free jet problem and for that at the inlet I want to apply some following function at every time steps.

u(r,t)=u_profile(r)+u_noise(r,t)+u_forced(r,t)

u_profile(r)=(U_inlet/2)(1+tanh(R-r/2theta))
u_noise(r,t) is generate random noise
u_forced(r,t)=A*u_profile(r)sin(2piSt_d*U_inlet*t)

If any one have idea about implementation of user define BC, please guide me for this.

With Regards
Trushar

marupio February 11, 2010 15:20

1. Choose a boundary condition that is close, and copy the directory contents to anywhere (say run/myCode). oscillatingFvPatchField might be a good one to start with.

2. Rename all the copied files to a new name (say customJetPatchField or something).

3. Search & replace all text in all the new files old name for new name (oscillatingFvPatchField replaced with customJetPatchField)

4. Modify the code to suit your needs. (How's your C++?)

5. Create the directory structure: myCode/Make, and create files and options in it.

6. Under files, define the main source file (look under finiteVolume/Make/files, and copy / rename the relevant entry from the patch field you copied). Also tell it what the new library name will be. Use $(FOAM_USER_LIBBIN) instead of $(FOAM_LIBBIN). It should look something like:
customJetPatchFields.C

LIB = $(FOAM_USER_LIBBIN)/libcustomJetPatchField


7. The options file should have EXE_INC (for any includes such as finiteVolume) and LIB_LIBS (for included libraries, again finite Volume). Look at other LIB_LIBS for examples. Should probably look like:
EXE_INC = \
-I$(LIB_SRC)/finiteVolume/lnInclude

LIB_LIBS = \
-lfiniteVolume

etc..

8. $wmake libso customJetPatchField

9. Add whatever new dictionary entries are needed to your 0/U and 0/P files.

10. Add libs ( "libcustomJetPatchField" ) to controlDict

11. It should run now.

Common mistakes are not linking the correct file in Make/files. It isn't the one you might think. Remember to copy what finiteVolume/Make/files does for the patch field you chose. Another mistake is forgetting the libso in wmake. Good luck!

trusharg February 11, 2010 22:29

Thanks David Gaden

With help of contributed groovyBC I am manage to implement required boundary condition.

Trushar

rassilon February 14, 2010 17:25

Hi Trushar, David,

I am also trying to create a new boundary condition, and have been experimenting with editing and compiling an existing condition. At the moment I am just trying to change the name of a condition - nothing more - as a proof of concept of being able to edit and compile.

I have been using the following method to make a statically linked solver and boundary condition 'package'

1. Make a copy of my case folder

2. Copy my solver (interFoam) into my case folder ($OpenFOAM/apps/case/interFoam)

3. Copy the contents of the boundary condition I am trying to rename into the solver folder (timeVaryingFixedUniformFixedValue)

4. Rename the solver folder (myInterFoam)

5. In the myInterFoam folder, rename the following files:
timeVaryingFixedUniformFixedValueFvPatchField.C -> myTimeVaryingFixedUniformFixedValueFvPatchField.C
timeVaryingFixedUniformFixedValueFvPatchField.H -> myTimeVaryingFixedUniformFixedValueFvPatchField.H
timeVaryingFixedUniformFixedValueFvPatchFields.C -> myTimeVaryingFixedUniformFixedValueFvPatchFields.C
timeVaryingFixedUniformFixedValueFvPatchFields.H -> myTimeVaryingFixedUniformFixedValueFvPatchFields.H
timeVaryingFixedUniformFixedValueFvPatchFieldsFwd. H -> myTimeVaryingFixedUniformFixedValueFvPatchFieldsFw d.H

6. Edit the files using a text editor, replacing all instances of timeVaryingUniformFixedValue with myTimeVaryingUniformFixedValue

7. Add the following to the second line of the Make/files file:
myTimeVaryingFixedUniformFixedValueFvPatchField.C
timeVaryingFixedUniformFixedValueFvPatchFields.C

8. Modify the final line so that it reads:
EXE = $(FOAM_USER_APPBIN)/myInterFoam

9. Add the following to the header of the interFoam.C file:
myTimeVaryingFixedUniformFixedValueFvPatchField.H
myTimeVaryingFixedUniformFixedValueFvPatchFields.H

10. Compile using:
wclean
rm -rf Make/linux*
wmake

I have got this method to work for a simple boundary condition (totalPressure), but when I attempt to compile this more complex boundary condition, I receive numerous instances of the following error:

Quote:

myTimeVaryingUniformFixedValueFvPatchField.C:38: error: redefinition of ‘Foam::myTimeVaryingUniformFixedValueFvPatchField< Type>::myTimeVaryingUniformFixedValueFvPatchField( const Foam::fvPatch&, const Foam: DimensionedField<Type, Foam::volMesh>&)’
myTimeVaryingUniformFixedValueFvPatchField.C:38: error: ‘Foam::myTimeVaryingUniformFixedValueFvPatchField< Type>::myTimeVaryingUniformFixedValueFvPatchField( const Foam::fvPatch&, const Foam: DimensionedField<Type, Foam::volMesh>&)’ previously declared here
What am I doing wrong? Is there something that I am missing when I am editing my boundary condition files by hand prior to compiling? Would I have better luck if I tried linking my BC dynamically instead of statically?

Any pointers would be greatly appreciated!


R

marupio February 15, 2010 11:41

You don't need to copy the solver - unless you are making changes to the solver itself. Only copy the boundary condition you want to change. So forget all the Make/files and Make/options from the solver.

Your Make/files for the boundary condition only needs one target. In this case it's

myTimeVaryingUniformFixedValueFvPatchFields.C

Follow the steps I posted for the Make/files and Make/options. When you compile, it's:
wmake libso

Don't forget to include in the controlDict file:
libs ( "libmyTimeVaryingUniformFixedValueFvPatchField " )
(or whatever you called the library .so file)

Hopefully that helps!

rassilon February 16, 2010 21:11

Quote:

Originally Posted by marupio (Post 246094)
You don't need to copy the solver - unless you are making changes to the solver itself. Only copy the boundary condition you want to change. So forget all the Make/files and Make/options from the solver.

Your Make/files for the boundary condition only needs one target. In this case it's

myTimeVaryingUniformFixedValueFvPatchFields.C

Follow the steps I posted for the Make/files and Make/options. When you compile, it's:
wmake libso

Don't forget to include in the controlDict file:
libs ( "libmyTimeVaryingUniformFixedValueFvPatchField " )
(or whatever you called the library .so file)

Hopefully that helps!

Hi David,

Thanks for your help. I have managed to successfully compile my new boundary condition, and have got it running to convergence. I have noticed some strangeness in post processing the results however. When I invoke paraFoam I receive the following error in the terminal:

Quote:

created temporary 'test_case.OpenFOAM'
--> FOAM Warning :
From function dlLibraryTable::open(const fileName& functionLibName)
in file db/dlLibraryTable/dlLibraryTable.C at line 79
could not load /home/nathan/OpenFOAM/nathan-1.6/lib/linux64GccDPOpt/libmyTimeVaryingUniformFixedValue.so: undefined symbol: _ZTIN4Foam5token8compoundE
though Paraview does run, and does render the results as if the case had been run using the original Boundary Condition (timeVaryingUniformFixedValue).

Also, I receive the following error when invoking paraFoam:

Quote:

Cannot find 'value' entry on patch wall-heater of field p in file "/home/rassilon/solver_package_tests/test_case/0/p"
which is required to set the values of the generic patch field.
(Actual type myTimeVaryingUniformFixedValue)

Please add the 'value' entry to the write function of the user-defined boundary-condition
or link the boundary-condition into libfoamUtil.so

file: /home/rassilon/solver_package_tests/test_case/0/p::wall-heater from line 59 to line 61.

From function genericFvPatchField<Type>::genericFvPatchField(con st fvPatch&, const Field<Type>&, const dictionary&)
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 72.

FOAM exiting
But have been able to overcome this by adding a dummy value line to the 0/p file for my new Boundary Condition.

I guess that if this is an exact copy of an existing BC, then I shouldn't be experiencing these errors, or are they to be expected?


R

marupio February 16, 2010 21:29

Good job on getting it to run!

I'm guessing paraView doesn't know about that boundary condition (and is probably trying to apply a 'generic' type) and is falling on its face.

Try adding OpenFOAM to the list of libraries you're including (in controlDict):

libs ( "libmyTimeVaryingUniformFixedValueFvPatchField .so" "libOpenFOAM.so" )

If that doesn't work... I'm not sure what else to do... I might try exporting to a different post processor... or bumping this to the rest of the folks in the OpenFOAM community.

-Dave

marupio February 26, 2010 12:05

I've adapted this into the wiki.
http://openfoamwiki.net/index.php/Ho...dary_condition

nishant_hull May 25, 2010 12:32

Hi David,

I am trying to implement a forced boundary condition on the inlet. I have used this piece of code-

label patchI = mesh.boundaryMesh().findPatchID("inlet");
const fvPatchVectorField& patchU = U.boundaryField()[patchI];
const labelList inletFc = patchU.patch().faceCells();
const vectorField inletCf = patchU.patch().Cf();

to access the centre of the inlet patch co-ordinates in the createFields.H file. However, I want to access it in my boundary patch code (e.g. timeVaryingFixedValue) to force a specific co-related pattern at the inlet every time-step. On compilation the error says that the variable "inletCf" is not defined in the same scope.
Do you have any idea whay it is?
Actually I want to access the inlet patch space co-ordinates and there I am having trouble finding the x,y and z co-ordinate of the inlet patch points.
Any hint will be appreciated.

Thansk & regards,

Nishant

marupio May 25, 2010 14:48

Are you trying to get the geometry of the fvPatchField itself? It should know itself... I think you get a reference to the patch using patch(). Have a look at parabolicVelocityFvPatchVectorField. That one probably also needs to "get" its own geometry.

Good luck!

trusharg May 25, 2010 22:37

In my case I put it like this way and its work fine:

label inletPatchID = mesh.boundaryMesh().findPatchID("in");
const fvsPatchVectorField& centre = mesh.Cf().boundaryField()[inletPatchID];
const fvsPatchVectorField& normal = mesh.Sf().boundaryField()[inletPatchID];
fvPatchVectorField& uu = U.boundaryField()[inletPatchID];

David_010 May 26, 2010 05:24

Hi David

Thanks for the help about how to create a new boundary condition. In my case, I need to create a boundary condition which makes cyclic the temperature gradient between two surfaces, in a solid region. I have thought in do it from the cyclic boundary condition, but my C++ knowledge is limited. Do you think it is possible? I imagine that I have to specify that the variable to be cycled will be snGrad(T) instead of T.

Thanks a lot for your help

Regards

David

nishant_hull May 26, 2010 08:20

Quote:

Originally Posted by trusharg (Post 260259)
In my case I put it like this way and its work fine:

label inletPatchID = mesh.boundaryMesh().findPatchID("in");
const fvsPatchVectorField& centre = mesh.Cf().boundaryField()[inletPatchID];
const fvsPatchVectorField& normal = mesh.Sf().boundaryField()[inletPatchID];
fvPatchVectorField& uu = U.boundaryField()[inletPatchID];



Hi Trushar,

Thanks for the reply. Did you use this piece of code in the createFields.H file or did you use it in the boundary condition file (like timeVaryingFvpatch.C file)?
If you have used this code in the createFields.H file then could you be able to use the "centre" vector field in the boundary condition file (like timeVaryingFvpatch.C file)?

Thanks & regards,

Nishant

trusharg May 26, 2010 11:38

HI Nishant

I use it directly in the main solver. Like in my case I modify the icoFOAM and put this code into it.

Trushar

nishant_hull June 8, 2010 20:56

Hi Trushar,

I have implemented the boundary condition now but there are some problem I am having while running. After few hundred iterations in a channel test case, I am having these errors:

Maximum number of iterations exceeded#0 Foam::error::printStack(Foam::Ostream&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 Foam::hPsiThermo<Foam::pureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::calculate() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#3 Foam::hPsiThermo<Foam::pureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::correct() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#4
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"
#5 __libc_start_main in "/lib/libc.so.6"
#6
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"


From function specieThermo<thermo>::T(scalar f, scalar T0, scalar (specieThermo<thermo>::*F)(const scalar) const, scalar (specieThermo<thermo>::*dFdT)(const scalar) const) const
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.6/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 68.

FOAM aborting

Can you please tell me how to get rid of such problems? I assume you might have come across such problems at some stage. Any help in this regard will be deeply appreciated.

Thanks & regards,

Nishant

trusharg June 8, 2010 23:08

Hi Nishant

Can you check, what is the Courant Number when you got that error. I think it is due to the delta T so try to lower the delta T.

Also tell me which solver are you using for pressure?

Trushar

nishant_hull June 9, 2010 10:40

Quote:

Originally Posted by trusharg (Post 262202)
Hi Nishant

Can you check, what is the Courant Number when you got that error. I think it is due to the delta T so try to lower the delta T.

Also tell me which solver are you using for pressure?

Trushar


Hi Trushar,

Thanks for the reply. I always check for courant number in such cases of error (specialy in compressible solver) but i think courant number is well within the limit. I even tried lowering the deltaT further down but with no success!
The pressure solver I am using is:
p
{
solver PCG;
preconditioner DIC;
tolerance 1e-06;
relTol 0;
}
The last iteration looks like this:

diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Ux, Initial residual = 0.00131998, Final residual = 7.85936e-08, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.00207584, Final residual = 1.27814e-07, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.00657929, Final residual = 9.48049e-07, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.00250624, Final residual = 4.06934e-08, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.00276642, Final residual = 2.94016e-09, No Iterations 1
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 2.77896e-10, global = 9.5837e-11, cumulative = 7.18337e-09
DILUPBiCG: Solving for h, Initial residual = 8.89116e-05, Final residual = 8.89116e-05, No Iterations 0

As you can see the last iteration stops at h (which also gives acceptable value). The solver for h is:
h
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-04;
relTol 0;
}

Thanks & regards,

Nishant

nishant_hull June 9, 2010 13:45

Hi Trushar,

After some modifications, I am getting this error:

time step continuity errors : sum local = 6.07738e-06, global = -2.00825e-07, cumulative = -1.65828e-07
#0 Foam::error::printStack(Foam::Ostream&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::sqrt(Foam::tmp<Foam::Field<double> > const&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#5 Foam::compressible::LESModels::vanDriestDelta::cal cDelta() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libcompressibleLESModels.so"
#6 Foam::compressible::LESModels::oneEqEddy::correct( Foam::tmp<Foam::GeometricField<Foam::Tensor<double >, Foam::fvPatchField, Foam::volMesh> > const&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libcompressibleLESModels.so"
#7 Foam::compressible::LESModel::correct() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libcompressibleLESModels.so"
#8
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"
#9 __libc_start_main in "/lib/libc.so.6"
#10
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"
Floating point exception

Have you come across anything like this? I wonder why there is floating point error in LESmodels??? Any idea, if you can assist me here please?

Thanks & regards,

Nishant

ovie June 9, 2010 15:00

My guess is that your boundary conditions for pressure are not consistent with the problem.

How have you implemented our pressure bcs?

nishant_hull June 10, 2010 13:19

Quote:

Originally Posted by ovie (Post 262339)
My guess is that your boundary conditions for pressure are not consistent with the problem.

How have you implemented our pressure bcs?

Hi Ovie
Thanks for reply. The pressure boundary condition is as follows:

inlet
{
type inletOutlet;
inletValue uniform 1e5;
value uniform 1e5;
}

outlet
{
type waveTransmissive;
field p;
phi phi;
rho rho;
psi psi;
gamma 1.3;
fieldInf 1e5;
lInf 0.3;
value uniform 1e5;
}


Thanks & regards,

Nishant

ovie June 10, 2010 21:04

Quote:

Originally Posted by nishant_hull (Post 262509)
Hi Ovie
Thanks for reply. The pressure boundary condition is as follows:

inlet
{
type inletOutlet;
inletValue uniform 1e5;
value uniform 1e5;
}

outlet
{
type waveTransmissive;
field p;
phi phi;
rho rho;
psi psi;
gamma 1.3;
fieldInf 1e5;
lInf 0.3;
value uniform 1e5;
}


Thanks & regards,

Nishant


I actually had a similar experience today simulating a falling film using interFoam with the MULES explicit solver for alpha1. I am not quite certain but the pressure might not really be the problem. In my case, the time step kept shrinking SO I switched to the MULES::Implicit solver and the error message stopped.

I dont know if reducing the CN for the explicit solver might help though but I intend to experiment with that as well and see how low I can go before the solution becomes stable.

ovie June 11, 2010 12:58

Hi nishant,

The floating point exception error usually results from illegal algebraic operations. You may check these links on the forum to see if they could shed any light:
http://www.cfd-online.com/Forums/ope...exception.html.
http://openfoamwiki.net/index.php/HowTo_debugging

Typically such errors are a consequence of wrong bcs primarily.

nishant_hull June 11, 2010 20:45

Quote:

Originally Posted by ovie (Post 262662)
Hi nishant,

The floating point exception error usually results from illegal algebraic operations. You may check these links on the forum to see if they could shed any light:
http://www.cfd-online.com/Forums/ope...exception.html.
http://openfoamwiki.net/index.php/HowTo_debugging

Typically such errors are a consequence of wrong bcs primarily.

Hi Ovie,

As I am not working on interfoam sort of solver, I think MULES implicit solver would not be useful for me?
However the last link look useful. I will try those and let you know how it worked.

Thanks & regards,

Nishant

ovie June 11, 2010 22:06

Hi Nishant,

Please check your variable initializations for the internal fields. I used non zero values and the error stopped. This might help. I found it from the second link in the last message.

Sorry about the confusion with the MULES solvers.

regards..

nishant_hull July 24, 2010 20:19

Thanks guys. Does any one know how to access the patchField from previous time step? is there any easy way to do it?

regards,

Nishant

nishant_hull July 24, 2010 21:46

I want to access the patchField value from the last time (current_time - 1) and then take avergae value of the current and previous value of patchField and impose it as a boundary condition.
Is there any easy way to access previous iteration patchField value? for example, something like ... patchField.this->db().time().timeIndex()-1 ???

regards,

Nishant

andrea November 4, 2010 10:19

Dynamically linked BC not recognized by simpleFoamResidual
 
Hi,
maybe one of you has already faced the problem, I created my own BC and linked it dynamically in $(FOAM_USER_LIBBIN) but post-processing tool simpleFoamResidual
cannot recognize it, do you know how to fix this?
Thanks
Andrea

Code:

--> FOAM FATAL IO ERROR:
Unknown patchField type evaporationVelocity for patch type patch

Valid patchField types are :

50
(
SRFVelocity
activeBaffleVelocity
advective
calculated
cyclic
cylindricalInletVelocity
directMapped
directMappedVelocityFlux
directionMixed
empty
fixedGradient
fixedInternalValue
fixedNormalSlip
fixedValue
flowRateInletVelocity
fluxCorrectedVelocity
freestream
inletOutlet
mixed
movingWallVelocity
oscillatingFixedValue
outletInlet
outletMappedUniformInlet
partialSlip
pressureDirectedInletOutletVelocity
pressureDirectedInletVelocity
pressureInletOutletVelocity
pressureInletUniformVelocity
pressureInletVelocity
pressureNormalInletOutletVelocity
processor
rotatingPressureInletOutletVelocity
rotatingWallVelocity
sliced
slip
supersonicFreestream
surfaceNormalFixedValue
swirlFlowRateInletVelocity
symmetryPlane
timeVaryingFlowRateInletVelocity
timeVaryingMappedFixedValue
timeVaryingMappedPressureDirectedInletVelocity
timeVaryingUniformFixedValue
timeVaryingUniformInletOutlet
translatingWallVelocity
turbulentInlet
uniformFixedValue
waveTransmissive
wedge
zeroGradient
)


file: /home/andrea/OpenFOAM/andrea-1.7.1/run/testMesh2Cor2P/16.0253/U::boundaryField::tub from line 111739 to line 111740.

    From function fvPatchField<Type>::New(const fvPatch&, const DimensionedField<Type, volMesh>&, const dictionary&)
    in file /opt/openfoam171/src/finiteVolume/lnInclude/newFvPatchField.C at line 110.

FOAM exiting


mm.abdollahzadeh July 30, 2012 13:46

Quote:

Originally Posted by marupio (Post 245761)
1. Choose a boundary condition that is close, and copy the directory contents to anywhere (say run/myCode). oscillatingFvPatchField might be a good one to start with.

2. Rename all the copied files to a new name (say customJetPatchField or something).

3. Search & replace all text in all the new files old name for new name (oscillatingFvPatchField replaced with customJetPatchField)

4. Modify the code to suit your needs. (How's your C++?)

5. Create the directory structure: myCode/Make, and create files and options in it.

6. Under files, define the main source file (look under finiteVolume/Make/files, and copy / rename the relevant entry from the patch field you copied). Also tell it what the new library name will be. Use $(FOAM_USER_LIBBIN) instead of $(FOAM_LIBBIN). It should look something like:
customJetPatchFields.C

LIB = $(FOAM_USER_LIBBIN)/libcustomJetPatchField


7. The options file should have EXE_INC (for any includes such as finiteVolume) and LIB_LIBS (for included libraries, again finite Volume). Look at other LIB_LIBS for examples. Should probably look like:
EXE_INC = \
-I$(LIB_SRC)/finiteVolume/lnInclude

LIB_LIBS = \
-lfiniteVolume

etc..

8. $wmake libso customJetPatchField

9. Add whatever new dictionary entries are needed to your 0/U and 0/P files.

10. Add libs ( "libcustomJetPatchField" ) to controlDict

11. It should run now.

Common mistakes are not linking the correct file in Make/files. It isn't the one you might think. Remember to copy what finiteVolume/Make/files does for the patch field you chose. Another mistake is forgetting the libso in wmake. Good luck!

Dear David

I have created my boundary condition according to your steps.
but when running my case it can not recognize the patch name.

could you please help me?

best
Mahdi

Tensai September 8, 2012 11:22

Hello foamers!

I am a new OpenFOAM user and I have been trying to create a new boundary condition using the tutorial posted on this thread and on the wiki. I followed the tutorials to the letter (at least I think!) and I managed to compile my boundary condition without any error.

However, when I tried to use the newly created boundary condition in a case, I got the same error message as Andrea two posts above. Any suggestion as to how to solve this problem?

By the way, I am using OpenFOAM 2.1.0.

Thanks

marupio September 8, 2012 13:00

When you run it, it isn't loading the library containing your boundary condition. Do you have the correct entries in the controlDict? I think it's called "libs". If you have the correct entries, check to see if it is actually loading... is there a --> FOAM Warning at the very start that informs you it could not load a library?

Tensai September 8, 2012 13:09

Thank you for your quick reply. I figured it would be a problem of library. In the controtDict for the library I added "libWindkessel.so". libWindkessel is the name of the library that was used in the files file. Anyway I can't get an answer right now regarding the error. I will probably only get it Monday when I have access to the machine I use for the simulations at the university.

Tensai September 10, 2012 04:48

Ok I just checked the error message and here is what I got at the start of it:

Quote:

--> FOAM Warning :
From function dlOpen(const fileName&, const bool)
in file POSIX.C at line 1175
dlopen error : /home/ese/mb483/OpenFOAM/mb483-2.1.0/platforms/linux64GccDPOpt/lib/libWindkessel4FvPatchScalarField.so: undefined symbol: _ZTVN4Foam29Windkessel4FvPatchScalarFieldE
--> FOAM Warning :
From function dlLibraryTable::open(const fileName&, const bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 96
could not load "libWindkessel4FvPatchScalarField.so"
I don't know how and where to track this unknown symbol. If you have any idea, please feel free to pitch it to me.

Tensai September 11, 2012 14:01

I just solved my problem. If it can be of any help to people stuck with a similar problem, the issue resided in the header file. I forgot to remove a member function of the original boundary condition that I had no use of.

sihaqqi March 25, 2013 04:51

queries in preparing boundary conditions
 
@David Gaden and other experts


I am a student of MS by research in CFD and a beginner with openFoam. I found your steps helpful but I am stuck in the following instances


According to your steps 5 and 6
  1. Create the directory structure: myCode/Make, and create files and options in it.
  2. Under files, define the main source file …...customJetPatchFields.C
    LIB = $(FOAM_USER_LIBBIN)/libcustomJetPatchField

    I have copied these two from system opt/openfoam/finiteVolume/Make folder and deleted all the patch names in it and deleted all entries except only the two lines you have written. Is it alright or should I let all entries stay there whic are there when you copy original file from Make folder and just add my line and change the last line to
    LIB =$(FOAM_USER_LIBBIN)/libcustomJetPatchField

    8. $wmake libso customJetPatchField
    When I type this command in withoutcustomJetPatchField. it gives me the following error: no rules to make target “ customJetPatchField.dep” needed by Make linux 64 GCcDP0pt/dependecies”. Stop
    When I type full command as you have written with customJetPatchField, the error is cannot find customJetPatchField. What does this mean

    10. Add libs ( "libcustomJetPatchField" ) to controlDict
    Where should I add this, In controlDict file, can you identify by attaching your own controldict file so that I can see where amongst the program of time you have included it to avoid mistakes

    I shall be very grateful for these answers.
    Best Regards

mwaqas November 3, 2014 07:19

Hello Everyone

I am trying to implement / compile new boundary condition in OF 2.3.0. I have followed the same steps as above. I have code for my new boundary condition. But when I try to compile boundary condition by typing "$ wmake libso " I get the following error

waqas@waqas-Inspiron-N5050:~/OpenFOAM/waqas-2.3.0/myCode$ wmake libso
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file particleSlip/particleSlipVelocityFvPatchVectorField.C
Making dependency list for source file particleSlip/particleSlipThetaFvPatchScalarField.C
make: *** No rule to make target `twoPhaseEulerFoam.dep', needed by `Make/linux64GccDPOpt/dependencies'. Stop.

I think there is something missing in "Make/files"

Because when I try to implement my new boundary condition in 0/U. solver does not read new boundary condition.

SeanOpenfoam November 6, 2014 21:54

mwaqas,

Did you get an answer to your question? I've been having the same problem on OpenFOAM-2.3.0

So far, I've followed the 11-step advice posted before by marupio. I made no changes to the condition itself--I simply renamed it, updated the appropriate files, and put it into my user-folder (i.e. /home/sean/OpenFOAM/Sean-2.3.0/src/finiteVolume/fields/fvPatchFields/derived). When I near the end of the 11 steps, I give the wmake command and get the same "*** No rule to make target . . ." error that you described, and when I try to run a case, my new boundary condition isn't recognized. Note that for me, the command "$wmake libso myUniformFixedValue" doesn't do anything. I simply typed "wmake" in the "/home/sean/OpenFOAM/Sean-2.3.0/src/finiteVolume" directory where my Make folder is located.

However! I repeated the 11-step advice as I described above, but instead of putting my new boundary condition into my personal OpenFOAM folder, I put it into the original OpenFOAM installation (i.e. /home/sean/OpenFOAM/OpenFOAM-2.3.0/src/finiteVolume/fields/fvPatchFields/derived). When I gave the "wmake" command, it seemed to work, and indeed when I examined the files in /home/sean/OpenFOAM/OpenFOAM-2.3.0/src/finiteVolume/fields/fvPatchFields/derived/myUniformFixedValue, I found the .dep file exactly where it should be. Unfortunately, when I tried to run a case, the solver still wouldn't recognize my boundary condition (perhaps I'll have to edit the actual solver's .C file and force it to look in the correct spot for my constraint? Or maybe use wmake in the /applications directory? Not sure how to solve this issue yet).

Anyways, there's some food for thought.

mwaqas November 7, 2014 03:53

Hello Sean

I am still stuck on the same point as mentioned above. I tried to add boundary condition in my personal folder and got same error "*** No rule to make target ***".
I also tried to add boundary condition directory into original OpenFoam installation but I was not able to add over there. If I will get something and update here. :)
Also if you get something please post here. Thank you

Best Regards

marupio November 7, 2014 10:02

"No rule to make target" is OpenFOAM for "the filename listed in Make/files cannot be found" - edit Make/files to make sure it is correct. Or it could also mean that an old .dep file is referencing a non-existent file. rmdepall clears this up.

If you compile successfully, make sure you add the library to your case directory's controlDict libs entry.

SeanOpenfoam November 16, 2014 18:24

I think I finally got my "custom" boundary conditions to work. After deleting all of my old mistakes, I:

1) created a copy of my OpenFOAM-2.3.0 folder and renamed it to sean-2.3.0 to make it my FOAM_USER location. I'm not sure if it's necessary to copy everything from the OpenFOAM-2.3.0 folder, but hey, it worked for me.

2) followed the steps marupio laid out, except that instead of putting my "custom" boundary conditions in a myCode/BC folder, I matched the file structure of OpenFOAM. For example, a fvPatchField would go in sean-2.3.0/src/finiteVolume/fields/fvPatchFields etc etc etc, just like it would in my original OpenFOAM installation.

I think a lot of my problems were related to putting my custom BC's in the correct folders, as well as getting consistent naming in their files. I found it very easy to accidentally type fvsPatchFields when I meant to type fvPatchFields, even though I used copy-paste a lot. So, marupio, I think that your previous post was quite correct.

Anyways, after following these steps, I successfully compiled my code and ran test cases with it.

Thanks a bunch!

mwaqas November 30, 2014 11:46

Hello Everyone
I have compiled my new boundary condition but when i try to run my case, I get following error

Create time

fileName::stripInvalid() called for invalid fileName air(copy).outlet~
For debug level (= 2) > 1 this is considered fatal
Aborted (core dumped)

Can anyone please tell me what could be the possible error. Thank you

PS: I am using twoPhaeEulerFoam for fluidisedbed, I have made changes in my 0/U.particles boundary condition


All times are GMT -4. The time now is 04:10.