[hjasak]

Hello Luca,

Boundary conditions (and many other things in OpenFOAM) are selected using a run-time selection mechanism). Here, all available b.c.-s register themselves to a table when you start the code and are chosen by the name in a dictionary (in your case, the type of patch field). Specifically for patch fields, if the boundary condition is not found, a "default" patch field is created for you (this helps with post-processing).

There are 3 reasons why your boundary condition would not be picked up:
- you mis-spelled its name. Check it carefully in the field file and the header file of the patch field code
- you did not compile it correctly. For examples, look at some other boundary conditions in the library. Depending on twhat you are doing, you will need one of the following in the file you compile:

makePatchFields(fixedValue);

makePatchTypeField(fvPatchScalarField, pressureTransmissiveFvPatchScalarField);

or similar.

- the third option is that you have not linked the object or library file with the solver you are trying to use. I suspect you know how to fix this.

Hope this helps,

Hrv

[luca_g]

Hello Hrvoje,

I understood the "default" mechanism and I checked the name many times; also the newBC.C file ends with something like:

makePatchTypeField(fvPatchScalarField, newBCFvPatchScalarField);

About compiling, the bc code is compiled to a library using wmake lib or wmake libso, and I looked at rhopSonicFoam/BCs for files and options.
About linking I added the -lxxx option to the EXE_LIBS list of the solver makefile.

However, I wonder how can the library get actually linked to the solver if nothing references it. By the way, I'm working under cygwin.

Regards,

Luca

[hjasak]

Aha, one of those. :-)

The definition of C++ language says that all static symbols in all linked libraries will be executed before the first line of the main code - this is what we use to populate the run-time selection tables. Therefore, according to the definition all should be well.

