wallHeatFlux BC not constant after restart
 

Dear all,

I have some problems with the wallHeatFlux bc as contributed by

http://openfoamwiki.net/index.php/Contrib_wallHeatFlux

When the bc is imposed as a constant value like

boundaryField
{
_x
{
type wallHeatFlux;
heatFlux uniform 0.0025;
}
}

the average heatflux is exactly 0.0025 (as determined with the utility wallHeatFlux modified for incompressible flows).

However, if I make a restart from the last iteration of a finalised run, the heat flux is not maintained anymore but changes. (I am using boussinesqBuoyantSimpleFoam solver). If a transient solver is used, the heatflux keeps changing.
The problems seems to be related to the fact that the heatflux is not a constant value in the latest time step anymore, but defined as a non-uniform list. Replacing this list to the uniform value again fixes the problem. However, sometimes I do want to use a non-uniform list of a want to define a varying heatflux over the boundary.

Is there anybody who had the same problem and found a solution for this?

Any hints apreciated.

Kind regards,

Eelco

Solution to wrong heatFlux BC after restart
 

For those interested,

the problems with the non-constant heatflux after a restart can be prevented by also setting the gradient and value at the initial time step, for instance in the 0/T field:


dimensions [0 0 0 1 0 0 0];

internalField uniform 1580;

boundaryField
{
upperWall
{
type wallHeatFlux;
heatFlux uniform -2e6;
gradient uniform 0;
value uniform 1580;
}
}

It appears that by writing the full data field of T, also the gradient and value are written (also if you do not specify them initially), but that then all the heatflux values are corrupted. If you specify gradient and heatFlux explicitely at 0/T, then the heatFlux is written as a uniform value (instead of a nonuniform list of corrupted values).

Eelco

I can not understand, eelcovv, why a restart will corrupt the boundary condition?? or the result??

I guess, you mean, to boussinesq buoyant problems, in every iterative time and spatial levels its results are often divergent (not unique resolution problem), so different restart time and interative step will influent on the result of next step? difficult...

Hi Sandy,

No, what you say is not what I mean. This is not a divergence of the simulation, but a bug in the wallHeatFlux. With corrupting I mean that the values are non-valid numbers like 1e-341, 1e35, etc. I found that the problem is introduced by the reconstruction step if you are doing a parallel calculation. I used the pitchDaily geometry to try to set a constant heatflux at the upper and lower wall as defined in my first post. If you stop a parallel calculation and reconstruct it, the heatflux values in the reconstructed files are corrupted (just run 1 iteration and look in the ascii file). My solution could not prevent this problem, I thought I solved it in my second post because I checked it with a serial run, and then the problem does not occur. I think that the wallHeatflux bc can not be used with parallel calculations if you want to be able to restart a stopped run.

Today I checked an alternative way to set the heatflux and that works, even for parallel runs. I now use groovyBC and define a heatFlux at the wall occording to:

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

In this way, a wall heatFlux of -2e6 W/m2 is impsed at the lowerWall boundary.
This gives identical results as wallHeatflux since they both use the effective thermal diffusivity at the wall to calculate and set the temperature gradient at the wall. However, reconstructing the decomposed parts using groovyBC does not corrupt the heatflux values. The only disadvantage is that the exact order of the lines in groovyBC is important, so use exactly the order as above (putting the 'variables' line avove the gradientExpresion line sets the gradientsExpression to zero). A big advantage of groovyBC is the ability to be able to define a non-uniform heatflux as well.

Well, hopefully it is clear. Just play with a pitchDaily geometry and play with the BC to see for yourself.

Cheers,

Eelco

Hi Eelco, thank you very much for your explanation. However, I still can not understand how can you find a stop makes a corruption of heatflux values in the reconstructed files?

You mean, if we do not stop the code, we can get every correct field files p, U, T and so on at every time step; however, if we stop the code, those field files at the last time step are corrupted, right? If that, can you restart a new iteration from the time step before the last time step? What about its reconstructed files?

In addition, I am actually stuned, in piso, which step will produce thoes "reconstructed" files called by you?

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

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.

Hi Eelco,

I inserted the groovyBC variables which looks like this

variables "heatFlux=750;Cp0=4180;rho0=1000;gradT=heatFlu x/(alphaEff * Cp0 * rho0)";

but it gives me error saying that it doesn't recognise gradT=heatFlux/(alphaEff * Cp0 * rho0)

Any hint?

Thanks very much.

groovyBC error:
 

elcovv:

I met a similar problem with groovyBC using OpenFOAM 1.6. I used the groovyBC to apply a constant gradient bc, to test the accuracy of the code.

Here is the bc setup:

working
{
type groovyBC;
value uniform 0;
valueExpression "0";
gradientExpression "100"; //"-Deff1*grad";
fractionExpression "0";
// variables "grad=snGrad(C_peroxide);Deff1=0.3827;";
}

Then I used wallMassFlux (modified from wallHeatFlux utility) to calculate the species gradient on the wall and found that the gradient is a lot higher than 100. I tried to rename groovyBC as a random name according to your suggestion but it does not help.

