CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

GroovyBC the dynamic cousin of funkySetFields that lives on the suburb of the mesh

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree6Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   March 2, 2011, 13:27
Default
  #221
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by ivan_cozza View Post

Again correct, in my case tau is the tangential vector aligned with the flow velocity U, so (U dot tau) = mag(U-normal()*(normal() dot U)).



What I want to do is set the slip velocity at wall, so at the end a Dirichlet b.c. for U is possible. On the other end, for stability reasons I need to evaluate U_slip in an implicit way, so I can't just discretize the derivatives and solve.
For d(U dot n)/dtau, maybe it could be rewritten as grad(U dot n) dot tau

Any other ideas? I definitely hope that groovyBc would do the trick...
Thanks, Ivan
I'm afraid implicit won't work (unless you can reduce it to a mixed-BC).

Bernhard
gschaider is offline   Reply With Quote

Old   March 3, 2011, 03:47
Default
  #222
Senior Member
 
Ivan Flaminio Cozza
Join Date: Mar 2009
Location: Torino, Piemonte, Italia
Posts: 207
Rep Power: 11
ivan_cozza is on a distinguished road
Send a message via MSN to ivan_cozza
Quote:
Originally Posted by gschaider View Post
I'm afraid implicit won't work (unless you can reduce it to a mixed-BC).

Bernhard
What do you mean with reduce to a mixed b.c.?
My b.c. is essentially a mixed b.c., as apart from the constants it is in the form

a*f_wall + b*grad(f_wall) = c

what kind of modification it needs to be putted in a mixed b.c.?

Thanks,
Ivan
ivan_cozza is offline   Reply With Quote

Old   March 3, 2011, 10:15
Default
  #223
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by ivan_cozza View Post
What do you mean with reduce to a mixed b.c.?
My b.c. is essentially a mixed b.c., as apart from the constants it is in the form

a*f_wall + b*grad(f_wall) = c

what kind of modification it needs to be putted in a mixed b.c.?

Thanks,
Ivan
With mixed b.c. I mean the mixed boundary condition as described in the UserGuide 5.2.3
gschaider is offline   Reply With Quote

Old   May 12, 2011, 18:23
Default
  #224
New Member
 
Dan Maciejewski
Join Date: Jun 2010
Location: State College, PA
Posts: 2
Rep Power: 0
DanScranton is on a distinguished road
Hello Foamers,

I am having the same error as suraj in post #27. However, I have added

libs ( "libgroovyBC.so" );

to the controlDict, and OF1.6-ext has access it, as I have no error finding the library. The error:

--> FOAM FATAL ERROR:

gradientInternalCoeffs cannot be called for a genericFvPatchField (actual type groovyBC)
on patch jet of field U in file "/home/dum153/OpenFOAM/dum153-1.6-ext/run/plateBlowing/airIntoWater/0/U"
You are probably trying to solve for a field with a generic boundary condition.

From function genericFvPatchField<Type>::gradientInternalCoeffs( ) const
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 782.

I am trying to implement a time-varying (ramp) parabolic velocity in the y-direction, following the "pulsedPitzDaily" case, which works fine. The offending code:

jet // jet perpendicular to hole
{
// type timeVaryingUniformFixedValue;
// fileName "JetVelocity";
// outOfBounds clamp;
// type fixedValue;

type groovyBC;
variables (
"t0=0.5"; // time (s) when to begin injection
"t1=1.0"; // time (s) to level off velocity -> constant after this time
"C=0.2"; // slope: velocity / time -> [m/s^2]
"xp=pts().x";
"minX=min(xp)";
"maxX=max(xp)";
"para=-(maxX-pos().x)*(pos().x-minX)/(0.25*pow(maxX-minX,2))*normal()";
);
// valueExpression "(time()<t0) ? 0 : ( time()<t1 ? C*(time()-t0) : C*(t1-t0) )";
// valueExpression "(time()<t0) ? vector(0,0,0) : ( time()<t1 ? C*(time()-t0)*para : C*(t1-t0)*para )";
valueExpression " vector(0,0,0) ";
value uniform (0 0 0); // default value not used
}


Any ideas as to what is causing this error? The pulsedPitzDaily case ran fine. I tried modifying the code, to just produce no-slip at the jet. Case runs fine with

