Parabolic Boundary Condition in OpenFOAM
 

How to give a fully developed flow inlet boundary condition (parabolic) in OpenFOAM.??

Greetings RAUL and welcome to the forum!

There are several ways to do it:

• Check the tutorial "tutorials/incompressible/simpleFoam/pitzDailyExptInlet", where it shows how to define the values for each point in the inlet... defined in the file "constant/boundaryData/inlet/0/U"
• You can also use groovyBC: http://openfoamwiki.net/index.php/Contrib_groovyBC
• You can also search this forum for the words "parabolic velocity" ;)

Best regards,
Bruno

I tried compiling the boundary condition for parabolicinlet velocity but i am getting an error after doing the compilation.This is the error output:

Making dependency list for source file simpleFoam.C
could not open file parabolicVelocityFvPatchVectorField.H for source file simpleFoam.C
make: *** No rule to make target `parabolicVelocityFvPatchVectorField.dep', needed by `Make/linuxGccDPOpt/dependencies'. Stop.

Without a full description of the changes you've made, or the source code with the changes you've made, all that's left is a guessing game :(

Really sorry for that :o ,i used a pdf of chalmers university explaining the implementation of this boundary condition.
Can i have your email id so i can send it over to you.

No need for emails ;)

You can indicate the title and/or name of the PDF you're following, which should be already available online!

Additionally, you can zip the folder you've tried to compile, after you run these two commands:

Ok
The name of the pdf was "implementBoundaryCondition.pdf" by Mr.Hakan Nilsson.

OK, it's this one: http://www.tfd.chalmers.se/~hani/kur...yCondition.pdf

Use the instructions starting from page 178. It's easier to follow the instructions from that page forward!

Yes it was the same pdf.
I will try compiling from page 178 and would let you know the results.
:)

Dear wyldckat,
I saw your post about the options of getting parabolic BC. For the second option, the groovy one... does it work with OF 2.1.1, does it need any compiling or compatible tools to make it works. Could you please direct my how to start using it...
Best Wishes,
Sandy,

Greetings Sandy,

1. It should work on OpenFOAM 2.1.1.
2. You will need to build swak4Foam, as instructed here: http://openfoamwiki.net/index.php/Co...4Foam#Building
3. You can download it as instructed here: http://openfoamwiki.net/index.php/Co...am#Downloading
4. You need to first install the packages indicated in the section "System Requirements" described here: http://www.openfoam.org/download/source.php
5. As for how to groovyBC for this flow profile, use Google to search for:
   
   Code:

   ---

   site:cfd-online.com parabolic groovybc

   ---

Best regards,
Bruno

Dear wyldckat,
Thank you very much for your replay. It was really very helpful. I have another question for you If you excuse me... Is there another way to get the parabolic B.C. more easy than this way? I mean like a direct B.C. in OF 2.1.1. to be imposed.
Best Wishes,
Snady,

Hi Sandy,

Follow the instructions from this post: http://www.cfd-online.com/Forums/ope...tml#post446451 post #10

Best regards,
Bruno

Dear wyldckat,
Thank you very much for your help. I followed the instructions and compiled the code you done it with simpleFoam and It works very well. But does it work with my case of interFoam, 3D. I tried to do it but running blew up with out any results. Could you please tell me what is in the inlet velocity B.C?
n (1 0 0);
y (0 1 0);
in my case I impose inlet from above, so I gave like this: maxValue -2;
2 is the maximum velocity I want. Any Ideas would help...
Sandy,

Hi Sandy,

Can you modify and share an OpenFOAM tutorial case to demonstrate what you are trying to do with this boundary condition?

Best regards,
Bruno

dynamic library linking
 

Hi Bruno,

I have a basic doubt about linking a dynamic library to a solver. If a dynamic library (say libmyBCs) has more than one boundary condition compiled in it (something other than parabolic velocity in this case), will there be an error when my solver uses just one of those two? We include libmyBCs.so in the controlDict and not just parabolicVelocity.

I have two boundary conditions compiled in the library and have a case where my modified solver uses only one of the two. When I tried to run the case i got:
Here newDirectionMixedFvPatchVectorField was the second boundary condition that was not use by this solver. So i guess my question is: Is it okay to have one library where all your user defined BC are compiled and accessible when the solver uses only one or few of those BCs?

Hi Srivaths,

It's not necessary to use all boundary conditions from the library in the source code of your solver.

The reported error seems to be another one: the boundary condition you added is not properly coded, to properly load up to the object list of possible boundary conditions. It's only partially coded in and it's missing the necessary hook-ups to the object reference library.

Check the previous instructions to verify if you did all of the necessary steps to create a new boundary condition. Or share your source code, so that I can have a look at it.

Best regards,
Bruno

Hi Bruno,

Thank you for the information. The boundary conditions that I've defined in the myBCs library are newGradient and newDirectionMixed. I've attached the .C files of both the boundary conditions.

