[wavemaster]

Dear Forum,
I successfully used groovyBC for some simple waveBC.
For learning (and later doing more complex stuff) I implemented the same equations (setting values for alpha and U) in a custom BC.
I then compared the BC values produced by both BCs and they were equal, except timestep 0.
I cannot see the numbers for timestep 0, but in paraFoam the groovyBC case gives alpha=0 and my customBC sets it to the waterlevel.

Now, I have the astonishing effect of very different development in the internal field, groovyBC behaves well and my BC produces large velocities in the internal field, even with zero amplitude waves which correctly impose zero velocity and no surface elevation.
Although it seems very unlikely to me, is there something I should know about how groovyBC evaluates the gradient? Would I have to define a way to get a gradient like in mixed Patch?
The whole issue does not make much sense to me, so any idea is much appreciated. I can happily share my BC and the testcases if anyone is interested.
Cheers,
Pal

[gschaider]

Originally Posted by wavemaster

Dear Forum,
I successfully used groovyBC for some simple waveBC.
For learning (and later doing more complex stuff) I implemented the same equations (setting values for alpha and U) in a custom BC.
I then compared the BC values produced by both BCs and they were equal, except timestep 0.
I cannot see the numbers for timestep 0, but in paraFoam the groovyBC case gives alpha=0 and my customBC sets it to the waterlevel.

I'd say this is a postprocessing-problem. Either groovyBC is not loaded into paraFoam and therefor paraFoam doesn't know how to treat it. All later time-steps have a value-field written out and paraview will fall back to that for output.

Originally Posted by wavemaster

Now, I have the astonishing effect of very different development in the internal field, groovyBC behaves well and my BC produces large velocities in the internal field, even with zero amplitude waves which correctly impose zero velocity and no surface elevation.
Although it seems very unlikely to me, is there something I should know about how groovyBC evaluates the gradient? Would I have to define a way to get a gradient like in mixed Patch?
The whole issue does not make much sense to me, so any idea is much appreciated. I can happily share my BC and the testcases if anyone is interested.
Cheers,
Pal

Basically groovyBC IS a mixed boundary-Condition. It only evaluates refValue, refGradient and valueFraction and then lets the superclass (mixed) do all the heavy lifting.

I'm not sure whether I understand your problem correctly "The boundary conditions look the same (except for t=0) but the solution is different (although groovyBC gives a sensible solution)"

[T.D.]

hi guys
how are you?
you are the Masters, i am just a new openfoam user and i have seen your posts and
i thought you might be able to help me, if you please of course

My problem is that i need to set a BC on a patch of a field "c" , but that BC is a function of another field "J" calculated before going to solve the Eqn of "c".

Example inside the solver:
.
.
J=pow(c,-2)+2*c+...etc.......
.
.
solve
( ddt(c) + div(phi,c) == div(A*div(J)) )
.
.
so now if i go to apply a BC on a patch of the field "c", but this BC is [J=0].
how to do that? Any idea?
if with groovyBC, how?

help please

thanks alot

[wavemaster]

Dear Bernhard and all,
Thanks for Your reply,
What I tried to say was that both BCs set the same fixed values, but when i use them on the same case they give different results. Which is of course impossible...
For time step zero i have not yet verified the values of groovyBC since they are not written out automatically.
Since with my BC the velocity in the internal field turns crazy I am unsure if groovyBC influences the evaluation of the gradient in any way when I only set a valueExpression . Don't know why it should but it could explain the difference.

I attached my (still ugly ) implementation of what should be the same as the groovyBC command used and two mini cases to just compare the BCs.
Thanks for Your input,
Cheers,
Pal

[wavemaster]

Seems I shouldn't trust my eyes anymore...

[gschaider]

Originally Posted by T.D.

hi guys
how are you?
you are the Masters, i am just a new openfoam user and i have seen your posts and
i thought you might be able to help me, if you please of course

My problem is that i need to set a BC on a patch of a field "c" , but that BC is a function of another field "J" calculated before going to solve the Eqn of "c".

Example inside the solver:
.
.
J=pow(c,-2)+2*c+...etc.......
.
.
solve
( ddt(c) + div(phi,c) == div(A*div(J)) )
.
.
so now if i go to apply a BC on a patch of the field "c", but this BC is [J=0].
how to do that? Any idea?
if with groovyBC, how?

help please

thanks alot

That is what groovyBC was written for. In the c-field-file you'll have to write something like

theMightyPatch {
   type groovyBC;
   valueExpression "sin(J)*J"; // or whatever the expression is
}

For technical details have a look at the Wiki-page

[T.D.]

Hi gschaider,
thanks for your reply

but in the Expression, can i put an equation also ??? !
My J is a volVectorField defined and used previously inside the solver so how to put
if i need "J=0" ? Can i put it directly like this "J=0" or "J=(0 0 0)" inside the ValueExpression ?
or how?

