[Roman1]

Hello. The function externalWallHeatFluxTemperature works differently at OF2.2 and at OF2.3 but the source code looks equal. Where one can find differences?

[massive_turbulence]

Originally Posted by Roman1

Hello. The function externalWallHeatFluxTemperature works differently at OF2.2 and at OF2.3 but the source code looks equal. Where one can find differences?

What exactly do you mean "works differently"? Are the enumerators different in terms of words used to describe the object? Did you get different results using the same dictionary file?

[Roman1]

Yes, I get different results at Of2.2 and OF2.3 with the same case. The function wallHeatFlux shows greater values at OF2.3 and the temperature inside the domain at OF2.2 higher that at OF2.3.

[olivierG]

hello,
Not sure here, but i think there were a bug report about this bc for OF2.2

regards,
olivier

[Roman1]

The bug is in OF2.3: http://www.openfoam.org/mantisbt/view.php?id=1258
Thanks to all

[derekm]

how does one get a fixed version of this in openfoam?

[olivierG]

Just use the 2.3.x version from git repo.
Then a git pull and Allwmake will give you a up to date version.

regards,
olivier

[Jean El-Hajal]

Dear all,

are you using the externalWallHeatFluxTemperature function with the heat flux (q) option or with the heat transfer coefficient (h) and external temperature (Ta) option ?

With the heat flux (q) it seems to work. But with the heat transfer coefficient (h) and external temperature (Ta) it works with OpenFoam 2.2.2 but not with OpenFoam 2.3.0. With OF 2.3.0 it just behave like an adiabatic wall ?! Did someone test this option with OF 2.3.0 ?

Best regards,

Jean

[Roman1]

The bug is in OF2.3: http://www.openfoam.org/mantisbt/view.php?id=1258

[vasava]

I have installed openFoam by following instructions on the openFoam website. I do not wish to go through the installation process again. Is there any workaround to use the corrected boundary condition??

[Naresh yathuru]

Hi Foamers,

I m also using OF 2.3.0 and I have the same problem like vasava. could someone please help me how to clear the bug with out re installing again. I m afraid if i have to reinstall openFoam again. because i m using centOS 6.5 and i struggled a lot during the previous installation. and i m not a very good user of linux os.

regards,
Naresh

[Naresh yathuru]

Hi Foamers,
sorry for restarting the thread again. I have a similar problem with externalwallheatFluxTemperature. Could somebody help me. I have a question in this link.

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

I m using OF 2.3.0. and I read in some threads that there is a bug in 2.3.0. could someone tell me if which of the following a better idea to fix the bug.

1. make new boundary condition by copying the bounday condition from 2.3.1 into 2.3.0?
2. reinstall from git repository? if this is better then how?

3. can i use the boundary condition for incompressible solver?(buoyantboussinessqsimplefoam)

I m feel lost now.

regards,
Naresh Yathuru

