[gschaider]

Originally Posted by Alex3262

Dear Bernard,

I am a student of shipbuilding. At the moment I am writing my bachelor thesis.
Therefore I am using your swirl, which you have published on the website: http://openfoamwiki.net/index.php/Contrib_groovyBC
I do know how the swirl is working, but I am not sure, how the swirl looks alike.
What i want to adjust:
I want to indicate a swirl at the Inlet, which goes through the domain, so that I can map the results at my simulation.
Below you can see my actual swirl. For the construction I have used your parameters. This swirl drifts along the y axis.
Unfortunately i do not believe that this is how your swirl should look alike. The swirl originates at the beginning of my plate, that’s why I believe that the plate is causing the swirl.
Would it be possible that you send me images of your swirl? Or do you have any advice for me, how to accomplish my swirl?
Your information on CFD-online are really helpful and I am grateful, that you are such an active user of CFD-online.


screenshots: https://www.dropbox.com/sh/t6uuyhhaslmcsoi/RRK13N6Um-
Code:
inlet
{
type groovyBC;
variables "rpm=8000.0;Un=55.8;c=sum(pos()*mag(Sf()))/sum(mag(Sf()));n=sum(normal())/mag(sum(normal()));p=pos()-c;r=mag(p)+1.0e-10;R=max(r);xt=vector(n.y,-n.x,0);xT=xt/mag(xt);yt=vector(-n.x*n.z,-n.y*n.z,n.x*n.x+n.y*n.y);yT=yt/mag(yt);";
valueExpression "-Un*normal() + (rpm*pi/30)*((p & yT)*xT - (p & xT)*yT)";
}


Kind regards,
Alexander

The usage example of the swirl was not added by my to the page: http://openfoamwiki.net/index.php?ti...730&oldid=9729

If I interpret Niklas' equations correctly he assumes that the swirl-axis is the Z-axis (and in your case it is Y if I understand you correctly). Use your mathematical common sense to reformulate it (& is the inner product of vectors. I think it could be shorter by using ^ for the cross-product)

[aujamal20]

Dear
I want to know that is groovyFlowRateInletVelocity is valid in OF 2.1.0 and if so how to use this BC to define time dependent flow rate at an oultlet patch.

[gschaider]

Originally Posted by aujamal20

Dear
I want to know that is groovyFlowRateInletVelocity is valid in OF 2.1.0 and if so how to use this BC to define time dependent flow rate at an oultlet patch.

To quote from the README:

*** Discontinued features
**** =groovyFlowRateInletVelocity=
This boundary condition will be removed in future releases
because the base class now supports the more general
=DataEntry=-class for which a =swak=-subclass exists

This means: it is still in the release, but will be discontinued because the regular flowRateInletVelocity now has a facility to do time-dependent flow rates. swak implements a sub-class to that DataEntry-class. So if you include libswak4FoamParsers.so into the libs-entry you will still be able to use swak-expressions.

Using that boundary condition on the outlet is not a good idea (applying a fixedValue for the velocity on the outlet is almost never a good idea). But you can try (but at least give velocity at least one boundary that is zeroGradient or equivalent

For an example that uses the DataEntry see Examples/tests/swakDataEntry/flowRateAngledDuct

For an example that uses groovyFlowRateInletVelocity see Examples/groovyBC/multiRegionHeaterFeedback

[albem]

Hello Foamers

I have tried to install swak4foam in OpenFOAM-1.6-ext (Ubuntu 12.04) without any succes I got plenty of errors some of them are

lnInclude/FaPatchValueExpressionDriver.H:63:47: fatal error: FaPatchValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
In file included from FaPatchValueExpressionDriver.C:37:0:
FaPatchValueExpressionDriver.H:63:47: fatal error: FaPatchValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
In file included from FaFieldValueExpressionDriver.C:33:0:
FaFieldValueExpressionDriver.H:48:47: fatal error: FaFieldValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
....
....
....
FaPatchValueExpressionParser.tab.cc:9304:24: warning: use of old-style cast [-Wold-style-cast]
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaPatchValueExpressionDriver.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaPatchValueExpressionLexer.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaFieldValueExpressionLexer.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/groovyBCFaPatchFields.o] Error 1


