[Anne Lincke]

Hey Matthew,

I tested your example and when using the same expression like you did, nothing happened.

It worked when changing the order of functions and libs, try it this way

functions
(
    monitorAirOutlet
    {
        type patchExpression;
        accumulations (sum);
        patches (airout);
        expression "area()";
        verbose true;
    }
);
libs (
    "libOpenFOAM.so"
    "libsimpleSwakFunctionObjects.so"
    "libswakFunctionObjects.so"
)
;

Kind Regards
Anne

[mkubemcd]

Originally Posted by Anne Lincke

Hey Matthew,

I tested your example and when using the same expression like you did, nothing happened.

It worked when changing the order of functions and libs, try it this way

Oh dang, it was something stupidly simple. I forgot the ";" after the libs list. Thanks, that's what I needed to fix it.

[Anne Lincke]

Oh, alright, I did not check this, but your are right.
The missing ';' was the reason!

[HighOrderCFD]

Greetings to all FOAMers and SWAKers

I am working with chtMultiRegionFoam and I have included in my simulation a fluid with the following thermoType:
hRhoThermo<pureMixture<sutherlandTransport<specieT hermo<janafThermo<perfectGas>>>>>

My question is if it is possible to obtain the thermal conductivity K as a separate file using swak4foam (or any other tool).

Thank you in advance for any comments.

[romain.h]

Hello all,
I just installed swak4foam and I tried one of the tutorials : multiRegionHeaterFeedback since it seems interesting and close of what I am looking for.

I use the file Allrun, but I have an error :

Selecting thermodynamics package hRhoThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > >::calculate() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#4  Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > >::hRhoThermo(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#5  Foam::basicRhoThermo::addfvMeshConstructorToTable<Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > > >::New(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#6  Foam::basicRhoThermo::New(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#7  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/chtMultiRegionFoam"
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9

Upon on closer look, it seems that my groovyBC boundary condition is set at 0 K and it is this 0 value which give an error.
If I use a fixedValue boundary condition and not the groovyBC boundary condition the tutorial is running.

The groovyBC is the following :

minY
    {
        type            groovyBC;
        value           uniform 300;
       valueExpression "Tin-(Tout-300)";
       variables       "Tout{maxX/topAir}=average(T);Tin{minY/heater}=average(T);";
    }

According to http://openfoamwiki.net/index.php/Contrib_groovyBC, the value for the first iteration should be set to value uniform 300; but it is set to 0...

Even if the valueExpression is used, the patch minY should be set at T_heater-(T_topAir-300) thus 500 K - (300-300) = 500 K.

I tried different groovyBC expression for the temperature, but my temperature on this patch is always set to 0, which cause the simulation to fail.

If someone could show what is wrong with this boundary condition, or with the example case (multiRegionHeaterFeedback, which is included is the installation package of swak4foam) it will be really useful.


Thanks,
Romain