[Moderator note: post moved from the thread http://www.cfd-online.com/Forums/ope...bient-air.html ]

[wyldckat]

Hi Naresh,

Originally Posted by Naresh yathuru

1. make new boundary condition by copying the bounday condition from 2.3.1 into 2.3.0?

I don't know if you've already solved this problem or not, but the easiest is to follow these steps:

1. Run these commands, for going to the folder for fixing the damaged boundary condition:
   

   cd $FOAM_SRC/turbulenceModels/compressible/turbulenceModel/derivedFvPatchFields/externalWallHeatFluxTemperature/

2. Backup the current file:
   

   mv externalWallHeatFluxTemperatureFvPatchScalarField.C externalWallHeatFluxTemperatureFvPatchScalarField.C.old

3. Download the file that has the fixed file:
   

   wget --no-check-certificate https://raw.githubusercontent.com/OpenFOAM/OpenFOAM-2.3.x/master/src/turbulenceModels/compressible/turbulenceModel/derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C

4. Now build the library that needs to be fixed:
   

   cd $FOAM_SRC/turbulenceModels/compressible/turbulenceModel
   wmake libso

5. Run the last command again:
   

   wmake libso

   it should tell you something like this:
   

   '/home/ofuser/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/libcompressibleTurbulenceModel.so' is up to date.

   which means that it's fixed.

And it should now work correctly.


Best regards,
Bruno

[Naresh yathuru]

hello Bruno,

thank you for the reply once again. I was interested in using the externalwallHeatFluxTemperature for incompressible flows. but as far as i have read it works only for compressible solver and in addition to that there is a bug. so i was trying something with grooveyBC but without sucess.

Now i should get back to square 1, and try to implement the b.c for incompressible solvers. I know its really hard for someone like me who doesnt have a very good knowledge of c++.However i will try it sooner or later. i have started making changes to some basic solvers. i m comparing compressible ::turbulent'WallHeatTemperature B.C with incompressible:: turbulentWallHeatfluxTemperature B.C.


May be this is not an appropriate thread to ask this question. sorry but,It would be very helpful if someone had already implemented could post the B.c or any guidence on how to implenent it.

thanks once again Bruno and other Foamers.

Best Regards,
Naresh

[flowAlways]

Thanks Bruno,

Your solution works when we make changes to the FOAM_SRC, however since its not a good idea to make changes to the actual source. I copy the directory $FOAM_SRC/turbulenceModels/compressible/turbulenceModel make changes to externalWallHeatFluxTemperatureFvPatchScalarField. C and update
LIB = $(FOAM_USER_LIBBIN)/libmy_compressibleTurbulenceModel in Make/files.

However the build with "wmake libso" exits with the following error

derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C:72:  error: class ‘Foam::externalWallHeatFluxTemperatureFvPatchScalarField’  does not have any field named ‘QrName_’

I think Qr for radiation was implemented in version 2.3.1 and is not present in 2.3.0 ... and therefore the make fails... can you please suggest a way, what more changes would be needed for a successful build ?

Originally Posted by wyldckat

Hi Naresh,


I don't know if you've already solved this problem or not, but the easiest is to follow these steps:

1. Run these commands, for going to the folder for fixing the damaged boundary condition:
   

   cd $FOAM_SRC/turbulenceModels/compressible/turbulenceModel/derivedFvPatchFields/externalWallHeatFluxTemperature/

2. Backup the current file:
   

   mv externalWallHeatFluxTemperatureFvPatchScalarField.C externalWallHeatFluxTemperatureFvPatchScalarField.C.old

3. Download the file that has the fixed file:
   

   wget --no-check-certificate https://raw.githubusercontent.com/OpenFOAM/OpenFOAM-2.3.x/master/src/turbulenceModels/compressible/turbulenceModel/derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C

4. Now build the library that needs to be fixed:
   

   cd $FOAM_SRC/turbulenceModels/compressible/turbulenceModel
   wmake libso

5. Run the last command again:
   

   wmake libso

   it should tell you something like this:
   

   '/home/ofuser/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPOpt/lib/libcompressibleTurbulenceModel.so' is up to date.

   which means that it's fixed.

And it should now work correctly.


Best regards,
Bruno

[wyldckat]

Greetings flowAlways,

Sorry, but I'll have to be quick: you're doing the right thing in not modifying the original source code directly, but you should not copy the source code for the whole library, otherwise you risk in-process memory corruption, due to having objects with the same name.

You should instead to it as explained here: http://openfoamwiki.net/index.php/Ho...dary_condition
which is to make a copy of only the relevant files you need to fix.

In addition, I guess that the fix I proposed in the previous post only repairs the ".C" file. Therefore, you should also update the ".H" file.

Best regards,
Bruno

[matthi]

Hi Foamers,

if you also update externalWallHeatFluxTemperatureFvPatchScalarField. H it works.

Greetings matthi

[vak96]

Hi Foamers,

I want to use externalWallHeatFluxTemperature boundary condition for my own customized laplacian solver. Can anyone please explain in detail, how to apply that boundary condition? I know that it has been used in few tutorial problem but I could not get exactly how to use it.

I am using Openfoam-v1612+ and my geometry is a cylinder. I want this boundary condition for walls.

I will be very happy if someone helps me.

Thanking you in advance,
Akshay

[calf.Z]

I am also confused about the parameters of externalWallHeatFluxTemperature. Can anyone explain its meaning? Thank you.

[Vishsel]

Hi all,

In my case, i have to use a boundary type that needs the input as heat Flux, which is recalculated to get the output as temperature. my solver is chtMultiRegionSimpleFoam.

0/T file :

wall-mp-1
    {
        type            externalWallHeatFluxTemperature;
        heatSource      flux;
        q               uniform 6000 ;
        alphaEff        alphaEff;
        value            uniform 323.15; ? //why i need to give temp. value ? because i already gave 'q' value know?
        kappa           solidThermo;
        kappaName       none; 
    }

Solving for fluid region fluid
DILUPBiCG:  Solving for Ux, Initial residual = 0.00242038, Final residual = 2.85334e-005, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 0.00466735, Final residual = 7.31426e-005, No Iterations 1
DILUPBiCG:  Solving for Uz, Initial residual = 0.00371143, Final residual = 0.00020355, No Iterations 1
DILUPBiCG:  Solving for h, Initial residual = 0.00293122, Final residual = 0.000270902, No Iterations 1
Min/max T:323.3 323.3
GAMG:  Solving for p_rgh, Initial residual = 0.0017874, Final residual = 1.12521e-005, No Iterations 3
time step continuity errors : sum local = 0.0587456, global = 0.00203603, cumulative = 10.1817
Min/max rho:***
DILUPBiCG:  Solving for epsilon, Initial residual = 0.00358344, Final residual = 4.05951e-005, No Iterations 2
DILUPBiCG:  Solving for k, Initial residual = 0.00331097, Final residual = 3.24722e-005, No Iterations 2

Solving for solid region solid
DICPCG:  Solving for h, Initial residual = 0.00218476, Final residual = 9.17909e-006, No Iterations 4
Min/max T:min(T) [0 0 0 1 0 0 0] 323.129 max(T) [0 0 0 1 0 0 0] 349.782
ExecutionTime = 788.942 s  ClockTime = 789 s

Why there is a need of two inputs as temp. value and heat flux value in 0/T ? Because i need to set an input as heat flux value only..

Is this boundary type is correct for assigning of heat flux as an input ? if it is not, Which one is suitable for my case?