I DO NOT LIKE "a hardware or OS problem"

Please take a look on the file attached about the compilation process

Any help is wellcome

Originally Posted by gschaider

That's the way it is: swak4foam supports no distro completely. For 1.6-ext those two examples do not work, for 1.7 the finiteArea stuff does not work

Seriously: I also built a swak4foam-package for 1.7.1. The problem is that I can't distribute it via launchpad because launchpad instists (which is a good thing) to rebuild packages from the sources. To do so it has got to install openfoam171 in a virtual machine and I don't know how to do that with a package which is not on the official ubuntu-severs and not in a launchpad-PPA. And I don't have the time to repackage 1.7 (especially as the debian-directory was removed from the 1.7-git - there are stil traces of it there)

BUT: if you have the sources (the version from mercurial. Probably also works with the one from SVN) you can always build your own debian package and install it locally (just make sure that your shell is set to the OF-distro that you want to build for and say "make dpkg")

[gschaider]

Originally Posted by albem

Hello Foamers

I have tried to install swak4foam in OpenFOAM-1.6-ext (Ubuntu 12.04) without any succes I got plenty of errors some of them are

lnInclude/FaPatchValueExpressionDriver.H:63:47: fatal error: FaPatchValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
In file included from FaPatchValueExpressionDriver.C:37:0:
FaPatchValueExpressionDriver.H:63:47: fatal error: FaPatchValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
In file included from FaFieldValueExpressionDriver.C:33:0:
FaFieldValueExpressionDriver.H:48:47: fatal error: FaFieldValueExpressionParser.tab.hh: No such file or directory
compilation terminated.
....
....
....
FaPatchValueExpressionParser.tab.cc:9304:24: warning: use of old-style cast [-Wold-style-cast]
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaPatchValueExpressionDriver.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaPatchValueExpressionLexer.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/FaFieldValueExpressionLexer.o] Error 1
The bug is not reproducible, so it is likely a hardware or OS problem.
make: *** [Make/linux64GccDPOpt/groovyBCFaPatchFields.o] Error 1


I DO NOT LIKE "a hardware or OS problem"

Please take a look on the file attached about the compilation process

Any help is wellcome