In newGradient I have only modified the definition for gradient() from fixedGradient BC and in the newDirectionMixed, the definition of refGrad() from directionMixed BC. Since both my BCs compiled, I thought there might not be any errors with the definition.

Would be glad if you could take a look.

Hi Srivaths,

Well, just because a library or application builds, it does not mean it will work as intended ;)

What about the header files? The ones that end with ".H"? They have the other half of this story.

Best regards,
Bruno

Oh, right. Point noted.

I'm learning by doing, so I was under the assumption it's all okay if it builds/compiles :p

I've attached the header files.

Hi Srivaths,

OK, once in possession of source code, it made it a lot easier to figure out the problem. Attached is a working build and loading library, but I have not tested the boundary conditions themselves ;)

So the problem was rather simple:

1. In "newDirectionMixedFvPatchVectorField.H" you were indicating that definitions for "autoMap" and "rmap" would be given at a later time.
2. But in "newDirectionMixedFvPatchVectorField.C", you had the code for them commented out.
3. Result: the library wouldn't load because the aforementioned methods were nowhere to be found and they are needed, given the inherited class structure.

Now, two solutions can be done:

1. You can comment out the respective code in the header file as well (which I did), since the methods in question were virtual and it's not obligatory in this case to declare them as well in this derived class.
2. Or you could uncomment the respective code from the ".C" file.

For more information about C++, I advise you to study this tutorial: http://www.cplusplus.com/doc/tutorial/ ;)

Best regards,
Bruno

Thank you!
 

Hi Bruno,

Thank you so much for clearing that issue! :)

To be frank I didn't quite understand what autoMap and rmap meant as I was simply doing changes to another derived BC. I have an idea now. I will have a look at the link you have given me and avoid mistakes like them in the future. (hopefully a few others as well)

Wishing you in advance for a Happy 2014! Its almost 00:00 AM here! :)

Greetings Bruno

Many thanks for your valuable information in this thread. I found the way in "tutorials/incompressible/simpleFoam/pitzDailyExptInlet"much simpler than groovy.

I want to implement this approach for my case. I have a wedge-typed grid that the inlet velocity profile is known from another simulation.

In the tutorial that you introduced, the velocities are identified for points along the min and maximum Z .

But what about a wedge-typed grid? I have attached a pic of my grid.

In Z direction only one cell occurs. If I define my velocities in Z=0 line, I have the values on cell centers (I think) or do I need to define the velocities on the points located on the upper and lower sides of the triangle?

Does it differ? Would you PLZ hint me?

Best,
Bobi

Greetings Bruno

About the method described in: "tutorials/incompressible/simpleFoam/pitzDailyExptInlet"

I checked that whether I need to determine the velocity profile on the upper and lower sides of the inlet triangle or can I adjust it on the middle of the triangle i.e the location of Z=0

I found out that we can just pre-determine the values of the velocity only on the sides of the boundary. i.e. in my case on the upper and lower sides of the triangle. (for other condition, O.F. did not accept pre-determination of velocity by expressing error)

Many thanks for your kind and always effective hints.:):)

Regards
Bobi

Hi wyldckat
I modify transitionalParabolicNonVelocity by replacing with and compile successfully. It work fine. But when I change code to it compile successfully but in running simulation give error . Do you any idea for this?
OpenFOAM-ext4.0, solver icofluid of fsiFoam.

Quick answers:
The only thing that comes to mind is to try to use "scalar" to convert the value to actual scalar value type that OpenFOAM and foam-extend use:
Beyond this, I would have to test it myself, but would need to know:

1. Which installation instructions you followed.
2. Which Linux Distribution you are using.
3. A simple test case with which to reproduce the error.

Please refer to its actual project name: foam-extend

Dear wyldckat
I use linux Ubuntu 16.04 with fsiFoam that downloaded from
https://openfoamwiki.net/index.php/E...re_interaction
the tutorial of hron&Turek that exist in fsiFoam folder is uses and transientParabolicVelocity in src folder of this toolkit modified with pow(a,n) (ex. 0<n<1 or any double value).
I use your recommended code but still the problem exist.
I saw in programmerGuide of openfoam that pow(a,n) work with n=0,1,2,..,4.

Quick answer: In the custom code you have, see this line?
Add this line after that one:
Compile the library again.

Run the case and you should see the list of values for "coord" before it crashes.

See any negative values? If there are negative values, care to guess why the power to 1.7 of a negative value would be a bad idea in the real value spectrum?

If you're not seeing it yet, square root can be defined as a power... "pow(value,0.5)". The cubic root can also be defined as a power: "pow(value,1.5)"

Not seeing it yet? Negative numbers inside root operations will result in imaginary numbers, i.e. not real numbers but instead complex numbers, which is not supported in this particular situation...

You are right. the (c-ctr) give negative value. By converting negative values to positive values, the problem solved.
Thanks