[gschaider]

Originally Posted by braennstroem

thanks for the info! Shouldn't be so hard sounds good ...

But doesn't mean it will happen in the next days. Sorry.

[gschaider]

Originally Posted by gautami

Hello,

I am trying to simulate a wave tank case in interDyMFoam.
I have set the inlet as groovyBC.
I want to set the expression for the inlet in pointMotionUx dictionary as follows:

if (time>1 and time<=2 expression-1) if (time>2 and time<3 expression-2) else zero.

I am trying to do it a follows,but I get an error.

valueExpression "toPoint((time()>1 && time()<=2) ? A*w*cos(w*time()) (time()>2 && time()<3) ? B*v*cos(w*time()) : 0 )";

How do I input such expression?

There is at least a ':' missing (between the first expression and the second condition)

Bernhard

[podallaire]

Hi Bernhard,

I was playing with groovyBC today and it appears that "epsilon" was not
recognized whereas "k" was - am I missing something ?

Thanks !

PO

[gschaider]

Originally Posted by podallaire

Hi Bernhard,

I was playing with groovyBC today and it appears that "epsilon" was not
recognized whereas "k" was - am I missing something ?

I don't quite understand. You mean you have a boundary condition where the expression contains a k or an epsilon and for one it works and for the other it doesn't. Could you please be a bit more specific? When does it fail? Which field? Which solver?

I have a suspicion (the field has not yet been created in memory) but I need more information

Bernhard

[podallaire]

Hi,

I'm defining a BC condition in field nut at time=0 using k and epsilon, solver
is pisoFoam but you are right, if I'm using a turbulence model that is not loading epsilon, well I cannot use it - thanks for your comments. I forgot
about that yesterday when using kOmegaSST.

Regards,

PO

[mks]

Hello,

after some variations with gamma-alpha1 and some others I just got the demo WaveTank working. But the waves seem to stay in the tank (reflection on the outlet) and not to go "through" the wall. Any ideas how to fix (change) it?

[gautami]

Hello Mr Gschaider,

I am having a small trouble with valueExpression.

I need to specify flap wave maker expression for velocity="(y*(A/h)*w*cos(w*t))" of moving wall.

Baased on discussion earlier I understood that it has to be specified as follows:

valueExpression "toPoint((time()>0.0) ? pos().y*(A/h)*w*cos(w*time()) : 0)";--in the pointMotionUx dictionary.
valueExpression "((time()>0.0) ? toFace(pointMotionUx): 0 )"; ---in the cellMotionUx dictionary.
valueExpression "(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)";--in the U dictionary.

My simulation runs fine with no errors,but my results of free surface elevation is not quite satisfactory.

I may be wrong but I am thinking that it is because I am not specifying the expression correctly and so I tried to change my expression using pts().y as follows

valueExpression "(time()>0.0) ? pts().y*toPoint((A/h)*w*cos(w*time())) : 0";
valueExpression "((time()>0.0) ? toFace(pointMotionUx): 0 )";
valueExpression "(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)";


but I get an error as follows

Parser Error at "1.15-17" :"syntax error, unexpected TOKEN_points"
"(time()>0.0) ? pts().y*toPoint((A/h)*w*cos(w*time())) : 0"
" ^^^ "

Can you please suggest,how do I specify the flap wave maker velocity for the moving wall correctly.

Regards,
Gautami.

[gautami]

Hello Mr Gschaider,

For the piston wave maker I need to specify the velocity=A*w*cos(w*t) for the moving wall
I have been doing this as follows:

valueExpression ""toPoint((time()>0.0) ? A*w*cos(w*time()) : 0)";--in the pointMotionUx dictionary.
valueExpression "((time()>0.0) ? toFace(pointMotionUx): 0 )"; ---in the cellMotionUx dictionary.
valueExpression "(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)";--in the U dictionary.
My simulations run fine witout errors.
But for different values of A and w I dont not get the correct free surface elevation.For example the free surface elevation graph does not start from zero,instead it starts either above or below zero.