type fixedValue;
value uniform (0 0 0);

But not for the equivalent with groovyBC:
type groovyBC;
valueExpression " vector(0,0,0) ";

This indicates to me that just using groovyBC is the issue, although the lib can be found without a problem...
Any insight would be greatly appreciated

Thanks,
Daniel

Last edited by DanScranton; May 12, 2011 at 19:00. Reason: typo
DanScranton is offline   Reply With Quote

Old   May 14, 2011, 11:15
Default
  #225
Member
 
Santiago
Join Date: Dec 2009
Posts: 85
Rep Power: 9
gascortado is on a distinguished road
Hi all,

I'm trying to set up a random 3D velocity inlet similar to this:

variables "utau=.128;nu=1.51e-5;ux=utau*((1/.41)*(log(pos().y*(utau/nu))) ;uy=(1/2.5)*ux; uz=(1/2)*ux;";

valueExpression "vector (ux*rand() ,ux*rand(), uz*rand())";

I need these three components to be random and independent of each other. I realized however, that every time rand() is called in a specific time-step it generates the same random field so at the end ux, uy and uy are multiples of each other. That is not what I want.

Is it possible to generate three sets of random numbers for each time step using GroovyBC??
gascortado is offline   Reply With Quote

Old   May 16, 2011, 05:00
Default
  #226
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
That all looks fine. Anyway. Set in your installation in etc/controlDict these flags:

disallowGenericFvPatchField 1;
disallowGenericPointPatchField 1;
disallowGenericPolyPatch 1;

instead of silently accepting the unknown BC it should give you a list of the boundary conditions that OF currently knows about (including stuff that was pulled in via libs)

BTW: which version of OF and which version of swak are you working with?

Quote:
Originally Posted by DanScranton View Post
Hello Foamers,

I am having the same error as suraj in post #27. However, I have added

libs ( "libgroovyBC.so" );

to the controlDict, and OF1.6-ext has access it, as I have no error finding the library. The error:

--> FOAM FATAL ERROR:

gradientInternalCoeffs cannot be called for a genericFvPatchField (actual type groovyBC)
on patch jet of field U in file "/home/dum153/OpenFOAM/dum153-1.6-ext/run/plateBlowing/airIntoWater/0/U"
You are probably trying to solve for a field with a generic boundary condition.

From function genericFvPatchField<Type>::gradientInternalCoeffs( ) const
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 782.

I am trying to implement a time-varying (ramp) parabolic velocity in the y-direction, following the "pulsedPitzDaily" case, which works fine. The offending code:

jet // jet perpendicular to hole
{
// type timeVaryingUniformFixedValue;
// fileName "JetVelocity";
// outOfBounds clamp;
// type fixedValue;

type groovyBC;
variables (
"t0=0.5"; // time (s) when to begin injection
"t1=1.0"; // time (s) to level off velocity -> constant after this time
"C=0.2"; // slope: velocity / time -> [m/s^2]
"xp=pts().x";
"minX=min(xp)";
"maxX=max(xp)";
"para=-(maxX-pos().x)*(pos().x-minX)/(0.25*pow(maxX-minX,2))*normal()";
);
// valueExpression "(time()<t0) ? 0 : ( time()<t1 ? C*(time()-t0) : C*(t1-t0) )";
// valueExpression "(time()<t0) ? vector(0,0,0) : ( time()<t1 ? C*(time()-t0)*para : C*(t1-t0)*para )";
valueExpression " vector(0,0,0) ";
value uniform (0 0 0); // default value not used
}


Any ideas as to what is causing this error? The pulsedPitzDaily case ran fine. I tried modifying the code, to just produce no-slip at the jet. Case runs fine with

type fixedValue;
value uniform (0 0 0);

But not for the equivalent with groovyBC:
type groovyBC;
valueExpression " vector(0,0,0) ";

This indicates to me that just using groovyBC is the issue, although the lib can be found without a problem...
Any insight would be greatly appreciated

Thanks,
Daniel
gschaider is offline   Reply With Quote

Old   May 16, 2011, 05:14
Default
  #227
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by gascortado View Post
Hi all,

I'm trying to set up a random 3D velocity inlet similar to this:

variables "utau=.128;nu=1.51e-5;ux=utau*((1/.41)*(log(pos().y*(utau/nu))) ;uy=(1/2.5)*ux; uz=(1/2)*ux;";

valueExpression "vector (ux*rand() ,ux*rand(), uz*rand())";

I need these three components to be random and independent of each other. I realized however, that every time rand() is called in a specific time-step it generates the same random field so at the end ux, uy and uy are multiples of each other. That is not what I want.

Is it possible to generate three sets of random numbers for each time step using GroovyBC??
I see what the problem is: the random-number generator always uses the same seed. This behaviour comes from old FSF (where this function was reused from) and was introduced then to make the fields generated by FSF reproduceable (this will also mean that the random-field will stay the same for all time-steps). Anyway. I have an idea how to fix this. If a bug-report turns up on the swak4foam-Mantis (sorry. I will only fix this for swak) then I will have a look at it. If no bug-report turns up I will fix it when I need this

Bernhard
gschaider is offline   Reply With Quote

Old   May 16, 2011, 06:52
Default
  #228
Member
 
Santiago
Join Date: Dec 2009
Posts: 85
Rep Power: 9
gascortado is on a distinguished road
Thanks for your reply. Just FYI, the random numbers are changing at every timestep. Is swak4foam-Mantis another tool similar to GroovyBC? sorry, I'm not so familiar with what swak4foam-Mantis is. I dont know what FSF is either. Is there any way for me to get into the source code for this and fix it myself? I guess I will have to create my own BC and compile it right?
gascortado is offline   Reply With Quote

Old   May 16, 2011, 08:32
Default
  #229
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by gascortado View Post
Thanks for your reply. Just FYI, the random numbers are changing at every timestep. Is swak4foam-Mantis another tool similar to GroovyBC? sorry, I'm not so familiar with what swak4foam-Mantis is. I dont know what FSF is either. Is there any way for me to get into the source code for this and fix it myself? I guess I will have to create my own BC and compile it right?
FSF is short for funkySetField

The Mantis is the bug-tracker software. This is a web-application so you only need a login. Link to the one for swak4Foam can be found on the swak-Wikipage

Sources: of course they are. Links on how to get them (either by SVN or with mercurial) can be found on the Wiki-pages for groovyBC and swak. If you manage to fix it by yourself then patches/commits will of course be appreciated

The elegant way to fix it would be to modify the driver-method makeRandomSomething to not alway use the same seed or to modify the grammer so that the user can specify a seed with the random-function (like this 'random(42)')
gschaider is offline   Reply With Quote

Old   May 16, 2011, 11:27
Default groovyBC working
  #230
New Member
 
Dan Maciejewski
Join Date: Jun 2010
Location: State College, PA
Posts: 2
Rep Power: 0
DanScranton is on a distinguished road
Bernhard,

Thank you for your suggestion: indeed groovyBC was not available. I had included the library in controlDict, but had put it inside of functions(); and therefore was not seen by the application.

I am running OF 1.6-ext, and swak4Foam version is compatible with 1.7 or 1.6-ext.

Now it is running well; thanks for your contribution!

Cheers,
Daniel
DanScranton is offline   Reply With Quote

Old   June 14, 2011, 03:54
Default swak4Foam vs. groovyBC on OF 1.6-ext
  #231
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 10
Arnoldinho is on a distinguished road
I figured out some problems using swak4Foam in combination with interFoam and OF 1.6-ext, showing strange results near the inlet (see below). The aim was to generate 2nd order Stokes waves.

1. I compiled OF 1.6-ext from scratch just a few days ago, and afterwards simpleFunctionObject 1.6 and swak4Foam 1.7. All compiles without an error. Using groovyBC at the inlet, I got strange results in the internal mesh near the inlet, see figures one and two.



2. I erased swak4Foam and simpleFunctionObjects and instead compiled groovyBC 1.6. Results were as expected, see figure three.



Using swak4Foam on the same machine with OF 1.7.x gave the same, expected results as in (2.).

Arne
Arnoldinho is offline   Reply With Quote

Old   June 14, 2011, 05:58
Default
  #232
Senior Member
 
Dr. Alexander Vakhrushev
Join Date: Mar 2009
Posts: 217
Rep Power: 12
makaveli_lcf is on a distinguished road
Send a message via ICQ to makaveli_lcf
Hi Arne!