I am 100% sure that my wallMassFlux utility works properly because I tested it using a fixedGradient bc instead. The results has been consistent.

Have u figured out what is the cause of the problem?

Thank u so much.

Ning

Add a semicolon after the last variable (eecolv has it right in his posting)

In you case groovy degenerates into a fixed gradient with grad=100. To check this replace groovyBC with mixed (valueFraction uniform 0). It should give the same results as groovy. If it does the problem is not with groovyBc, but either with your case or the mixed-BC (unlikley)

Would surprise me, because basically groovy calculates the stuff for mixed and then lets mixed do the hard work, but nothing is impossible. In fact for later timesteps it writes the usual stuff for mixed (refValue, refGradient, valueFraction). Could you please check if they are what you expect?

If the problem persists please write a bug to
http://sourceforge.net/apps/mantisbt...l_bug_page.php
(if possible with a small test-case) and I'll have a look

The refValue, refGradient and valueFraction values are all correct. It is weird that the calculated mass flux is off by a big margin.

Hi Bernard:

Thank u for help. I did some further testing and found something very similar to Eelco's post. Basically after the calculation, if I change the name of groovyBC in time data file to a different name, I get correct results (wall flux) using my self made wallMassFlux, which is very similar to openfoam wallHeatFlux. Does this look like a bug to u? Or something is wrong with my wallMassFlux.

Thank u.

Ning

No idea. And I currently have enough interesting problems of my own so I can't be bothered to have a look before I find a bug-report at
https://sourceforge.net/apps/mantisb...l_bug_page.php

Bernhard

wallHeatflux and groovybc
 

Hi Ning,

The wall heatflux as imposed by groovyBC is correct, however, it seems that other external utilities do not know how to deal with groovyBC. I have recompiled my wallHeatFlux for incompressible flows (wallHeatFluxIncompressible) with the groovyBC library, hoping that that would help, but the calculated heatFlux is still not correct. Also for instance running 'foamCalc magGrad T' gives the wrong gradient field, thus also this openFoam native utilitydoes not know how to deal with groovyBC.

The temperatures in the nonuniform list of the groovyBC boundary, however, do correspond with the correct heatFlux. If you replace 'groovyBC' with 'fixedValue' in your boundary and run wallHeatFluxIncompressible, the correct heatFlux is shown. You can easily replace all your T data files by using the perl script I wrote a while ago, fndrpl.pl. Just do

fndrplc.pl -expr 's/groovyBC/fixedValue/' `find [1-9]* -name T` -overwrite -verbose

I have include my wallHeatFluxIncompressible and fndrpl.pl to this post.

It is a bit unhandy that groovyBC is not recognised by other utilities, but the imposed heatFlux and the resulting temperature field is correct, that is the most important conclusion. I am still a big fan of groovyBC, it can be used to impose a broad range of boundary conditions.

Regards

Eelco

Eelco:

Thank you for sharing the script. It makes things much easier for transient problems.

Ning

If heat flux is non uniform; it changes according to internal temp field
 

Hello All,
I have vertical annulus cylinder with Argon gas filled in. The bottom of the annuli of the cylinder is kept at a constant temperature 400K. The outerSideWall is cooled by air having temperature of 393K. As the argon gas gets heated, it raises up; meanwhile it looses it energy along vertical direction. I have a problem the temperature BC I use at the outerSideWall of this vertical annulus. I can not use BC like wallHeatFlux becasue it gives constant heat flux. The gas is loosing energy due to cooling at the outerSideWall, so it will have variable type of heat flux along vertical direction. I need assistance that how this variable heat transfer could be implemented. Though I have tried with groovyBC as below

outerSideWall
{
type groovyBC;
value uniform 393;
valueExpression "T";
gradientExpression "gradT";

fractionExpression "0.5";
variables "hcof=0.04;Cp0=520;rho0=0.81;alphaEff=pow(10,-4);heatFlux=hcof *(T-Tamb);gradT=-heatFlux/(alphaEff * Cp0 * rho0);"
// valueExpression "";
timelines (
);

}

but this puts a constant heat loss at the outerSideWall. As gas raises up it will loss heat flux gradually rather then a fixed value. I need to incorporate this decrease of heat loss at the outerSideWall. I am thinking to make Tamb (temperature of argon) be variable such that it would be connected with the temperature of the internal field. If argon losses heat and temperature; that in turn decrease Tamb, henceforth the heatflux.
Could anybody help me in this problem; I would be really thankful to him. This might solve my long awaited problem.

thank you

Hi Dinesh,

I think the way you do it should give a variable heat flux, as it T-Tamb becomes smaller when the gases cools off (T is the temperature of the gas at the wall). I only don't undestand why you have fractionExpression "0.5", because this combines a constant gradient with a constant value BC, whereas what you want is just to impose a constant gradient which scales with T-Tamb, so you should set fractionExpression "0.0";.

Regards,

Eelco