Can you please let me know if the problem is with the way I am specifying the expression or it is something else.


Regards,
Gautami.

[gschaider]

Originally Posted by gautami

Hello Mr Gschaider,

I am having a small trouble with valueExpression.

I need to specify flap wave maker expression for velocity=&quot;(y*(A/h)*w*cos(w*t))&quot; of moving wall.

Baased on discussion earlier I understood that it has to be specified as follows:

valueExpression &quot;toPoint((time()>0.0) ? pos().y*(A/h)*w*cos(w*time()) : 0)&quot;;--in the pointMotionUx dictionary.
valueExpression &quot;((time()>0.0) ? toFace(pointMotionUx): 0 )&quot;; ---in the cellMotionUx dictionary.
valueExpression &quot;(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)&quot;;--in the U dictionary.

My simulation runs fine with no errors,but my results of free surface elevation is not quite satisfactory.

I may be wrong but I am thinking that it is because I am not specifying the expression correctly and so I tried to change my expression using pts().y as follows

valueExpression &quot;(time()>0.0) ? pts().y*toPoint((A/h)*w*cos(w*time())) : 0&quot;;
valueExpression &quot;((time()>0.0) ? toFace(pointMotionUx): 0 )&quot;;
valueExpression &quot;(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)&quot;;


but I get an error as follows

Parser Error at &quot;1.15-17&quot; :&quot;syntax error, unexpected TOKEN_points&quot;
&quot;(time()>0.0) ? pts().y*toPoint((A/h)*w*cos(w*time())) : 0&quot;
&quot; ^^^ &quot;

Can you please suggest,how do I specify the flap wave maker velocity for the moving wall correctly.

Regards,
Gautami.

Basically the problem seems to be that the first expression (time()>0) is a cell value and the parser therefor expects b and c in &quot;a ? b : c&quot; to be cell values, too. Enclose the condition with a toPoint and the constant at place c, too. (Havn't verified this, but am pretty sure that this is the problem)
Bernhard

[gschaider]

Originally Posted by gautami

Hello Mr Gschaider,

For the piston wave maker I need to specify the velocity=A*w*cos(w*t) for the moving wall
I have been doing this as follows:

valueExpression &quot;&quot;toPoint((time()>0.0) ? A*w*cos(w*time()) : 0)&quot;;--in the pointMotionUx dictionary.
valueExpression &quot;((time()>0.0) ? toFace(pointMotionUx): 0 )&quot;; ---in the cellMotionUx dictionary.
valueExpression &quot;(time()>0.0) ? vector(toFace(pointMotionUx),0,0) : vector(0,0,0)&quot;;--in the U dictionary.
My simulations run fine witout errors.
But for different values of A and w I dont not get the correct free surface elevation.For example the free surface elevation graph does not start from zero,instead it starts either above or below zero.

Can you please let me know if the problem is with the way I am specifying the expression or it is something else.


Regards,
Gautami.

I don't quite get the problem: cos(w*t) should be 1 for t=0, shouldn't it? If you want it to be zero, call it sin

[WiWo]

Hello everybody,

I have started using groovyBC recently and I must say that it's really awesome! Thanks a lot for this contribution :-)

Anyway ... here comes my issue. I'm using dev-1.5 and groovyBC is getting along fine. But this week I was using groovyBC in connection with the icoFsiFoam solver, which is capable of doing fluid-structure-interaction as well as the respective mesh motion.
GroovyBC again worked fine in p and U - but what I need to do is have a definded transient wall deformation (which is possible by setting BC in motionU - I already succeeded using oscillationFixedValue but for my purpose I need more flexibility).
Now motionU is an object of tetPointVectorField class (not volScalarField or volVectorField as p or U) and groovyBC is refused with the following statement:

Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: laplaceFaceDecomposition


Unknown patchField type groovyBC for patch type patch

Valid patchField types are :

15
(
symmetryPlane
oscillatingFixedValue
empty
fixedValue
mixed
componentMixed
processor
calculated
slip
timeVaryingUniformFixedValue
generic
value
global
wedge
zeroGradient
)


file: /home/wolfgang/Foams/playFoams/bloodVesselFSIsimple_longVessel_oscillating/fluid/0/motionU::topWall from line 41 to line 44.

From function PointPatchField<PatchField, Mesh, PointPatch, MatrixType, Type>::New(const PointPatch&, const DimensionedField<Type, Mesh>&, const dictionary&)
in file /home/wolfgang/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/newPointPatchField.C at line 221.

FOAM exiting

Is there anything I can do to make groovyBC work inside motionU? It would of course be fantastic to be able to define transient wall motion in an analytical way by using groovyBC.
Has anybody ever done such a thing or is this a stupid approach? I would be grateful for any advice or hint :-)