help please

and thanks for you

[gschaider]

Originally Posted by T.D.

Hi gschaider,
thanks for your reply

but in the Expression, can i put an equation also ??? !
My J is a volVectorField defined and used previously inside the solver so how to put
if i need "J=0" ? Can i put it directly like this "J=0" or "J=(0 0 0)" inside the ValueExpression ?
or how?

help please

and thanks for you

You're asking for a lot. Especially as your exquation J=0=f(c) might have more than one solution for c (depending on c). No. Equation solving can't be done in the BC.
You'll have to solve f(c)=0 pick the solution that makes (physical) sense and implement it in the boundary condition for c

Bernhard

[T.D.]

hi
thank you so much
thanks a lot, and sorry if i insisted a bit
thank you so much for your patience

but i am really in trouble and i don't know what to do

how can i solve J=0 knowing that it is f(c), it will be like another problem where i need also my value of "c" that i don't know on the same patch wall.
It looks like setting a new problem with the same problem that stays, becuase the value of "c" at that BC wall is to be from solving "J=0"?

Just for clearance i repeat:
My "J" is the flux i defined (i calculated) which is a very complex form function of "c".
I need after to solve a transport eqn for field "c" but where the BC on a certain patch wall for "c" filed is the (zeroFlux) "J=0" .


help please, any ideas??
Can it be done by just setting a zeroGradient for the "c" filed BC at that patch wall ? Is it the same, knowing My Flux J is a special function of "c" that i defined?

thanks a lot
i need your patience

[yashar.afarin]

Hi Bernhard,
I am using OpenFOAM-1.6 with Fedora12. during groovyBC compilation I recieve some warnings nad errors that I copy some of them because all of them are almost the same:
PatchValueExpressionParser.yy:684: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:686: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:686: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:686: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:686: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:686: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:687: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:687: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:687: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.tab.cc: In member function ‘unsigned char pve::PatchValueExpressionParser::yytranslate_(int) ’:
PatchValueExpressionParser.tab.cc:4941: warning: use of old-style cast
make: *** [Make/linux64GccDPOpt/PatchValueExpressionParser.o] Error 1


please give me some guids and I wolud appreciate it.
sincerely yours

[gschaider]

Originally Posted by yashar.afarin

Hi Bernhard,
I am using OpenFOAM-1.6 with Fedora12. during groovyBC compilation I recieve some warnings nad errors that I copy some of them because all of them are almost the same:
PatchValueExpressionParser.yy:684: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
PatchValueExpressionParser.yy:685: error: ‘union pve::PatchValueExpressionParser::semantic_type’ has no member named ‘lfield’
pve::PatchValueExpressionParser::yytranslate_(int) ’:
PatchValueExpressionParser.tab.cc:4941: warning: use of old-style cast
make: *** [Make/linux64GccDPOpt/PatchValueExpressionParser.o] Error 1


please give me some guids and I wolud appreciate it.
sincerely yours

a) is this the first error message you encounter?
b) what is the output of "bison -V"

Bernhard

[yashar.afarin]

Hi Bernhard
thanks alot for your answer.
a) no, first of all, i have an error that i solved it by deleting the extra enter in make/options file. aftar that i compile again and this time, i encountered the error that i sent it to you.
b)i installed bison 2.4.1 successfully


is it possible that this error is relating to my OF version(1.6.x)?

sincerely yours

[gschaider]

Originally Posted by yashar.afarin

Hi Bernhard
thanks alot for your answer.
a) no, first of all, i have an error that i solved it by deleting the extra enter in make/options file. aftar that i compile again and this time, i encountered the error that i sent it to you.
b)i installed bison 2.4.1 successfully


is it possible that this error is relating to my OF version(1.6.x)?

sincerely yours

a) No. I mean the first line with an error. usually that is the most meaningful
b) Bison and OF-version should be alright as long as you downloaded the 1.6-version

What did you change in Make/options. I'm suspecting that

Bernhard

[yashar.afarin]

Hi bernhard
thank you for your guidance.
I detected the error and could solve it successfully.

[General_Gee]

Hi all,

I have got groovyBC working fine - thanks very much Bernhard =D.

Reading back on this forum I think that if I am coupling two patches I can only take one value from the source patch, eg. a max, min or average value. Is this correct?

I have conformal meshes at the two faces, and would like to be able to take the velocity profile from one patch and apply it as the BC for the other. What files would I have to look at modifying to try and achieve this? Or would groovyBC allow a text file (which I would write each time step from the source patch) to be read in and define a profile?

Thanks in advance and sorry if a similar q has been posed b4, but I couldnt find anything on the forum

Brian

[gschaider]

Originally Posted by General_Gee

