CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Post-Processing

integrate several fields

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   April 6, 2011, 11:27
Default integrate several fields
  #1
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
Hi foamers,

I'm doing a RTD (Residence Time Distribution) of a 3D cylinder. I solved the velocity part by using simpleFoam in a steady state.
Then, with this converged velocity I created a similar case (with scalarTransportFoam, transient), including a
step experiment at the beginning.
By measuring the Heat flux at the "outlet" patch, I would manage to study this RTD. (Hope you got everything)

My case briefly pre
sented, here's my question:

in the controlDict file, I want to use a function to calculate the integral for the product (Ux*T) during the whole calculation (t= 0 -> 3 with dt=2.5e-3)

I was trying to use "libsimpleFunctionObjects.so" with the type "patchIntegrate" as follows
Code:
flux
    {
      functionObjectLibs ( "libsimpleFunctionObjects.so" );
      type    patchIntegrate;
      fields (T);
      patches ( "outlet" );
      factor Ux;
    }
but:
There is no way to do what I exposed above.

Note: U isn't in the integral as it's constant for the whole calculation (already established).
Apparently you need a scalar and not Ux...
Code:
--> FOAM FATAL IO ERROR: 
wrong token type - expected Scalar found on line 63 the word 'Ux'
1) Anyone has an idea how to do it?
2) Does it exist another utility to multiply 2 scalarfields? Then I'll be able to use the result of this one in my integral.

Thank you
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 7, 2011, 03:15
Default My bad
  #2
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
I don't know what I was thinking about...

The integral is spatial and not temporal. Therefore, Ux isn't constant (as there is a laminar profile in the tube)!

I must multiply, then both Ux and T before integrating more or less as follows:
Code:
flux
    {
      functionObjectLibs ( "libsimpleFunctionObjects.so" );
      type    patchIntegrate;
      fields (Ux*T);
      patches ( "outlet" );
    }
(Ux*T) doesn't work but that's the idea of what I wanna solve
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 7, 2011, 07:27
Default
  #3
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sixwp View Post
I don't know what I was thinking about...

The integral is spatial and not temporal. Therefore, Ux isn't constant (as there is a laminar profile in the tube)!

I must multiply, then both Ux and T before integrating more or less as follows:
Code:
flux
    {
      functionObjectLibs ( "libsimpleFunctionObjects.so" );
      type    patchIntegrate;
      fields (Ux*T);
      patches ( "outlet" );
    }
(Ux*T) doesn't work but that's the idea of what I wanna solve
@your recent posting: the factor always has to be a number that's why Ux didn't work. If you know the velocity you'd have to hardcode it here.