Cheers,
Wolfgang

[gautami]

Hello Mr Gschaider,

Thank you for your suggestions.Still working on it.Will let you know once I get good results.

Regards,
Gautami.

[philippose]

Hello Gschaider,

A Good Evening to you!

I am surprised that though I have been using OpenFOAM for almost three years now, I have not had the opportunity to look into such an excellent contribution such as the groovyBC :-)!

I must say, it is seriously "groovy" :-)! Thanks a lot!

Recently I had the need to come up with a way of coupling two patches, such that the pressure on one patch (inlet), is dependent on the pressure on an another patch (outlet1) via a simple expression like:

p(inlet) = mean[p(outlet)]*m + c


After trying for a couple of hours to come up with a new boundary condition for OpenFOAM without success, I solved the problem by modifying my toplevel solver (in this case, simpleFoam) to read in a Master patch and Slave patch from a new dictionary file (called coupledPatchDict), along with a factor (m) and offset (c).

Continuing with my example,
.... Master patch = outlet1
.... Slave patch = inlet
.... m = 0.0
.... c = <a constant>

.... Slave patch = (Master patch)*m + c

This method worked very well, but I don't like that fact that the implementation is so specific..... starting from modification of a top-level solver, to the fact that as of now I can only specify one master patch and one slave patch, and also, that the field which is modified (in this case "p") is hard-coded into the modified solver.

Do you think it would be possible to extend the groovyBC boundary condition in order to support such coupled systems?

An additional entry like the timelines entry... for example "coupledPatches" or just "patches" could be used to specify something like:

patches (
.... {
.......... name <variable name to use within groovyBC expression>;
.......... patch <patch1>;
.......... field <field on patch to use>;
.......... component <component of field to use>; ---> in case of vectorField or "magnitude"?
.... }
);


What do you say?

Have a nice day!

Philippose

[gschaider]

Originally Posted by WiWo

Hello everybody,

<cut>

Now motionU is an object of tetPointVectorField class (not volScalarField or volVectorField as p or U) and groovyBC is refused with the following statement:

<cut>

file: /home/wolfgang/Foams/playFoams/bloodVesselFSIsimple_longVessel_oscillating/fluid/0/motionU::topWall from line 41 to line 44.

From function PointPatchField<PatchField, Mesh, PointPatch, MatrixType, Type>::New(const PointPatch&, const DimensionedField<Type, Mesh>&, const dictionary&)
in file /home/wolfgang/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/newPointPatchField.C at line 221.

FOAM exiting

Is there anything I can do to make groovyBC work inside motionU? It would of course be fantastic to be able to define transient wall motion in an analytical way by using groovyBC.
Has anybody ever done such a thing or is this a stupid approach? I would be grateful for any advice or hint :-)