However, we are talking about a Billy-boy box (that's Gates, BTW) rather than a real computer :-) so try doing an explicit dllopen() on your library at the start of the code. I'm pretty sure this would do it.

Alternatively, just link the object file from your new boundary condition straight with the top-level code, which should avoid all problems. In any case, that would be a good test.

Hrv

[luca_g]

Thank you Hrvoje,

I linked directly the object file and it works..

Any comment about the definition of FoamX types (although this is the wrong thread..) ?

Regards,

Luca

[cedric_duprat]

Hi all,
I 'm trying to use the convectiveOutlet boundary condition but ...just trying.
I put it in src/finiteVolume/fields/fvPatchFields/basicFvPatchFields and compile it, there every thing seems to be Ok.
Then, in my case, I modified the O/U and in the outlet patch I add:
type convectiveOutlet;
gradient UNIFORM 0;
convectiveVelocity uniform 11.3;
snGradScheme normal;
ddtScheme Euler;
updateValue 0;
writeValue 0;

starting FoamX, I got this error Invalid patch field type 'convectiveOutlet' for patch 'outlet' in field dictionary 'U'

Maybe I forgot to do something, any idea or hints ?
Thank you for helping ...

[msrinath80]

Yes, for FoamX to recognize newly build B/C you need to edit some of its config files. My suggestion is to simply edit all dictionaries from the command line and proceed. Ignore FoamX. When I started using OpenFOAM 1.2, I used FoamX for the first week or so. Later I found that all it did was provide a graphical interface to edit dictionary entries. So I started editing all dictionaries using emacs directly. In my opinion, FoamX is a very useful application for beginners to OpenFOAM. But as you develop new solvers, boundary conditions etc., it is usually more productive to move straight to the command line.

[cedric_duprat]

Ok, Srinath thank you for replying, I will try like that ...
and hope that it will work correctly
and if I have question(s) ... I won't hesitate :o)

[cedric_duprat]

Hi again, few days later,

I'm trying to run my case on parallel, without FoamX , but when I tryed to decompose my geometry (decomposePar), I got this error:
FOAM FATAL IO ERROR :
Cannot find 'value' entry which is required to set the values of the default patch field.
(Actual type convectiveOutlet)

my problem is that there is no "value" defined in convectiveOutlet (this is the aim of this method ...), so, is there any file I have to change to run parallel computation with other BC ?

Thanks for replying,

Cedric

[msrinath80]

Check this[1] thread. Are you still using FoamX at some point after setting up the case, because FoamX can then overwrite your settings.

[1] http://www.cfd-online.com/OpenFOAM_D...es/1/1057.html

[cedric_duprat]

Hi Srinath,
Thank for replying so fast, ...
yes, I use FoamX for all my "normal" BC and then I change my "home made" BC. You are right, change my BC first then FoamX is .... not a good idea.
thank you for the link, I didn't find it ...
so, let's try like that and ....see you in one week for an other problem ... :-)

Cedric

[cedric_duprat]

hello,

I would like to know if someone tried the convectiveOutletPatch in a parallel run. Cause in my case, It's running well on a coarse grid (one processor) but, with a finer grid, It stop a the second iteration (parallel run).
what is strange is that the first iteration works correctly. (maybe no link with the convectiveOutlet patch ...but, I ask the question to confirm,.... or not)
I used decomposePar so I don't know where are the borders of my sub-domains, if the oultet patch is cut in two parts, there is a problem with the BC ... how to check this?

any idea(s) ?

Thanks,
Cedric

[7islands]

Hi all,
I also confirmed some numerical oscillations on the convectiveOutlet boundary with my solver in a parallel case... I have never tried any parallel case till now with the code.

I haven't found what's the problem as of now but have a feeling that if I could sort it out that should be quite trivial. Do anyone know what a parallel-ready b. c. code which relies only on the time-histories of boundary and patchInternalField values must satisfy?

Takuya

[eugene]

Is the code still the same as your last post (9/2/2007)? If you can confirm or post the latest I will take a quick look to see if I can spot any obvious issues.

[7islands]

Hi Eugene,
Yes, the same code. Many thanks for your assistance!

Takuya

[cedric_duprat]

Hi Takuya and Eugene,

I also used this code, with difficulties in parallel. I think that we can decrease the possibility of mistakes if we use OF's numerical scheme whereas these avaiable from Takuya's code but it's just an optimisation and no link with our parallel problem.
I just want to add that it is working properly on 1 processor with a fine mesh also.

Thank you for helping,

Cedric

[7islands]

Hi,
I think I have solved the problem.

• Fixed uninitialized internal variables
• Supports OF 1.3, 1.4, 1.4.1
• Default ddtScheme changed from backward to CrankNicholson (since the scheme has been giving the best results for me)

For detailed usage see the included README.

convectiveOutlet-20070905.tar.gz
Takuya

[cedric_duprat]

Hi Takuya,
thank you for the new version of you code. I am strating to use it now.
so, I copied it in /applications/utilities/preProcessing/
It compile well (without any problems); `/craya/big/duprat/OpenFOAM/duprat-1.4.1/lib/linuxGccDPOpt/libconvectiveOutlet.s o' is up to date.

then, when I tryied to run it on a case, with OF 1.4.1, I got this message:
Starting time loop

Time = 0.001

--> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type convectiveOutlet)
on patch sortie of field U in file "/craya/data/duprat/cylindre/0/U"
You are probably trying to solve for a field with a default boundary condition.

From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.

FOAM exiting

I added the lib in controlDict as you mensionned on your README: ("libconvectiveOutlet.so");

Well, I'm quite lose now,am I missing something?

I found a thread http://www.cfd-online.com/OpenFOAM_D....html#POST8728 with the same problem and Hrv focus on a wrong compile method but, I can't find what I did wrong ...
Any idea ?

thank you for helping,
Regards,
Cedric

PS: notice that my case worked with the last version of convectiveOutlet.

[7islands]

Hi Cedric,
I just would like to make sure you wrote libs, not lib as the keyword in controlDict. It's the standard procedure to load user libraries; see ReleaseNote-1.4.1 included in your copy of OF distribution.

Takuya

[lakeat]

Hi Takuya!

I am using OpenFOAM-1.5 now.
ParaFoam can't handle convectiveOutlet BC....Crashhhhhhhh
Any ideas?

Regards, Daniel

[7islands]

Hi Daniel,
I'm not seeing any crashes so far... but on the Mac port. Do you get any error messages or whatever?

p.s. Did anyone try the new advection b.c. in 1.5?

Takuya