[Gerrit]

Hello everyone,

I hope I am in the correct forum with my problem. I am simulating the heat transfer from a hot wire anemometer in a hydrogen stream with buoyantSimpleFoam. I am using polynomial functions for the fluid properties. My cases run and give results that make sense so far.
Now as I was about to finish the project I wanted to check everything again and found a fundamental problem with my cases:

To gain the heat transfered from the wire to the fluid I used "wallHeatFlux" and it gave logical results so far. Now I made a short calculation, first law of thermodynamics, relating inlet and outlet enthalpies with the mass flow and got a heat flow which is approx 1.7 times smaller than with "wallHeatFlux".

I gained the temperature at the outlet with "patchAverage T outlet" and the heat capacities with my polynomial functions.

I checked everything five times and do not know where this crude difference might come from. The biggest problem is, that I do not know which result I should trust.

Furthermore it becomes more confusing, as I have other simulations where only the velocity and the fluid properties where changed. These do not have this problem - there I get nearly the same heat flows with the described ways.

I hope it is possible to understand my problem so far.

Does someone have an idea?

Thank you very much!

Best regards

[jherb]

How do you average the temperature at the outlet? Is it weighted by the mass flow? (Or is the temperature constant over the whole area of your outlet?)

[Gerrit]

Hi,

the temperature is not constant over the whole area. I use "patchAverage T outlet" exactly like I wrote it here in this post. So no weightening as far as I know.

How can I use such a weighted function?

Thank!

[jherb]

You can use the simpleFunctionObjects library from swak4foam:

http://openfoamwiki.net/index.php/Co...vailable_types

patchMassFlowAverage uses the mass flow of each boundary face to weight the average.

[Gerrit]

Thank you very much for your answer!
Edit: I installed swak4Foam, found the folder in the installation called "patchMassFlowAverageFunctionObject". Sadly the command is not listed in the known commands. Do I have to add swak4Foam to the .bashrc?

Thank you very much!

[jherb]

you have to add it to the controlDict, e.g.

functions
(
   postFields
   {
       type patchMassFlowAverage;
       functionObjectLibs
       (
         "libsimpleFunctionObjects.so"
       );
       verbose true;
       patches
       (
         inlet
         outlet
       );
       fields
       (
         T
       );
       outputControlMode timeStep;
       outputInterval 1;
   }
);

This will create a directory postProcessing/0 (if you start at t = 0 s) containing a file T with the averages.

You might also be able to produce this file after you have finished you simulations with the command execFlowFunctionObjects. I am not totally sure about the options to use, but I used this in the past:

execFlowFunctionObjects -dict system/functionObjectsDict -noFlow

(in this case the above code was in a separate file functionObjectsDict and not in controlDict)

see also: https://openfoamwiki.net/index.php/E...unctionObjects

[Gerrit]

Thank you so much! It worked!

Best regards
Gerrit

[jherb]

And did it fix the problem with the heat balance?

[Gerrit]

Sadly it did not. It minimized the problem a little bit, but the difference is still there.

[jherb]

How did you specify the temperature wall function at the hot wire?

https://github.com/OpenFOAM/OpenFOAM...hScalarField.H

And did the solver really converge?

[Gerrit]

Hi thanks for the answer again!

That might have been important to mention:
My flow is laminar - at the wire I have Re number smaller than 1 - so no turbulence model. Therefore I did not specify the temperature wall function - was that still necessary?

I would say that it is converged - see the attached picture

[jherb]

But what is the boundary condition on the wire?

And you could check if the velocities and the temperature values at the boundaries stay constant to check if the solution has really converged.

If you do not have a turbulence model turned on, the wallHeatFlux utility calculates the heat flux with this code:

        surfaceScalarField heatFlux
        (
            fvc::interpolate
            (
                (
                    turbulence.valid()
                  ? turbulence->alphaEff()()
                  : thermo->alpha()
                )
            )*fvc::snGrad(h)
        );

        const surfaceScalarField::GeometricBoundaryField& patchHeatFlux =
            heatFlux.boundaryField();

        Info<< "\nWall heat fluxes [W]" << endl;
        forAll(patchHeatFlux, patchi)
        {
            if (isA<wallFvPatch>(mesh.boundary()[patchi]))
            {
                Info<< mesh.boundary()[patchi].name()
                    << " "
                    << gSum
                       (
                           mesh.magSf().boundaryField()[patchi]
                          *patchHeatFlux[patchi]
                       )
                    << endl;
            }
        }

So is the value for alpha calculated correctly?

[Gerrit]

The values of velocity and temperature are converged. I plotted them at different points in the domain and they converged towards constant values.

My wire boundary is defined to be:
{
type fixedValue;
value uniform 515.15;
}

the surrounding is of course colder!

Referring to alpha: I do not know, how to gain this value. The only things OpenFOAM gives me are U,T,p and p_rgh. In the fluid properties only mu, rho, Cp and k are defined.

Thank you very much for answering so fast.

[jherb]

For alpha see e.g. http://www.tfd.chalmers.se/~hani/kur...3-or-2.4.x.pdf

Depending on what you have specified in constant/thermophysicalModels, alpha (laminar) is calculated somewhere in https://github.com/OpenFOAM/OpenFOAM...hysicalModels/