I'm afraid there is no trivial way to get this to work. tetPoint-Field is special to the dev-version and I'm not sure whether they map trivially to the point-Field (for which there is already a boundary-condition in groovyBC). You might get lucky if you copy the files from groovyBCpointPatchField to something like groovyBCtetPointPatchField and adapt those to use the corresponding tet-types. What will definitly not work with that approach is accessing other tetPoint-Fields (only volume and point), for that you'd have to modify the parser and the lexer.

Bernhard

[gschaider]

Originally Posted by philippose

An additional entry like the timelines entry... for example "coupledPatches" or just "patches" could be used to specify something like:

patches (
.... {
.......... name <variable name to use within groovyBC expression>;
.......... patch <patch1>;
.......... field <field on patch to use>;
.......... component <component of field to use>; ---> in case of vectorField or "magnitude"?
.... }
);

I've been thinking about such an extension (actually it was requested by someone else some time ago) and will add it once I find the time to do so (it is not too hard, but I need to do some changes to the parser). The biggest restriction would be that from the other patch only a single value (an average, min, max or similar) could be used as for a general face-to-face mapping some serious checks would have to be done (how are the two patches aligned, have they conformal meshes) which would either result in a lot of code and/or terribly confusing options

Bernhard

[philippose]

Hello Bernhard,

A Good Afternoon to you!

Cool :-)! So I am not the first to want something like this. I had looked around on the forum, but found no similar requirements from anyone else, and hence resorted to modifying the solver myself.

It is true that we can only expect to extract a single value from the Master patch. In my case, I took the area weighted average value of the pressure. I dont think it would be required to implement a generic mapping method.

I guess providing a couple of options like "min", "max", "mean", etc as part of the specification dictionary would suffice for most normal cases. adding on a dictionary key like "extract" should be sufficient.

Is there any way I can be of any help for implementing something like this into groovyBC? I briefly looked through the source files, but the parser part was literally "Greek and latin" for me :-)! Am not (yet) familiar with bison or yylexer, etc...

Have a nice day, and thank you for the response :-)!

Philippose

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Good Afternoon to you!

Cool :-)! So I am not the first to want something like this. I had looked around on the forum, but found no similar requirements from anyone else, and hence resorted to modifying the solver myself.

It is true that we can only expect to extract a single value from the Master patch. In my case, I took the area weighted average value of the pressure. I dont think it would be required to implement a generic mapping method.

I guess providing a couple of options like "min", "max", "mean", etc as part of the specification dictionary would suffice for most normal cases. adding on a dictionary key like "extract" should be sufficient.

Basically what I'm intending to do is evaluate an expression on a remote patch and then apply one of those functions to it

Originally Posted by philippose

Is there any way I can be of any help for implementing something like this into groovyBC? I briefly looked through the source files, but the parser part was literally "Greek and latin" for me :-)! Am not (yet) familiar with bison or yylexer, etc...

Basically the problem is to rewrite the Driver-class in such a way that it can parse and evaluate stuff on a remote patch. In order to do this one has to introduce some subtle changes.

There are two ways you can help:
- provide me with a simple (preferably tutorial-based) test-case
- have patience

Bernhard

[philippose]

Hello Bernhard,

A Very Good Evening to you :-)!

I just happened to be looking into the OpenFOAM-dev SVN repository, and found the changes you have made to GroovyBC :-)!

All I can say is.... wow :-)! You implemented the ability to couple patches via expressions!! Thank you very much!

On the other hand, I am feeling extremely sheepish now for not having sent you a test-case. I have no excuses for it except for "laziness", and I am very sorry...

Does this version of GroovyBC also work on OpenFOAM-1.5-dev? I have not yet started using OpenFOAM-1.6, and I prefer to stick to the "-dev" versions.

Shall try to compile the latest version of GroovyBC on OpenFOAM-1.5-dev, and let you know how it works out on the case I had.

I hope this time atleast I can post some pictures and a case too....

Once again.... thank you!

Have a nice evening ahead!

Philippose

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Very Good Evening to you :-)!

I just happened to be looking into the OpenFOAM-dev SVN repository, and found the changes you have made to GroovyBC :-)!