edit : I found my problem ! while I was looking at the wiki (http://openfoamwiki.net/index.php/Contrib/swak4Foam) I observed that OF211 seems to not be yet supported. And effectively, it is working with OF210. It seems that swak is not yet working correctly with OF211.
At least one hour wasted on that ! Hopefully it will help someone to not repeat my mistake.

[wyldckat]

Greetings to all!

@HighOrderCFD:

Originally Posted by HighOrderCFD

My question is if it is possible to obtain the thermal conductivity K as a separate file using swak4foam (or any other tool).

Here you go: http://openfoamwiki.net/index.php/Ti...gisteredObject

Best regards,
Bruno

[aerogt3]

I am using swak4foam to monitor mass flow rate on faceZones. Does anyone know if it's possible to do pressure averaging on a faceZone using swak4foam?

[nakor]

Originally Posted by aerogt3

I am using swak4foam to monitor mass flow rate on faceZones. Does anyone know if it's possible to do pressure averaging on a faceZone using swak4foam?

can you be a bit more specific on what you want to do ?
It seem that you are looking to do something similar to what is explaining here, part 3.6

----------------------




On another point, I am looking to implement a boundary condition in chtMultiRegionFoam for conduction between two solids, but with a contact resistance.
I was thinking to use something along the lines of

Patch2
{
type groovyBC;
value uniform Tinit;
valueExpression "Tpatch1+DT*q";
variables "Tpatch1{patch1/solid1}=average(T);DT=cst;q=?";
}

with q determined using a swak function, or by modifying the chtMultiRegionSolver in order to have a field Q (I have already done it)
qHot
{
type swakExpression;
valueType patch;
patchName hot;
verbose true;
expression "-K*area()*snGrad(T)";
accumulations (sum);
region Solid_2;
}

Do you think that something like that could work ?

Thanks

[aerogt3]

Originally Posted by nakor

can you be a bit more specific on what you want to do ?
It seem that you are looking to do something similar to what is explaining here, part 3.6

What is in section 3.6 is pressure monitoring on a patch. I want/need to do it on a faceZone! Unfortunately I can't answer your question

[gschaider]

Originally Posted by HighOrderCFD

Greetings to all FOAMers and SWAKers

I am working with chtMultiRegionFoam and I have included in my simulation a fluid with the following thermoType:
hRhoThermo<pureMixture<sutherlandTransport<specieT hermo<janafThermo<perfectGas>>>>>

My question is if it is possible to obtain the thermal conductivity K as a separate file using swak4foam (or any other tool).

Thank you in advance for any comments.

I K is kept in memory as a field by the model then swak can access it.

To access properties of the thermal model that are not accessible by fields you can load a function plugin by adding "libswakThermoTurbFunctionPlugin.so" to your libs. Then the field parser has additional functions like thermo_alpha() (which gives you the thermalDiffusivity)

FunctionPlugins only work with the latest release of swak4Foam

[gschaider]

Originally Posted by romain.h

Hello all,
I just installed swak4foam and I tried one of the tutorials : multiRegionHeaterFeedback since it seems interesting and close of what I am looking for.

I use the file Allrun, but I have an error :

Selecting thermodynamics package hRhoThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > >::calculate() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#4  Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > >::hRhoThermo(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#5  Foam::basicRhoThermo::addfvMeshConstructorToTable<Foam::hRhoThermo<Foam::pureMixture<Foam::constTransport<Foam::specieThermo<Foam::hConstThermo<Foam::perfectGas> > > > > >::New(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#6  Foam::basicRhoThermo::New(Foam::fvMesh const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#7  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/chtMultiRegionFoam"
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9

Upon on closer look, it seems that my groovyBC boundary condition is set at 0 K and it is this 0 value which give an error.
If I use a fixedValue boundary condition and not the groovyBC boundary condition the tutorial is running.

The groovyBC is the following :

minY
    {
        type            groovyBC;
        value           uniform 300;
       valueExpression "Tin-(Tout-300)";
       variables       "Tout{maxX/topAir}=average(T);Tin{minY/heater}=average(T);";
    }

According to http://openfoamwiki.net/index.php/Contrib_groovyBC, the value for the first iteration should be set to value uniform 300; but it is set to 0...

Even if the valueExpression is used, the patch minY should be set at T_heater-(T_topAir-300) thus 500 K - (300-300) = 500 K.

I tried different groovyBC expression for the temperature, but my temperature on this patch is always set to 0, which cause the simulation to fail.

If someone could show what is wrong with this boundary condition, or with the example case (multiRegionHeaterFeedback, which is included is the installation package of swak4foam) it will be really useful.


Thanks,
Romain

edit : I found my problem ! while I was looking at the wiki (http://openfoamwiki.net/index.php/Contrib/swak4Foam) I observed that OF211 seems to not be yet supported. And effectively, it is working with OF210. It seems that swak is not yet working correctly with OF211.
At least one hour wasted on that ! Hopefully it will help someone to not repeat my mistake.

Same version of swak? Strange. It is possible that there is a problem with a changed order of evaluations. Could you write a bug-report and I'll see when I can get to it

[nakor]

Originally Posted by gschaider

Same version of swak? Strange. It is possible that there is a problem with a changed order of evaluations. Could you write a bug-report and I'll see when I can get to it

The issue has (recently) been reported, 0000159: OpenFoam 2.1.1 + swak4foam 0.2.0: groovyBC fail to apply the initial condition
http://sourceforge.net/apps/mantisbt...nbn=1#bugnotes :

My solution was to switch to OF210, which resolve the groovyBC problem, but OF210 is not working properly with one of my other boundary condition (externallWallHeatFluxTemperature).

I could stick with OF210 and groovyBC if I could replace externallWallHFTemperature with a similar groovy boundary condition.

Do you think that the following one could do the trick ?

walls
{
type groovyBC;
value uniform 300;
gradientExpression "gradT";
fractionExpression "0";
variables "Text=300;hc=10000;gradT=(Text-T)*hc;";
timelines ();
}

(source)

edit: after test, it seem that I have to use hc=hext/lambda; I do not see why... But at least it is working.

[gschaider]

Originally Posted by aerogt3

I am using swak4foam to monitor mass flow rate on faceZones. Does anyone know if it's possible to do pressure averaging on a faceZone using swak4foam?

Yep. The only thing is that in the function object where you do that you've got to set

autoInterpolate true;

this tells the parser to automatically interpolate volume fields to the faces

[mkubemcd]

Hi again, now that I've got swak working I'm looking for a more elegant solution to my actual problem.

I'm running my case in interFoam, and what I'm trying to measure is the mass or volume flow of one phase out an outlet. What I've got right now is

type patchExpression
accumulations (sum);
patches (airout);
expression "U.y*alpha1*area()";
verbose true;

with the restriction that the outlet plane has to be normal to the y-axis. It works okay, but it's not extendable and not entirely accurate.

What I want is an expression more like

(velocity).dotproduct.(facenormal) * alpha1

but I'm not familiar with swak or sfo enough to know if that exists, and the documentation on the wiki is really confusing. Any advice would be greatly appreciated.

[gschaider]

Originally Posted by mkubemcd

Hi again, now that I've got swak working I'm looking for a more elegant solution to my actual problem.

I'm running my case in interFoam, and what I'm trying to measure is the mass or volume flow of one phase out an outlet. What I've got right now is

with the restriction that the outlet plane has to be normal to the y-axis. It works okay, but it's not extendable and not entirely accurate.

What I want is an expression more like

but I'm not familiar with swak or sfo enough to know if that exists, and the documentation on the wiki is really confusing. Any advice would be greatly appreciated.

It is here: http://openfoamwiki.net/index.php/Co...ression_syntax

Inner product is & and normal() gets you the face vectors

[sahmadian]

Dear Bernard, I am newly working with OpenFOAM. I am trying to use the groovyBC library for a convective heat transfer boundary condition. I have used two kinds of expression:
1-
{ type groovyBC;
variables "ktherm=0.5;ktot=ktherm;htot=3400;Tinf=253.15; "; valueExpression "Tinf";
gradientExpression "0";
fractionExpression "(1/(1+ktot/htot*(mag(delta()))))";
value uniform 293.15;
}

For this kind of expression unfortunately when I change variables like htot no change in the solution is observed. So alternatively I used the following expression:

2-
{
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 ( );
}

For this kind of expression, the results seem reasonable but when I increase the value of htot for a limit, a floating point expression is occurred and the solution is not converged. Can you please kindly help me in this regards? I prefer to use the second solution but dont know how to avoid the Floating point exception. I would really appreciate your help!
Regards

[gschaider]

Originally Posted by sahmadian

Dear Bernard, I am newly working with OpenFOAM. I am trying to use the groovyBC library for a convective heat transfer boundary condition. I have used two kinds of expression:
1-
{ type groovyBC;
variables "ktherm=0.5;ktot=ktherm;htot=3400;Tinf=253.15; "; valueExpression "Tinf";
gradientExpression "0";
fractionExpression "(1/(1+ktot/htot*(mag(delta()))))";
value uniform 293.15;
}

For this kind of expression unfortunately when I change variables like htot no change in the solution is observed. So alternatively I used the following expression:

2-
{
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 ( );
}

For this kind of expression, the results seem reasonable but when I increase the value of htot for a limit, a floating point expression is occurred and the solution is not converged. Can you please kindly help me in this regards? I prefer to use the second solution but dont know how to avoid the Floating point exception. I would really appreciate your help!
Regards

My guess with the second formulation is that the timestep is too large: the rather steep gradient produces a value that over/undershoots Tinf. Try a smaller timestep (not sure whether this is also the problem with the first formulation but it might be worth try)

Question: do you see groovyBC in the stacktrace? If not then I guess the problem is not groovyBC per se but the way you use it

[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

[sahmadian]

Originally Posted by gschaider

My guess with the second formulation is that the timestep is too large: the rather steep gradient produces a value that over/undershoots Tinf. Try a smaller timestep (not sure whether this is also the problem with the first formulation but it might be worth try)

Question: do you see groovyBC in the stacktrace? If not then I guess the problem is not groovyBC per se but the way you use it

Hi Bernard,
Thanks so much for your reply!
I tried to change the time step (high to very small) and even the mesh (finer) but again got Floating point expression.
I guess there is a problem with numerical calculation. The reason I am telling this is that for example with variables htot=340 and k=ktherm*0.1 the solution is correct but when I change htot to for example 500 (which is not a big change) or the k to ktherm*0.05 then the temperature of the wall and the cells accross the wall fall to very small values of orders -1e20 and finally floating point expression is occurred. It seems that the solution is fine until a certain value of gradT or heat flux but heat fluxes higher than that value will cause a heat sink at the boundary.
One of the problems that may affect the solution can be the expression of mag(T-Tinf) which for T values lower that Tinf gradient is still imposed which should not. In OF codes I usually use for example max(0, (T-Tinf)) instead of mag(T-Tinf) but in groovyBC I tried this with no success. Do you know how to do this in groovyBC?
Any idea on improving the BC?
Thanks again for your consideration.

[gschaider]

Originally Posted by sahmadian

Hi Bernard,
Thanks so much for your reply!
I tried to change the time step (high to very small) and even the mesh (finer) but again got Floating point expression.
I guess there is a problem with numerical calculation. The reason I am telling this is that for example with variables htot=340 and k=ktherm*0.1 the solution is correct but when I change htot to for example 500 (which is not a big change) or the k to ktherm*0.05 then the temperature of the wall and the cells accross the wall fall to very small values of orders -1e20 and finally floating point expression is occurred. It seems that the solution is fine until a certain value of gradT or heat flux but heat fluxes higher than that value will cause a heat sink at the boundary.
One of the problems that may affect the solution can be the expression of mag(T-Tinf) which for T values lower that Tinf gradient is still imposed which should not. In OF codes I usually use for example max(0, (T-Tinf)) instead of mag(T-Tinf) but in groovyBC I tried this with no success. Do you know how to do this in groovyBC?
Any idea on improving the BC?
Thanks again for your consideration.

I'm sorry. I only provide groovyBC. How you use it (and to make sure that your physical equations are right) I do not see as my responsibility.

Just some notes:
- making the mesh finer will NOT make the problem with the explicit gradient (the second formulation) go away but make it worse. ONLY change the timestep
- the first formulation should be in my opinion more stable
- the max-expression SHOULD work