[evgenii]

Hello, Hrvoje.
I write you to know how can I apply the possibility you've mentioned in answer to my post. I mean
newDirectionMixedFvPatchField. I need so much this kind of b.c. to apply it in my solver.
Would you be so kind and send me this files, because on my machine there's no such directory (you wrote about in your answer)
Hopefully, Eugene

[hjasak]

Just send me an E-mail and I'll post it back to you.

Regards,

Hrv

[evgenii]

Thank you a lot!
How can I properly compile it to use?

[hjasak]

The file you need to compile and link with your executable (either directly or through a shared library) is newDirectionMixedFvPatchFields.C

Once you do that, the new type will be available on the run-time selection mechanism and you will be able to use it as an FV boundary condition.

Enjoy,

Hrv

P.S. As I've said before, the correct specification of the b.c. in the boundary field (in my case for a vector) is:

bottomBrickUp
{
type directionMixed;
refValue uniform (0 0 0);
refGradient uniform (0 0 0);
valueFraction uniform 0;
value uniform (0 0 0);
}

[evgenii]

Hi
I have a question about strange solver behaviour(from my point of view).
In my file I make a little mistake and write nemDirectionMixed instead of newDirectionMixed.
But no error occured!
Solver worked as before and produced the same results as before.
Than I changed it again and it worked again!
So now I don't no how to understand this strange behaviour.
Regards
Evgeny

[evgenii]

Hi
And now I have one more strange thing
if I change directionMixed to mdirectionMixed or fixedValue to newfixedValue solver also works without any errors.
It's so strange!
Regards
Evgeny

[hjasak]

Hi,

You are quite clearly not running what you think you should be running. I'm not quite sure if you are only changing the input files or the actual code as well. Remember that boundary conditions are on a run-time selection table and that you will need to re-compile the file that instantiates them to get the changes and not the top-level code.

As for the error in the name, OpenFOAM has got a special default do-nothing condition, which will allow you to do post-processing but not run the code. If you look at defaultFvPatchField in the finiteVolume library you will see what I mean. I keep a little Info message in it, so that I know if the solver does this for me. Anyway, if default b.c. is used, your solver should do nothing (or if you are VERY unlucky) produce garbage.

Enjoy,

Hrv

[evgenii]

Sorry I don't understand your answer.

I have compiled solver and I have a case for this solver. When I run this solver it reads in mesh, boundary fields and so on. So if I want to change boundary conditions I need to change in my case/0/field this boundary field. Am I right?
What should I recompile at this point?
I thought that this is the one major point of OpenFoam: you simply change geometry and boundary without any recompilation. Is ir true or not?

regards
Evgeny

[hjasak]

OK, let's try again.

I have compiled solver and I have a case for this solver. When I run this solver it reads in mesh, boundary fields and so on. So if I want to change boundary conditions I need to change in my case/0/field this boundary field. Am I right?

You are right.

What should I recompile at this point?

Nothing.

I thought that this is the one major point of OpenFoam: you simply change geometry and boundary without any recompilation. Is ir true or not?

This is true.

Let us return to the problem: what happens when in the case/0/field file I specify a boundary condition called banana. The solver looks into the run-time selection table for an entry called banana. If the entry is there, a banana boundary condition is created and when you evaluate the boundary field, the code inside the banana b.c. will be executed. All is well.

If the entry for banana is not there, the code will create a default boundary condition for you. This boundary condition is created for post-processing only and has no functionality requred by the solver. Since the banana. b.c. has not been created, its evaluation code will never be visited.

Therefore, if you mis-spell the name of the b.c., your executable may or may not work, which is dangerous. For this purpose, I want to know when a default b.c. has been created: if it happens in solver code, you know something has gone wrong.

Remember, the run-time selection table is assembled when you start the code and its contents depends on which libraries you linked with the executable, but this is another story.

Better now?

Hrv

[evgenii]

Yes!
Thank you, you're very kind person!

Best regards
Eugene

[sreekanth]

hello,

can someone help me in implementing 'calculated' pressure condition on 'adiabatic wall' . I have an obstacle in the flow which has to be adaiabatic but i don't want to impose any condition of p on that. I tried to use 'calculated' primitive type with no physical type specified on obstacle and zeroGradient for T and U. It shows the following error:
Reading field p



--> FOAM FATAL IO ERROR : keyword value is undefined in dictionary "/home/user/skolan/OpenFOAM/skolan-1.3/run/tutorials/sonicFoam/backwardStep/0/p: :obstacle"

file: /home/user/skolan/OpenFOAM/skolan-1.3/run/tutorials/sonicFoam/backwardStep/0/p:: obstacle from line 58 to line 58.

From function dictionary::lookupEntry(const word& keyword) const
in file db/dictionary/dictionary.C at line 152.

FOAM exiting