First the good news: the majority of swak4Foam has compiled OK. Seems like the problem is "only" with the FAM-stuff. Bad news: I'm a bit amazed. But I've got an idea: is it possible that $WM_NCOMPROCS is set (possibly to a large value). This can be a problem because the compilation of the yy-files produces headers that later files (grovvy-something) need. Try unsetting the variable and recompile (it also might be possible that it you don't have to unset the variable. Just recompile)

[linch]

Hi all,

a short question: how to use variables in funkySetFields?

Example (funkySetFieldsDict):

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      funkySetFieldsDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
variables
(   
    "dropCenter=vector(0.3176e-3,0.3176e-3,0.3176e-3);"
    "R=79.4e-06;"
    "f1=0.630436"
    "f2=0.630436"
    "f3=2.521744"
);

expressions
(
    createDroplet
    {
        field alpha1;
        expression "1";
        condition  "f1*pow(pos().x-dropCenter.x,2)+f2*pow(pos().y-dropCenter.y,2)+f3*pow(pos().z-dropCenter.z,2)<pow(R,2)";

    }
);

returns an error:

Parser Error at "1.1-2" :"field f1 not existing or of wrong type"
"f1*pow(pos().x-dropCenter.x,2)+f2*pow(pos().y-dropCenter.y,2)+f3*pow(pos().z-dropCenter.z,2)<pow(R,2)"
" ^^

so obviously I'm defining variables in the wrong way

[gschaider]

Originally Posted by linch

Hi all,

a short question: how to use variables in funkySetFields?

Example (funkySetFieldsDict):

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      funkySetFieldsDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
variables
(   
    "dropCenter=vector(0.3176e-3,0.3176e-3,0.3176e-3);"
    "R=79.4e-06;"
    "f1=0.630436"
    "f2=0.630436"
    "f3=2.521744"
);

expressions
(
    createDroplet
    {
        field alpha1;
        expression "1";
        condition  "f1*pow(pos().x-dropCenter.x,2)+f2*pow(pos().y-dropCenter.y,2)+f3*pow(pos().z-dropCenter.z,2)<pow(R,2)";

    }
);

returns an error:so obviously I'm defining variables in the wrong way

Move it into the createDroplets-subdictionary. Or add "variables $variables;" there.

As a rule-of-thumb in swak variables are taken from the same place as the expression.

[nik]

Hi,

I am using Swak4Foam_2.x_release_0.2.3 with OpenFOAM-2.2.x. I am trying to define a heat flux using groovyBC:

This is the boundary condition I use for temperature

 CAVITY_BACK
    {
        type            groovyBC;
        value           uniform $refTemp;
        valueExpression "573.15";
        gradientExpression "gradT";
        fractionExpression "0";
        variables
        (
            "heatFlux=  37000;"
            "rho=1.9e+03;"
            "cp=1.54e+03;"
            "nu=1.72e-06;"
            "pr=9.75;"
            "kappa=nu/pr;"
            "gradT=heatFlux/((kappa+kappat)*rho*cp);"
        );
    }

The code (buoyantBoussinesqPimpleFoam) runs and the results look OK. The only question that I have is related to the following warning that I get in the output log file:

Courant Number mean: 1.62363e-05 max: 0.0521217
deltaT = 4.89936e-05
DILUPBiCG:  Solving for Ux, Initial residual = 0.000397252, Final residual = 5.73223e-10, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 0.000148742, Final residual = 1.32665e-10, No Iterations 1
DILUPBiCG:  Solving for Uz, Initial residual = 0.000536376, Final residual = 7.73942e-10, No Iterations 1
[1] swak4Foam: Allocating new repository for sampledGlobalVariables
[2] swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning : 
    From function CommonValueExpressionDriver::evaluateVariable
    in file CommonValueExpressionDriver.C at line 924
    There is a field named nu of type IOobject found which may be shadowed by the variable of the same name.
This may lead to trouble
If this is OK set 'variableNameIdenticalToField' in the relevant parser

[0] swak4Foam: Allocating new repository for sampledGlobalVariables
[3] swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning : 
    From function CommonValueExpressionDriver::evaluateVariable
    in file CommonValueExpressionDriver.C at line 924
    There is a field named nu of type IOobject found which may be shadowed by the variable of the same name.
This may lead to trouble
If this is OK set 'variableNameIdenticalToField' in the relevant parser

DILUPBiCG:  Solving for T, Initial residual = 0.00265407, Final residual = 4.90932e-10, No Iterations 1
GAMG:  Solving for p_rgh, Initial residual = 0.0641449, Final residual = 0.000572967, No Iterations 5
time step continuity errors : sum local = 4.20113e-12, global = -1.03896e-14, cumulative = -1.03896e-14
GAMG:  Solving for p_rgh, Initial residual = 0.0243003, Final residual = 8.95937e-07, No Iterations 21
time step continuity errors : sum local = 6.36208e-15, global = 6.04629e-17, cumulative = -1.03291e-14
DILUPBiCG:  Solving for omega, Initial residual = 1.48881e-05, Final residual = 3.6477e-11, No Iterations 1
DILUPBiCG:  Solving for k, Initial residual = 0.000656271, Final residual = 9.90796e-11, No Iterations 1
bounding k, min: 9.9996e-16 max: 0.0003 average: 7.59597e-09
ExecutionTime = 73.15 s  ClockTime = 76 s

How do I get rid of this warning?

Nicolas

[Anne Lincke]

Rename your variable nu?

[nik]

Originally Posted by Anne Lincke

Rename your variable nu?

I tried that and it stills gives me the same warning, even though only once this time:

Courant Number mean: 3.14183e-09 max: 0.000291297
deltaT = 1.12045e-05
DILUPBiCG:  Solving for Ux, Initial residual = 1, Final residual = 8.48153e-11, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 1, Final residual = 8.48551e-11, No Iterations 1
DILUPBiCG:  Solving for Uz, Initial residual = 1, Final residual = 7.23982e-11, No Iterations 1
[3] swak4Foam: Allocating new repository for sampledGlobalVariables
[2] swak4Foam: Allocating new repository for sampledGlobalVariables
[1] swak4Foam: Allocating new repository for sampledGlobalVariables
[0] swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning :
    From function CommonValueExpressionDriver::evaluateVariable
    in file CommonValueExpressionDriver.C at line 924
    There is a field named nu of type IOobject found which may be shadowed by the variable of the same name.
This may lead to trouble
If this is OK set 'variableNameIdenticalToField' in the relevant parser

DILUPBiCG:  Solving for T, Initial residual = 0.993214, Final residual = 2.27937e-10, No Iterations 1
GAMG:  Solving for p_rgh, Initial residual = 1, Final residual = 0.00873422, No Iterations 26
time step continuity errors : sum local = 6.45786e-11, global = -4.08718e-13, cumulative = -4.08718e-13
GAMG:  Solving for p_rgh, Initial residual = 0.0320338, Final residual = 9.64194e-07, No Iterations 28
time step continuity errors : sum local = 1.80256e-12, global = 1.25071e-14, cumulative = -3.96211e-13
DILUPBiCG:  Solving for omega, Initial residual = 3.4176e-06, Final residual = 5.61993e-13, No Iterations 1
DILUPBiCG:  Solving for k, Initial residual = 0.000180099, Final residual = 1.12906e-12, No Iterations 1
bounding k, min: 9.99991e-16 max: 0.0003 average: 6.10765e-09
ExecutionTime = 70.08 s  ClockTime = 71 s

Nicolas

[Anne Lincke]

Without having a look at your controlDict or the files where you were changing the settings I cannot judge anything.
Did you mind to remove the processor-directories when computing in parallel and decompose again, when you want to change the boundary conditions?

[nik]

Originally Posted by Anne Lincke

Without having a look at your controlDict or the files where you were changing the settings I cannot judge anything.
Did you mind to remove the processor-directories when computing in parallel and decompose again, when you want to change the boundary conditions?

Dear Anne,

yes I removed the processor-directories and decomposed again. I did it once more to be sure. I still have the same warning. I have attached my controlDict and my boundary conditions if that helps.

Regards,
Nicolas

[Anne Lincke]

Why don't you rename nu in the BC for the Cyl as well?

CAVITY_CYL
    {
        type            groovyBC;
        value           uniform $refTemp;
        valueExpression "573.15";    
        gradientExpression "gradT";    
        fractionExpression "0";  
        variables
        (
            "heatFlux=  18510;"
            "rho=1.9e+03;"
            "cp=1.54e+03;"
            "nu=1.72e-06;"
            "pr=9.75;"
            "kappa=nu/pr;"
            "gradT=heatFlux/((kappa+kappat)*rho*cp);"
        );
    }

[nik]

Originally Posted by Anne Lincke

Why don't you rename nu in the BC for the Cyl as well?

How silly of me. I have just forgot to do so. Now its OK, no warnings. Thanks a lot Anne.

Nicolas

[atoof]

{
type groovyBC;
value uniform 293.15;
variables "htot=340;Tinf=253.15;Cp=384;k=ktherm*0.01;gra dT=-htot*mag((T-Tinf))/k;";//k=alphaEff*rho*Cp;
gradientExpression "gradT";
fractionExpression "0";
timelines ( );
}

I try to implement the following boundary condition in the wall patch, but I encounter an error in the first time step which states Parser Error for driver PatchValueExpressionDriver at "1.1-6" :"field gradhT not existing or of wrong type". I'm using swak4Foam-2.x-release-0.2.1 and OP2.1.

    walls
    {
        type groovyBC;
        value uniform -254449;
        variables "gardhT=cp*snGrad(T);";
        gradientExpression "gradhT";
        fractionExpression "0";
        timelines ( ); 
    }

Output in terminal:

.
.
.
rho max/min : 1.10805 0.26055
DILUPBiCG:  Solving for PV, Initial residual = 1, Final residual = 3.62937e-07, No Iterations 2
swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning : 
    From function ConcretePluginFunction<DriverType>::exists
    in file lnInclude/ConcretePluginFunction.C at line 111
    Constructor table of plugin functions for PatchValueExpressionDriver is not initialized


--> FOAM FATAL ERROR: 
 Parser Error for driver PatchValueExpressionDriver at "1.1-6" :"field gradhT not existing or of wrong type"
"gradhT"
  ^^^^^^
--|     

Context of the error:


- From dictionary: 
.../0/hT::boundaryField::walls
  Evaluating expression "gradhT"


    From function parsingValue
    in file lnInclude/CommonValueExpressionDriverI.H at line 1039.

FOAM exiting

How can I solve above problem?

[atoof]

Originally Posted by atoof

How can I solve above problem?

Solved.

I substituted "gardhT" to "gradhT".

[akidess]

I ran into a similar problem with weird build errors while compiling swak with foam-extend-3.0 (AllMake.stage5) when WM_NCOMPROCS was set to 16. After setting it to one it worked as expected.

Originally Posted by gschaider

First the good news: the majority of swak4Foam has compiled OK. Seems like the problem is "only" with the FAM-stuff. Bad news: I'm a bit amazed. But I've got an idea: is it possible that $WM_NCOMPROCS is set (possibly to a large value). This can be a problem because the compilation of the yy-files produces headers that later files (grovvy-something) need. Try unsetting the variable and recompile (it also might be possible that it you don't have to unset the variable. Just recompile)

[wyldckat]

Hi Anton,

Originally Posted by akidess

I ran into a similar problem with weird build errors while compiling swak with foam-extend-3.0 (AllMake.stage5) when WM_NCOMPROCS was set to 16. After setting it to one it worked as expected.

From what I saw the other day, the AllMake.stage5 script will only work properly with the Mercurial repository. And that version of code should already have some restrainers to the "WM_NCOMPPROCS" flag put in, where some were limiting to 3 and others to 1.

The other similar strangeness I can remember is that the official OpenFOAM version use to constrain the counter to 8 in the "ThirdParty-*" building scripts... so my guess is that some other 3rd party source code is also constrained to a maximum number of parallel GCC compilers working at the same time... or simply to avoid overconsumption of RAM

But the big question is: were you using the normal GCC compilers or did you use LLVM+clang or even ICC?

Best regards,
Bruno

[akidess]

I was under the impression the AllMage.stage5 script did use the Mercurial repository, but I'm not sure about it. I was using my system gcc-4.7.1 compiler.

Originally Posted by wyldckat

Hi Anton,


From what I saw the other day, the AllMake.stage5 script will only work properly with the Mercurial repository. And that version of code should already have some restrainers to the "WM_NCOMPPROCS" flag put in, where some were limiting to 3 and others to 1.

The other similar strangeness I can remember is that the official OpenFOAM version use to constrain the counter to 8 in the "ThirdParty-*" building scripts... so my guess is that some other 3rd party source code is also constrained to a maximum number of parallel GCC compilers working at the same time... or simply to avoid overconsumption of RAM

But the big question is: were you using the normal GCC compilers or did you use LLVM+clang or even ICC?

Best regards,
Bruno

[wyldckat]

Hi Anton,

Originally Posted by akidess

I was under the impression the AllMage.stage5 script did use the Mercurial repository, but I'm not sure about it. I was using my system gcc-4.7.1 compiler.

This is very very strange... if the build error was in the same exact place as on the other post you referenced, then if you look at the file "Libraries/Allwmake" and check if this code is found there:

    if [[ $WM_NCOMPPROCS>2 ]]; then
        echo "WM_NCOMPPROCS $WM_NCOMPPROCS will cause race conditions with the grammars. Resetting to 2 for this library"
        (export WM_NCOMPPROCS=2;     wmake libso swakFiniteArea)
    else
         wmake libso swakFiniteArea
    fi

If it is and if it was that library that had the issue, then perhaps the machine you're using is really that good, because it's so fast that it can even get a race condition with just 2 cores
If this is the case, then it might be worth reporting to Bernhard!

Best regards,
Bruno