All I can say is.... wow :-)! You implemented the ability to couple patches via expressions!! Thank you very much!

On the other hand, I am feeling extremely sheepish now for not having sent you a test-case. I have no excuses for it except for "laziness", and I am very sorry...

Does this version of GroovyBC also work on OpenFOAM-1.5-dev? I have not yet started using OpenFOAM-1.6, and I prefer to stick to the "-dev" versions.

Shall try to compile the latest version of GroovyBC on OpenFOAM-1.5-dev, and let you know how it works out on the case I had.

I hope this time atleast I can post some pictures and a case too....

Once again.... thank you!

Have a nice evening ahead!

Philippose

Hi Philippose!

No problem with the test-case. There is always a chance to make it up .

I think back-porting the changes to 1.5(-dev) should be rather easy (if I remember it correctly the majority of the effort to port groovy from 1.5 to 1.6 was modifying the demo-cases so that they work again). Should you succeed, you can check them into the SVN (that would be nice).

Bernhard

[philippose]

Hello Bernhard,

Yet another Good Evening to you, though it could start getting a little warmer now :-)!! My eyes are getting bored of seeing black, white and grey... !!

I thought I would give you a first status update regarding the coupling facility you added to groovyBC recently:

1. I checked out the OF-1.6 version of groovyBC from SVN today, and directly, without making any changes, compiled it on OpenFOAM-1.5-dev.... Result: It worked without a hitch :-) So it looks like you could simply copy all the changes you made on the 1.6-branch of groovyBC to the 1.5-branch

2. Using help from the demo case which you set up to showcase this new feature, I modified my case for which I had used my modified simpleFoam solver earlier.... to use groovyBC together with the standard simpleFoam solver.... Result: It worked very well :-)! The fields converged to the same values I had seen earlier, and the groovyBC feature worked exactly as I hoped :-)!

3. An additional test-case for the repository.... I shall see if I can actually give out a modified version of the case I ran for inclusion into the groovyBC suite.

4. For others who might want to try out this cool feature.... here are my "0/p", "0/U" and "system/controlDict" files.....

*** "0/p" file -->

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 2352.9411;  // 20 bar

boundaryField
{
    fixedWalls
    {
        type            zeroGradient;
    }
    inlet
    {
        type            groovyBC;
        valueExpression "pLS+(9.5*100000.0/850.0)";
        variables       "pLS@outletLS=sum(p*mag(Sf()))/sum(mag(Sf()));";    // Calculates the average value of p at the LS patch
        value           uniform 2352.9411;
    }
    outlet
    {
        type            fixedValue;
        value           $internalField;
    }
    outletLS
    {
        type            zeroGradient;
    }
}

*** "0/U" file -->

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    fixedWalls
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    inlet
    {
        type            pressureInletVelocity;
        value           uniform (0 0 0);
    }
    outlet
    {
        type            zeroGradient;
    }
    outletLS
    {
        type            fixedValue;
        value           uniform (0 0.67905 0);
    }
}

*** "system/controlDict" file -->

application     simpleFoam;

startFrom       latestTime;

startTime       0;

stopAt          endTime;

endTime         2000;

deltaT          1;

writeControl    timeStep;

writeInterval   10;

purgeWrite      2;

writeFormat     ascii;

writePrecision  6;

writeCompression compressed;

timeFormat      general;

timePrecision   6;

graphFormat     gnuplot;

runTimeModifiable yes;

libs ("libgroovyBC.so");

functions
(
    massFlow
    {
        type patchMassFlow;
        
        functionObjectLibs ("libsimpleFunctionObjects.so");

        verbose true;
        
        patches
        (
           inlet
           outlet
           outletLS
        );

        factor 60000.0;
    }    
);

5. I shall post screenshots of the current case which I ran as soon as Paraview has finished compiling on my system (its busy right now :-)!)


Have a great day ahead!

Philippose