[gschaider]

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

[ivan_cozza]

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

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

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

Thanks,
Ivan

[gschaider]

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

[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<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

[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??

[gschaider]

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?

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<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]

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

[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?

[gschaider]

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)')

[DanScranton]

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

[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

[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?

[Arnoldinho]

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

[gschaider]

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

[Arnoldinho]

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.

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).

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]

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

[gschaider]

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?

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

[makaveli_lcf]

... you can also check your solver:

ldd `which interYourFoam`

just a comment)

[gschaider]

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

[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)