Hi all,

I have got groovyBC working fine - thanks very much Bernhard =D.

Reading back on this forum I think that if I am coupling two patches I can only take one value from the source patch, eg. a max, min or average value. Is this correct?

I have conformal meshes at the two faces, and would like to be able to take the velocity profile from one patch and apply it as the BC for the other. What files would I have to look at modifying to try and achieve this? Or would groovyBC allow a text file (which I would write each time step from the source patch) to be read in and define a profile?

Thanks in advance and sorry if a similar q has been posed b4, but I couldnt find anything on the forum

Brian

I've been thinking about allowing mapping on conformal patches, but
a) it would require some changes on the way results are passed around
b) and this is more important: it would require some amount of checking. Otherwise there'd be a whole lot of possible user errors and I don't want to open that can of worms (and I'm not talking about parallelization yet)

Reading from files I thought about, but is currently not very high on my priority list. For your case I don't think it would be the way to go anyway (a. you'd have to write the data b. the performance would be horrible)

Why don't you use a cyclic BC for that anyway?

Bernhard

[General_Gee]

Thanks for the response. I thought that those were going to be the issues, but just wanted to check. I wanted to also be able to match the shear stress at the two faces as well... will have to have a think and play around with the cyclic condition.

Thanks again

[alfa_8C]

Hello groovy People

I'm using groovyBC as well. Also for heatFlux problems and it looks like this:

SURFACE_SOURCE
{
type groovyBC;
value uniform 283;
valueExpression "283";
gradientExpression "gradT";
fractionExpression "0";
variables "heatFlux=2000;Cp0=1005;rho0=1.18;gradT=heatFl ux/(alphaEff * Cp0 * rho0);";
timelines (
);
}

Up to now I used it in models without radiation. As soon as radiation is implemented, the solver returns the following error:

************************************************** *******************************************
--> FOAM FATAL ERROR:
Parser Error at "1.11-18" :"field alphaEff not existing or of wrong type"
"heatFlux/(alphaEff * Cp0 * rho0)"
" ^^^^^^^^ "

From function parsingValue
in file PatchValueExpressionDriver.C at line 188.

************************************************** *******************************************

Does anybody have a clue, where this problem could come from?

I compared the appearance of alphaEff in buoyantSimpleFoam and in buoyantSimpleRadiationFoam. The appearance is exactly the same!!

Thanx in advance for any hints!
Tony

[gschaider]

Originally Posted by alfa_8C

Hello groovy People

I'm using groovyBC as well. Also for heatFlux problems and it looks like this:

SURFACE_SOURCE
{
type groovyBC;
value uniform 283;
valueExpression "283";
gradientExpression "gradT";
fractionExpression "0";
variables "heatFlux=2000;Cp0=1005;rho0=1.18;gradT=heatFl ux/(alphaEff * Cp0 * rho0);";
timelines (
);
}

Up to now I used it in models without radiation. As soon as radiation is implemented, the solver returns the following error:

************************************************** *******************************************
--> FOAM FATAL ERROR:
Parser Error at "1.11-18" :"field alphaEff not existing or of wrong type"
"heatFlux/(alphaEff * Cp0 * rho0)"
" ^^^^^^^^ "

From function parsingValue
in file PatchValueExpressionDriver.C at line 188.

************************************************** *******************************************

Does anybody have a clue, where this problem could come from?

I compared the appearance of alphaEff in buoyantSimpleFoam and in buoyantSimpleRadiationFoam. The appearance is exactly the same!!

Thanx in advance for any hints!
Tony

That is strange. Not that it doesn't work, but that it worked the first time around. The field alphaEff is created by most turbulence models as a temporary field that is not necessary present when groovyBC kicks in. But for h you might be lucky. Anyway. Are you sure you used the same turbulence model for both calculations?

Bernhard

[alfa_8C]

What do you mean with "h"?? for my understanding h is the enthalpy and it appears in the laplacian term with alphaEff. But how can I use it for my problem??

Yes the turbulence model is the same. Basically the whole solver is the same accept to the additionally implemented radiation model!

This is my "debugging" procedure:
I have my 0 directory with the necessary files to run buoyantSimpleRadiationFoam. The directory contains exactly the same files as the one of buoyantSimpleFoam + the G file, which provides the radiation props of the walls etc.

Now I run buoyantSimpleFoam --> and it works. (even if the G file is in the dir - it's not needed)
Then I run buoyantSimpleRadiationFoam --> and the above mentioned error occurs.

Would it work, if I modify the solver in a manner, to let him write out alphaEff in a file every timestep? If so, do you know how to do that? I've found this piece of code in an other thread,

{
volScalarField alphaEff = turb.alphaEff();
alphaEff.write();
}

but I don't know where to insert it. Maybe you have an idea.
Tony