# [swak4Foam] 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

March 2, 2011, 13:27
#221
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by ivan_cozza 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

March 3, 2011, 03:47
#222
Senior Member

Ivan Flaminio Cozza
Join Date: Mar 2009
Location: Torino, Piemonte, Italia
Posts: 207
Rep Power: 11
Quote:
 Originally Posted by gschaider 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

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

Thanks,
Ivan

March 3, 2011, 10:15
#223
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by ivan_cozza 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

 May 12, 2011, 18:23 #224 New Member   Dan Maciejewski Join Date: Jun 2010 Location: State College, PA Posts: 2 Rep Power: 0 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::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()

 May 14, 2011, 11:15 #225 Member   Santiago Join Date: Dec 2009 Posts: 85 Rep Power: 10 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??

May 16, 2011, 05:00
#226
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
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 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::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()

May 16, 2011, 05:14
#227
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by gascortado 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

 May 16, 2011, 06:52 #228 Member   Santiago Join Date: Dec 2009 Posts: 85 Rep Power: 10 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?

May 16, 2011, 08:32
#229
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by gascortado 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)')

 May 16, 2011, 11:27 groovyBC working #230 New Member   Dan Maciejewski Join Date: Jun 2010 Location: State College, PA Posts: 2 Rep Power: 0 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

 June 14, 2011, 03:54 swak4Foam vs. groovyBC on OF 1.6-ext #231 Senior Member   Arne Stahlmann Join Date: Nov 2009 Location: Hanover, Germany Posts: 209 Rep Power: 11 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

 June 14, 2011, 05:58 #232 Senior Member   Dr. Alexander Vakhrushev Join Date: Mar 2009 Posts: 230 Rep Power: 12 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 http://smmp.unileoben.ac.at

 June 14, 2011, 08:31 #233 Senior Member   Arne Stahlmann Join Date: Nov 2009 Location: Hanover, Germany Posts: 209 Rep Power: 11 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

June 14, 2011, 11:41
#234
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by Arnoldinho 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

June 14, 2011, 11:54
#235
Senior Member

Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 11
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

June 15, 2011, 07:00
#236
Senior Member

Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 11
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

June 15, 2011, 08:22
#237
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by Arnoldinho 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 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

 June 15, 2011, 08:41 #238 Senior Member   Dr. Alexander Vakhrushev Join Date: Mar 2009 Posts: 230 Rep Power: 12 ... 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 http://smmp.unileoben.ac.at

June 15, 2011, 09:45
#239
Assistant Moderator

Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,045
Rep Power: 43
Quote:
 Originally Posted by makaveli_lcf ... 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

 June 15, 2011, 15:04 #240 Senior Member   Dr. Alexander Vakhrushev Join Date: Mar 2009 Posts: 230 Rep Power: 12 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 http://smmp.unileoben.ac.at

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Qingsong FLUENT 0 August 7, 2017 11:08 Saima CFX 45 September 22, 2015 10:53 David121284 ANSYS Meshing & Geometry 0 April 11, 2014 04:19 thezack FLUENT 0 June 4, 2013 22:09 IndrajitW FLUENT 0 March 30, 2013 09:03

All times are GMT -4. The time now is 11:19.