My remark is not regarding sawk4Foam:
do you complain that alpha field out of range [0..1]?
Is it just a post-processing or are those real alpha values?
I think it is due to convectional term discretization. I use modified interFoam solver
with alpha field limiting after it is calculated in alphaEqn.H.

Your comments?
__________________
Best regards,

Dr. Alexander VAKHRUSHEV

Christian Doppler Laboratory for "Advanced Process Simulation of
Solidification and Melting"

Simulation and Modelling of Metallurgical Processes
Department of Metallurgy
University of Leoben

Franz-Josef-Str. 18
A - 8700 Leoben
Österreich / Austria
Tel.: +43 3842 - 402 - 3125
http://smmp.unileoben.ac.at
makaveli_lcf is offline   Reply With Quote

Old   June 14, 2011, 08:31
Default
  #233
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 10
Arnoldinho is on a distinguished road
Good point Alexander. Never really thought about that... Yes, the values are calculated ones.

As I already use a modified interFoam solver and loop over my cells, I could integrate this as a limit as well. Although the speedup is only about three percent in my case...
But I'm not sure if this modification might have some disadvantages?

Arne
Arnoldinho is offline   Reply With Quote

Old   June 14, 2011, 11:41
Default
  #234
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Arnoldinho View Post
I figured out some problems using swak4Foam in combination with interFoam and OF 1.6-ext, showing strange results near the inlet (see below). The aim was to generate 2nd order Stokes waves.

1. I compiled OF 1.6-ext from scratch just a few days ago, and afterwards simpleFunctionObject 1.6 and swak4Foam 1.7. All compiles without an error. Using groovyBC at the inlet, I got strange results in the internal mesh near the inlet, see figures one and two.



2. I erased swak4Foam and simpleFunctionObjects and instead compiled groovyBC 1.6. Results were as expected, see figure three.



Using swak4Foam on the same machine with OF 1.7.x gave the same, expected results as in (2.).

Arne
That's a strange one. May I summarize:
1. OF-1.6-ext + swak4Foam from SVN: doesn't work
2. OF-1.6-ext + old-school groovyBC: works
3. OF-1.7.x + swak4Foam from SVN: works

One question: are you sure that this is not due to the change of what the pressure is in interFoam or other implementation differences (although the combination 2+3 speaks against this)

Would it be possible for you to file a bug-report at the extend-mantis, if possible with the case (it is "only" blockMesh is it?) or at least share the boundary conditions you used with us?

Bernhard
gschaider is offline   Reply With Quote

Old   June 14, 2011, 11:54
Default
  #235
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 10
Arnoldinho is on a distinguished road
Quote:
That's a strange one. May I summarize:
1. OF-1.6-ext + swak4Foam from SVN: doesn't work
2. OF-1.6-ext + old-school groovyBC: works
3. OF-1.7.x + swak4Foam from SVN: works
Yep, thats correct.

Quote:
One question: are you sure that this is not due to the change of what the pressure is in interFoam or other implementation differences (although the combination 2+3 speaks against this)
I took exactly the same case, (and changed p_rgh to pd in 0 folder, fvscheme and fvsolution from 1.7.x to 1.6-ext).

Quote:
Would it be possible for you to file a bug-report at the extend-mantis, if possible with the case (it is "only" blockMesh is it?) or at least share the boundary conditions you used with us?
I will put a bug report with a smaller test-case blockMesh in extend-mantis.

Arne
Arnoldinho is offline   Reply With Quote

Old   June 15, 2011, 07:00
Default
  #236
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 10
Arnoldinho is on a distinguished road
Quote:
That's a strange one. May I summarize:
1. OF-1.6-ext + swak4Foam from SVN: doesn't work
2. OF-1.6-ext + old-school groovyBC: works
3. OF-1.7.x + swak4Foam from SVN: works
Hmm, that's indeed strange: I just got the latest swak4Foam version and recompiled it. No I got similar, wrong results using OF 1.7.x as well! Has anything been changed the last few weeks, as I had an "older" swak4Foam version installed on that machine as it was working?
Does it make a difference, if I compile simpleFunctionObjects 1.6 and afterwards swak4Foam alone or only swak4Foam without sFO (but tried both)?