As what you're trying to compute isn't THAT uncommon SFO has a functionObject patchFieldFlow to do it (for compressible flow there is also a rho there, but that's alright I guess)

simpleFunctionObjects can't do arbitray calculations (Ux*T or so) on patches BUT swak4Foam can. The functionObjects there that can do that are patchExpression or swakExpression and they are based on SFO

Bernhard
gschaider is offline   Reply With Quote

Old   April 7, 2011, 08:53
Default
  #4
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
Quote:
Originally Posted by gschaider View Post
@your recent posting: the factor always has to be a number that's why Ux didn't work. If you know the velocity you'd have to hardcode it here.

As what you're trying to compute isn't THAT uncommon SFO has a functionObject patchFieldFlow to do it (for compressible flow there is also a rho there, but that's alright I guess)

simpleFunctionObjects can't do arbitray calculations (Ux*T or so) on patches BUT swak4Foam can. The functionObjects there that can do that are patchExpression or swakExpression and they are based on SFO

Bernhard
Hi Bernhard,

First of all: thanks for your answer !

I was doing some tries with swak4foam before I saw your reply.
First of them, I tried to change (naively...) the "functionObjectsLibs" into that:
Code:
flux
    {
      functionObjectLibs ( "libsimpleSwakFunctionObjects.so" );
      type    patchIntegrate;
      fields     (Ux*T);
      patches     ( "outlet" );
but without success...

I was then looking at the wiki page (nice job for this contrib, btw) checking for examples. I couldn't find one that can help me.

Do you have any hints considering that?
Meanwhile, I'll continue to dig all of this.

Best Regards,
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 7, 2011, 10:27
Default
  #5
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sixwp View Post
Hi Bernhard,

First of all: thanks for your answer !

I was doing some tries with swak4foam before I saw your reply.
First of them, I tried to change (naively...) the "functionObjectsLibs" into that:
Code:
flux
    {
      functionObjectLibs ( "libsimpleSwakFunctionObjects.so" );
      type    patchIntegrate;
      fields     (Ux*T);
      patches     ( "outlet" );
but without success...

I was then looking at the wiki page (nice job for this contrib, btw) checking for examples. I couldn't find one that can help me.

Do you have any hints considering that?
Meanwhile, I'll continue to dig all of this.

Best Regards,
Have a look at the Examples that come with swak. Especially other/angledDuctImplicit is bloated with functionObjects.

I hope to find the time to update the swak-Wiki-page when I find time (which should be hopefully before my retirement). Until then I welcome any contributions on it

Bernhard
gschaider is offline   Reply With Quote

Old   April 7, 2011, 10:34
Default
  #6
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
Thank you so much. I was just about to leave a message saying I did use this example. I'm waiting for the calculation results.

I'll post what I did if effective (hopefully!)
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 7, 2011, 10:39
Default
  #7
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sixwp View Post
Thank you so much. I was just about to leave a message saying I did use this example. I'm waiting for the calculation results.

I'll post what I did if effective (hopefully!)
Or (even better) you can add it as an example to the Wiki-page
gschaider is offline   Reply With Quote

Old   April 7, 2011, 11:13
Default
  #8
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
If you don't mind, I'd rather post it here (or send you by email) first because if it works, it's a highly not straight forward way to do it I fear... :-p
Let's wait and see
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 8, 2011, 08:43
Default
  #9
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
I finally manage to realize my RTD!

The problem I had about integrating Ux and T together is solved. Here's what I used (it's definitely not the best way to do so, but that's a start):

First thing, in my case I admitted that Ux=magU (as the flow is almost perfectly unidirectional).

In controlDict, I input:
Code:
functions
{
      dflux
    {
      type    expressionField;
      outputControl timeStep;
      outputInterval 1;
      fieldName    dflux;
      expression    "(T*mag(U))";
      patches     ( "outlet" );
      autowrite true;
    }
    flux
    {
      functionObjectLibs ( "libsimpleFunctionObjects.so" );
      type    patchIntegrate;
      fields     (dflux);
      patches     ( "outlet" );
    }
}

libs ( 
    "libOpenFOAM.so" 
    "libgroovyBC.so" 
    "libsimpleSwakFunctionObjects.so" 
    "libswakFunctionObjects.so" 
    "libswakTopoSources.so" 
) ;
Remarque: 1) The huge amount of libraries at the end isn't required (only some would be necessary). I just have them from a previous case and didn't optimize it.
2) I'm not sure if the dflux "patches" is correct or if the calculation is made everywhere...

As I said, it's highly inefficient compare to what's possible to do, but that's a start.
I wait for your comments before putting my example in the swak4foam wiki (if it's not too crappy)

Have a nice weekend
__________________
Sam
sixwp is offline   Reply With Quote

Old   April 9, 2011, 08:40
Default
  #10
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sixwp View Post
I finally manage to realize my RTD!

The problem I had about integrating Ux and T together is solved. Here's what I used (it's definitely not the best way to do so, but that's a start):

First thing, in my case I admitted that Ux=magU (as the flow is almost perfectly unidirectional).

In controlDict, I input:
Code:
functions
{
      dflux
    {
      type    expressionField;
      outputControl timeStep;
      outputInterval 1;
      fieldName    dflux;
      expression    "(T*mag(U))";
      patches     ( "outlet" );
      autowrite true;
    }
    flux
    {
      functionObjectLibs ( "libsimpleFunctionObjects.so" );
      type    patchIntegrate;
      fields     (dflux);
      patches     ( "outlet" );
    }
}

libs ( 
    "libOpenFOAM.so" 
    "libgroovyBC.so" 
    "libsimpleSwakFunctionObjects.so" 
    "libswakFunctionObjects.so" 
    "libswakTopoSources.so" 
) ;
Remarque: 1) The huge amount of libraries at the end isn't required (only some would be necessary). I just have them from a previous case and didn't optimize it.
2) I'm not sure if the dflux "patches" is correct or if the calculation is made everywhere...

As I said, it's highly inefficient compare to what's possible to do, but that's a start.
I wait for your comments before putting my example in the swak4foam wiki (if it's not too crappy)

Have a nice weekend
Hi.

You don't have to go through the expressionField. libsimpleSwakFunctionObjects.so already has what you need:
Code:
 temperatureSum
    {
        type patchExpression;
        accumulations (
            sum
        );
        patches (
            outlet 
        );
        expression "mag(U)*T*area()";
        verbose true;
    }
If you want the actual amount of T (which still is not the energy) flowing out this is better
Code:
 temperatureSum
    {
        type patchExpression;
        accumulations (
            sum
        );
        patches (
            outlet 
        );
        expression "phi*T";
        verbose true;
    }
But if you had wanted that you would have used the patchFieldFlow from the simpleFunctionObjects

Bernhard
calim_cfd likes this.
gschaider is offline   Reply With Quote

Old   April 11, 2011, 03:56
Default
  #11
Member
 
Samuel ARNAUD
Join Date: Feb 2011
Location: Grenoble, FRANCE
Posts: 39
Rep Power: 6
sixwp is on a distinguished road
thanks for your answer.

I didn't want to use the patchExpression with "sum" because I thought it was only for an addition. I didn't push it further...

Quote:
If you want the actual amount of T (which still is not the energy) flowing out this is better
Code:
temperatureSum
{
type patchExpression;
accumulations (
sum
);
patches (
outlet
);
expression "phi*T";
verbose true;
}
But if you had wanted that you would have used the patchFieldFlow from the simpleFunctionObjects
Exactly

[EDIT]: I tried to use your expression (to compare results) but I'm having some trouble with. It can't find the "linsimpleSwakFunctionObjects.so" apparently. Don't know what's wrong, I did "wclean" and "wmake" again, but it seems there's a problem with it. With OF1.7, I guess that's normal (as you put in your README) but with OF1.6dev, it should work...
__________________
Sam

Last edited by sixwp; April 11, 2011 at 04:02. Reason: test done
sixwp is offline   Reply With Quote

Old   December 1, 2011, 10:27
Default
  #12
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
Hi,

To get to grips with the simpleFunctionObjects and swak4Foam I created a modified PD case to pisoFoam and injected scalarTransport into it - scalar T. I want to track the very uninteresting change of T in the domain and on the boundary. In the blockMeshDict I named all my blocks "domain".

I failed to create an expression for the difference of patchFieldFlow @ the inlet and outlet - main aim is to replicate the sumT expression with only boundary information only. Later I realized that I cannot reproduce the patchFieldFlow simpleFuncuntionObject with swak ...

At first I tried to somehow name (save) the two patchFieldFlow and make a subtraction. Is it possible to name / save it or to combine this with swak4Foam? My pure swak was crap as well ...

For the new sumT expression the timeStep information is necessary, how can one obtain the timeStep within swak?

There's some very similar stuff in the Examples / groovyBC / pulsedPitzDaily but I couldn't put it into practise.
Code:
functions 
{
    massFlowAverageT
    {
    type patchMassFlowAverage;
    functionObjectLibs ( "libsimpleFunctionObjects.so" );
    fields ( T );
    patches
    (
        inlet
        outlet
    );
    factor 1.0;
    verbose true;
    }

    patchFieldFlowT
    {
    type patchFieldFlow;
    functionObjectLibs ( "libsimpleFunctionObjects.so" );
    fields ( T );
    patches
    (
        inlet
        outlet
    );
    verbose true ;
    }

    patchFieldFlowT_S4F
    {
    type patchExpression;
    expression "mag(Sf())*phi*T" ;
    patches
    (
        inlet
        outlet
    );
    accumulations ( sum );
    verbose true ;
    }

    patchFieldFlowNettoT_S4F
    {
        type swakExpression;
    valueType internalField;
    variables
    (
        "inFlowT{inlet}=mag(Sf())*phi*T;"
        "outFlowT{outlet}=mag(Sf())*phi*T;"
    );
        expression "outFlowT-inFlowT";
        accumulations ( sum );
        verbose true;
    }

    // total T in simulation domain
    sumT
    {
    type swakExpression;
    valueType cellSet;
    setName domain;
    expression "( T * vol() ) / sum( vol() )";
    accumulations ( sum );
    verbose true ;
    }
}
Thank you!
Toorop is offline   Reply With Quote

Old   December 2, 2011, 07:17
Default
  #13
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Toorop View Post
Hi,

To get to grips with the simpleFunctionObjects and swak4Foam I created a modified PD case to pisoFoam and injected scalarTransport into it - scalar T. I want to track the very uninteresting change of T in the domain and on the boundary. In the blockMeshDict I named all my blocks "domain".

I failed to create an expression for the difference of patchFieldFlow @ the inlet and outlet - main aim is to replicate the sumT expression with only boundary information only. Later I realized that I cannot reproduce the patchFieldFlow simpleFuncuntionObject with swak ...

At first I tried to somehow name (save) the two patchFieldFlow and make a subtraction. Is it possible to name / save it or to combine this with swak4Foam? My pure swak was crap as well ...

For the new sumT expression the timeStep information is necessary, how can one obtain the timeStep within swak?

There's some very similar stuff in the Examples / groovyBC / pulsedPitzDaily but I couldn't put it into practise.
Code:
functions 
{
    massFlowAverageT
    {
    type patchMassFlowAverage;
    functionObjectLibs ( "libsimpleFunctionObjects.so" );
    fields ( T );
    patches
    (
        inlet
        outlet
    );
    factor 1.0;
    verbose true;
    }

    patchFieldFlowT
    {
    type patchFieldFlow;
    functionObjectLibs ( "libsimpleFunctionObjects.so" );
    fields ( T );
    patches
    (
        inlet
        outlet
    );
    verbose true ;
    }

    patchFieldFlowT_S4F
    {
    type patchExpression;
    expression "mag(Sf())*phi*T" ;
    patches
    (
        inlet
        outlet
    );
    accumulations ( sum );
    verbose true ;
    }

    patchFieldFlowNettoT_S4F
    {
        type swakExpression;
    valueType internalField;
    variables
    (
        "inFlowT{inlet}=mag(Sf())*phi*T;"
        "outFlowT{outlet}=mag(Sf())*phi*T;"
    );
        expression "outFlowT-inFlowT";
        accumulations ( sum );
        verbose true;
    }

    // total T in simulation domain
    sumT
    {
    type swakExpression;
    valueType cellSet;
    setName domain;
    expression "( T * vol() ) / sum( vol() )";
    accumulations ( sum );
    verbose true ;
    }
}
Thank you!
Sorry for not answering to your post in more detail, but at a first glance I'd say that there is a slight misunderstanding on the definition of phi:
http://openfoamwiki.net/index.php/Ma...ver_is_writing
That means multiplying the surface is not necessary (actually it is wrong).

Also remote variables only work correctly if they are uniform. So for your difference you'll have to do the sums on the patches (inFlowT{inlet}=sum(phi*T)) and on the internalField accumulate the difference with min, max or average (they all should give the same result).

Whether checking for the "conservation of temperature" makes physical sense of course depends on your solver
gschaider is offline   Reply With Quote

Old   December 5, 2011, 12:09
Default
  #14
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
Thank for the assistance!

With your advices I managed to pull it through, big thank you!

The only thing that still puzzles me is the slight difference in the the values - volume integration of the scalar and the calculated value based on the boundary flows. The latter gets accumulated in a variable, so there will be some error as the simulation progresses. But what causes the relatively big difference at the start, and the error wouldn't grow afterward, albeit it is not constant - quite strange! Attached the plots.

I attach the case since I usually find them quite useful if there's an attached project on the threads. So, the attachment contains a very simple extended pisoFoam solver with a scalar transport equation in it. The case is the pitzDaily with a scalar injected on the inlet. I used groovyBC to partition just the middle section of the inlet. I use simpleFunctionObjects and swakExpressions to track the evolution of the T scalar in the domain. I tried to replicate some functionalities with swak just to get some things sorted and learn a bit. At the end of the simulation pyFoam generates the plots.
Attached Files
File Type: gz pisoScalarFoam.tar.gz (2.3 KB, 18 views)
File Type: gz pitzDailyPisoScalar.tar.gz (4.4 KB, 19 views)
File Type: pdf volInt_vs_phi - all.pdf (13.6 KB, 45 views)
File Type: pdf volInt_vs_phi - start.pdf (9.4 KB, 32 views)
Toorop is offline   Reply With Quote

Old   December 5, 2011, 20:14
Default
  #15
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Toorop View Post
Thank for the assistance!

With your advices I managed to pull it through, big thank you!

The only thing that still puzzles me is the slight difference in the the values - volume integration of the scalar and the calculated value based on the boundary flows. The latter gets accumulated in a variable, so there will be some error as the simulation progresses. But what causes the relatively big difference at the start, and the error wouldn't grow afterward, albeit it is not constant - quite strange! Attached the plots.

I attach the case since I usually find them quite useful if there's an attached project on the threads. So, the attachment contains a very simple extended pisoFoam solver with a scalar transport equation in it. The case is the pitzDaily with a scalar injected on the inlet. I used groovyBC to partition just the middle section of the inlet. I use simpleFunctionObjects and swakExpressions to track the evolution of the T scalar in the domain. I tried to replicate some functionalities with swak just to get some things sorted and learn a bit. At the end of the simulation pyFoam generates the plots.
Sorry. I currently don't have the time to have a look at the case.

Anyway: I don't think that the initial error is something to worry about. The relative error at the first time-step is (judging from your diagram) approx 10% and rapidly becoming smaller. Possible explanations are: the solution is not "totally correct" (try changing the tolerances of the linear solver and see if that error changes), error in the interpolation to the patches, time discretization: the summation at the patches is a pure explicit Euler while the other stuff depends on whatever scheme you chose for ddt
gschaider is offline   Reply With Quote

Old   January 7, 2014, 07:27
Default
  #16
Member
 
Join Date: Jun 2011
Posts: 65
Rep Power: 6
maalan is on a distinguished road
Quote:
You don't have to go through the expressionField. libsimpleSwakFunctionObjects.so already has what you need:
Hi Bernhard!!

I am wondering how swak4foam and the libsimpleSwakFunctionObjects.so library compute exactly the integrals, I mean accuracy and method.

Thanks!
Best!
maalan is offline   Reply With Quote

Old   January 7, 2014, 19:36
Default
  #17
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by maalan View Post
Hi Bernhard!!

I am wondering how swak4foam and the libsimpleSwakFunctionObjects.so library compute exactly the integrals, I mean accuracy and method.

Thanks!
Best!
What do you mean? Usually integrals are implemented in the user expressions: size of the discretization elements (=cell volume or face area) times the (cell or face value). Sum.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 30, 2014, 07:46
Default
  #18
Member
 
Join Date: Jun 2011
Posts: 65
Rep Power: 6
maalan is on a distinguished road
Quote:
What do you mean? Usually integrals are implemented in the user expressions: size of the discretization elements (=cell volume or face area) times the (cell or face value). Sum.
Hi again and thanks for your reply!

Now I'm trying to integrate an expression on a patch via swak4foam. To do it I'd need the value of a field on another patch... I wonder if you could tell me how to do it with swakExpression.

Also, I'd need the time derivative of the velocity as I set an uniform velocity ramp at the inlet but I got the next message when I use the "ddt" function:

Code:
--> FOAM FATAL ERROR: 
LHS and RHS of - have different dimensions
     dimensions : [0 1 -2 0 0 0 0] - [0 0 -1 0 0 0 0]
I have used both the OF BC's and groovyBC to implement the velocity ramp. Also, I have calculated the time derivative like that:

Code:
    dUdt
    {
        type expressionField;
        outputControl timeStep;
        fieldName ddtU;
//        expression "(U-oldTime(U))/deltaT()";
        expression "ddt(U)";
        verbose true;
        autowrite true;
But I don't get the expected results.

Thanks for your attention!!
Best!
maalan is offline   Reply With Quote

Old   January 30, 2014, 13:04
Default
  #19
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by maalan View Post
Hi again and thanks for your reply!

Now I'm trying to integrate an expression on a patch via swak4foam. To do it I'd need the value of a field on another patch... I wonder if you could tell me how to do it with swakExpression.

Also, I'd need the time derivative of the velocity as I set an uniform velocity ramp at the inlet but I got the next message when I use the "ddt" function:

Code:
--> FOAM FATAL ERROR: 
LHS and RHS of - have different dimensions
     dimensions : [0 1 -2 0 0 0 0] - [0 0 -1 0 0 0 0]
I have used both the OF BC's and groovyBC to implement the velocity ramp. Also, I have calculated the time derivative like that:

Code:
    dUdt
    {
        type expressionField;
        outputControl timeStep;
        fieldName ddtU;
//        expression "(U-oldTime(U))/deltaT()";
        expression "ddt(U)";
        verbose true;
        autowrite true;
But I don't get the expected results.

Thanks for your attention!!
Best!
A numer of questions:
- which OF-version
- which swak-version
- the fatal-error is without any context (so I could only guess what is going on). Try the following: "export FOAM_ABORT=1" and rerun. This should yield a stacktrace which would be helpful to see WHERE this is happening
- what is "expected results" and what are the results you get?
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 31, 2014, 06:49
Default
  #20
Member
 
Join Date: Jun 2011
Posts: 65
Rep Power: 6
maalan is on a distinguished road
Quote:
- what is "expected results" and what are the results you get?
At last I got it!! This is an example of the correct expression... I just wanted to call the value of the field on another patch...

Code:
    {
        type swakExpression;
        valueType patch;
        variables (
            "ddtUin{INLET}=(U-oldTime(U))/deltaT();"
            "ddtV{BODY}=(U-oldTime(U))/deltaT();"
        );
        patchName CYLINDER;
        accumulations (
            sum
        );
        expression "(ddtV-ddtUin)&normal()*area()";
        verbose true;
}
Now I have another problem... I know that to set a velocity ramp at the inlet one can do it by using both the uniformFixedValue function in OF and groovyBC. Well, I would like to set a ramp with the freestream BC and it's not possible to do it with 'uniformFixedValue', so is there any way to do it with groovyBC??

Thank you so much, Bernhard!!
Best!
maalan is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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 Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
The mysterious _0 fields stevenvanharen OpenFOAM Running, Solving & CFD 2 January 4, 2011 08:24
Missing fields in reconstructPar flowris OpenFOAM 1 July 9, 2010 02:48
domainIntegrate, dieselFoam and Lagrangian Fields mturcios777 OpenFOAM 0 May 14, 2010 15:16
PostChannel maka OpenFOAM Post-Processing 5 July 22, 2009 09:15
Integrate Variables using PAraFoam nandiganavishal OpenFOAM Post-Processing 2 April 17, 2009 12:38


All times are GMT -4. The time now is 10:29.