This is then used to calculate the heat flux in the wallHeatFlux utility.

Just a very wild guess: You are sure that you have always used K as temperature unit in your temperature dependent polynomials?

[Gerrit]

Hi again,

the thermal diffusivity is defined as conductivity divided by the product of density and cp, these are all defined in the thermophysical properties file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      thermophysicalProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

thermoType
{
    type            heRhoThermo ;         
    mixture         pureMixture;          
    transport       polynomial;            
    thermo          hPolynomial;        
    equationOfState icoPolynomial ;        
    specie          specie;                
    energy          sensibleEnthalpy;        
    dpdt              off;            
}

mixture
{
    specie
    {
        nMoles          1;            
        molWeight       2;            
    }
    equationOfState// coef a + bT+cT²+...
    {
        rhoCoeffs<8>    
        (0.2279 -0.0007589 1.082e-06 5.606e-10 0 0 0 0);// rho(T)
    }
    thermodynamics
    {
        Hf              0;
        Sf              0;
    CpCoeffs<8>     (9386 37.42 -0.1025 0.0001242 -5.555e-08 0 0 0);//
    }
    transport
    {
        muCoeffs<8>     (1.98e-06 2.601e-08 -9.145e-12 0 0 0 0 0);// viscosity(T) 
        kappaCoeffs<8>  (0.04287 0.0004602 -4.39e-08 0 0 0 0 0);//conductivity(T)
    }    
    
}

// ************************************************************************* //

And yes the properties are based on kelvin ;-)

Due to the size of the wire I only can imagine, that there can occur rounding errors while evaluating the temperature or heat flow. The heat input is in dimensions of 1-2 mW.

I really appreciate that you try to help me jherb!

[jherb]

On last idea:

You could modify the solver buoyantSimpleFoam (rename it to e.g. myBuoyantSimpleFoam, look for tutorials how to do this) and add fields for these values (kappa, rho, ...) to createFields.H and for each time step copy the values from thermo()->alpha() etc. to these fields and store them (MUST_WRITE ?) so you can check their values in paraview. I guess you could just start with your already converged solution and do one time step with your new solver to get these files.

Just an idea: If I remember correctly you might be able to do this with swak4foam without modifying the solver. Look at expressionField https://openfoamwiki.net/images/6/6d...ining_OFW8.pdf (page 79)

http://www.cfd-online.com/Forums/ope...tml#post567457

http://www.cfd-online.com/Forums/ope...tml#post446085
http://www.cfd-online.com/Forums/ope...tml#post465020
http://www.cfd-online.com/Forums/ope...tml#post567457

[Gerrit]

Hey,

I don't know if this will solve my problem, but I gave it a try as I always wanted to learn this. I came quite far I would say: When running a simulation I gain field for mu, rho and he (enthalpy). For some reason Cp and kappa (conductivity) are not written - I do not receive an error either. All the fields are set up like this:

   
 volScalarField Cp
    (
        IOobject
        (
            "Cp",
            runTime.timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        thermo.Cp()
    );

Did I forgot something?

Thanks again!

[jherb]

In one of the messages a linked above (or somewhere in the threads) I think I read that there can be a name collision if "Cp" is used for the new field, as this is already the name of the existing one. Perhaps you could try to use a different name like "cp" or "myCp".

[Gerrit]

Hi, that actually helped! Now I gain fields for everything I need. Before I proceed, I only have two smaller problems left:
1. When I start a simulation from "0" where I only defined the boundaries, the solver does not save a field, only values at boundaries. An example from the "he" file at timestep 10:

    outlet
    {
        type            mixedEnergy;
        refValue        uniform 0;
        refGradient     uniform 0;
        valueFraction   uniform 0;
        value           uniform 862060.707658628;
    }

If I run normal bouyantSimpleFoam and start a simulation with mybuoyantSimpleFOAM on that solution I gain the fields.

2. Problem is related to to the he field. The way of saving the boundaries of my walls seems to be wrong:

    wall1
    {
        type            gradientEnergy;
        gradient        uniform 0;
    }

If I want to gain values from the he field, I have to rewrite the above to "zeroGradient", otherwise OpenFOAM complains about it:

FOAM FATAL IO ERROR: 

    Cannot find 'value' entry on patch wall1 of field he in file "/home/usr/Desktop/test/10/he"
    which is required to set the values of the generic patch field.
    (Actual type gradientEnergy)

    Please add the 'value' entry to the write function of the user-defined boundary-condition


file: /home/usr/Desktop/test/10/he.boundaryField.wall1 from line 39 to line 40.

    From function genericFvPatchField<Type>::genericFvPatchField(const fvPatch&, const Field<Type>&, const dictionary&)
    in file genericFvPatchField/genericFvPatchField.C at line 71.

FOAM exiting

Changing the boundary to zeroGradient solves the problem.


Thank you for your help!

[jherb]

Do you copy the internal field into your newly created fields at the end of each simple loop step or just when you create the fields? This might explain why you only get the correct fields if you restart your case from 10 s. Also if you only copy it on creation the number of time steps does not matter.

(by the way I thought you use buoyantSimpleFoam so no real time steps but outer loop iterations)

Also the boundary conditions for these fields should not really matter because they are not use for any equation solving.