Arne
Arnoldinho is offline   Reply With Quote

Old   June 15, 2011, 08:22
Default
  #237
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Arnoldinho View Post
Hmm, that's indeed strange: I just got the latest swak4Foam version and recompiled it. No I got similar, wrong results using OF 1.7.x as well! Has anything been changed the last few weeks, as I had an "older" swak4Foam version installed on that machine as it was working?
I summarize again:

1. OF-1.6-ext + swak4Foam from SVN: doesn't work
2. OF-1.6-ext + old-school groovyBC: works
3. OF-1.7.x + swak4Foam from SVN: works
4. OF-1.7.x + swak4Foam new : doesn't work

Does "new" mean you're using the version from SVN or from Mercurial? Although I'm not aware of a difference between the two that might affect your problem?

Quote:
Originally Posted by Arnoldinho View Post
Does it make a difference, if I compile simpleFunctionObjects 1.6 and afterwards swak4Foam alone or only swak4Foam without sFO (but tried both)?
No. sFO and groovy don't affect each other.

What could be the case is that you're in a version of "DLL-Hell": there is a mix of libraries you're actually using. Check:

a) have a look the $FOAM_LIBBIN, $FOAM_USER_LIBBIN and $FOAM_SITE_LIBBIN. Whether there are different instances of libgroovyBC.so and the other swak-libraries

b) check with ldd (ldd $FOAM_LIBBIN/libgroovyBC.so) which other libraries groovyBC actually is using
gschaider is offline   Reply With Quote

Old   June 15, 2011, 08:41
Default
  #238
Senior Member
 
Dr. Alexander Vakhrushev
Join Date: Mar 2009
Posts: 217
Rep Power: 12
makaveli_lcf is on a distinguished road
Send a message via ICQ to makaveli_lcf
... you can also check your solver:

ldd `which interYourFoam`

just a comment)
__________________
Best regards,

Dr. Alexander VAKHRUSHEV

Christian Doppler Laboratory for "Advanced Process Simulation of
Solidification and Melting"

Simulation and Modelling of Metallurgical Processes
Department of Metallurgy
University of Leoben

Franz-Josef-Str. 18
A - 8700 Leoben
Österreich / Austria
Tel.: +43 3842 - 402 - 3125
http://smmp.unileoben.ac.at
makaveli_lcf is offline   Reply With Quote

Old   June 15, 2011, 09:45
Default
  #239
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,013
Rep Power: 43
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by makaveli_lcf View Post
... you can also check your solver:

ldd `which interYourFoam`

just a comment)
I'm afraid that won't work, because usually groovyBC is dynamically loaded via the libs entry in the controlDict and ldd doesn't know about that. If groovyBC is linked into the solver (you can do that, but I don't recommend it) then this will work

Bernhard
gschaider is offline   Reply With Quote

Old   June 15, 2011, 15:04
Default
  #240
Senior Member
 
Dr. Alexander Vakhrushev
Join Date: Mar 2009
Posts: 217
Rep Power: 12
makaveli_lcf is on a distinguished road
Send a message via ICQ to makaveli_lcf
Bernhard,

thank you for your clarification! I usually link my libs via "options" file in Make directory,
to check their presence at the link stage of compilation... So then it works)
__________________
Best regards,

Dr. Alexander VAKHRUSHEV

Christian Doppler Laboratory for "Advanced Process Simulation of
Solidification and Melting"

Simulation and Modelling of Metallurgical Processes
Department of Metallurgy
University of Leoben

Franz-Josef-Str. 18
A - 8700 Leoben
Österreich / Austria
Tel.: +43 3842 - 402 - 3125
http://smmp.unileoben.ac.at
makaveli_lcf is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
FunkySetFields for OF 141 mer OpenFOAM Pre-Processing 71 June 11, 2014 11:34
Running funkySetFields sara OpenFOAM Running, Solving & CFD 10 October 3, 2012 10:08
FunkySetFields dictionary gschaider OpenFOAM Running, Solving & CFD 14 December 3, 2008 22:13
FunkySetFields for cyclic bc zakifoam OpenFOAM Pre-Processing 1 December 18, 2007 08:24


All times are GMT -4. The time now is 22:45.