[eelcovv]

Hi sandy,

I am using a modified oodles solver in which the temperature equation has been added just as has been done in the BoussinesqBuoyantSimpleFoam solver. Next, I use the oodles Pitch daily case with the following bc for T

inlet
{
type fixedValue;
value uniform 1580;
}
outlet
{
type zeroGradient;
}

lowerWall
{
type wallHeatFlux;
heatFlux uniform -2e6;
}
upperWall
{
type wallHeatFlux;
heatFlux uniform -2e6;
}

If you run this case in serial, i.e. just type boussinesqBuoyantTrLesFoam at the command line, after 0.001 second the newly create output file generates the following output for the lower and upperWall:

lowerWall
{
type wallHeatFlux;
heatFlux uniform -2e+06;
gradient nonuniform List<scalar>
250
(
-12132.5
:
: list of 250 values containing the temperature gradients
);
value nonuniform List<scalar>
250
(
1577.32
:
: list of 250 values containing the temperatures
);
}

So apparently, the temperature and temperature gradients are also written with the wallHeatflux bc. The wall temperature gradients are such that the heatflux qflux=-rho*Cp*alphaEff*dT/dy is -2e6 W/m2 on average. Note that the line
heatFlux uniform -2e+06;
is still maintained. If you restarts this run, it will continue correctly, with still a fixed heatflux at the boundaries.

However, you can also run this simulation parallel by first typing decompose so that domain is splitted in the processor1..processorN directories.
If you run this and then reconstruct the whole grid from the partitions, again the list of gradients and values of T is created, however, this time the following line is written
heatFlux uniform 0;
so the -2e6 heatflux is reset to 0. If you remove the processor directories, and decompose again, the wallheatflux will not be kept to 2e6 anymore. The reconstructed resuls file at 0.002 will again has a list of temperature and temperature gradients values, but the heatflux will now also be a nonuniform list like
lowerWall
{
type wallHeatFlux;
heatFlux nonuniform List<scalar>
250
(
1.12809e-312
1.12809e-312
6.00709e-07
5.28547e-07
:
: list of 250 values
);

I see now that the values are not necessarly corrupted, but just nearly to zero (normally with single precision, e-312 values would be corrupted, but we are using double precision now so the exponent is allowed to become that large)
The problem is that the heatflux is not 2e6 anymore, but zero.

There is an easy work around: correct the heatflux by setting it back to 2e6 after a reconstruction. However, this is quite some work if the file is large and especially if it is in binary format (which I usually have for large files to save storages and reduced I/O time). Besides, initially I was not aware of this behaviour and surprised to see my heatflux to dissappear suddenly. I suspect the the reconstructing algorithm does not know how to handle wallHeatflux bc's correctly. Using groovyBC does have this behaviour, so I am know using this bc. groovyBC also allows the set non-uniform heatfluxes or to set a heat transfer coefficient like

lowerWall
{
type groovyBC;
value uniform 1580;
valueExpression "1580";
gradientExpression "gradT";
fractionExpression "0";
variables "hcof=1000;Cp0=795;rho0=7023;Tamb=25;heatFlux=hcof *(T-Tamb);gradT=heatFlux/(alphaEff * Cp0 * rho0);"
timelines (
);
}

GroovyBC therefore seems to be a bit more flexible and at least does not have this behaviour of resetting the heatflux back to zero.

There is one strange thing with groovyBC which I found yesterday. Perhaps there is an experienced user who is able to explain this. Based on the list of temperature gradients and the list of alphaEff values, I can validate that the wallHeatflux is indeed correctly set to 2e6 on average if I use groovyBC. However, I would like to use the wallHeatFlux utility to quickly calculate the wallheat fluxes of my running simulation. I have a modified version of wallHeatFlux, wallHeatFluxLES, which allows to use this routine for LES simulations for incompressible flows (using the alphaEff based on nuSgs and change the h derivative to a rho*cp*dT/dx derivative). This routing works perfectly fine if I set the heatflux with wallHeatFlux, however, gives erroneous results for the groovyBC bc (about 1000 too large). Since I can also calculate the wallHeatFlux manually by mutliplying all the temperature gradients with the alphaEff (and rho*Cp of course), I can check that the heatFlux is correcly set to 2e6 W/m2 on average. However, if I rename the groovyBC bc to something unknow, like removing the initial g from the name:

upperWall
{
type roovyBC;
refValue uniform 0;
refGradient uniform 0;
valueFraction uniform 1;
value nonuniform List<scalar>
223
(
1577.33

then suddenly the wallHeatFluxLES utility calculates the correct value of the wallheatFlux. I really do not understand this behaviour. Hopefully there is a openFoam expert who can explain this ? Well, I see the Openfoam version 1.6 has been released, so I will check if the same happens with the new version.

Regards,

Eelco

[sandy]

Hi Eelco, I appreciate so much for your detailed explanation. I feel lucky not to meet this kind of bug. I am so weak to debuger the code.

[grandgo]

Originally Posted by eelcovv

[...]

There is one strange thing with groovyBC which I found yesterday. Perhaps there is an experienced user who is able to explain this. Based on the list of temperature gradients and the list of alphaEff values, I can validate that the wallHeatflux is indeed correctly set to 2e6 on average if I use groovyBC. However, I would like to use the wallHeatFlux utility to quickly calculate the wallheat fluxes of my running simulation. I have a modified version of wallHeatFlux, wallHeatFluxLES, which allows to use this routine for LES simulations for incompressible flows (using the alphaEff based on nuSgs and change the h derivative to a rho*cp*dT/dx derivative). This routing works perfectly fine if I set the heatflux with wallHeatFlux, however, gives erroneous results for the groovyBC bc (about 1000 too large). Since I can also calculate the wallHeatFlux manually by mutliplying all the temperature gradients with the alphaEff (and rho*Cp of course), I can check that the heatFlux is correcly set to 2e6 W/m2 on average. However, if I rename the groovyBC bc to something unknow, like removing the initial g from the name:

[...]

hi eelcovv,

how did you manage to connect the alphaEff with nuSgs? i'm desperately trying to get a modified pisoFoam solver (energy equation with alphaEff included) to work, that uses dynSmagorinsky turbulence model.

can you show me the c++ source of wallHeatFluxLES?

best regards