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

trouble with totalTemperature BC

Register Blogs Community New Posts Updated Threads Search

Like Tree1Likes
  • 1 Post By pg22

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 26, 2009, 14:34
Default trouble with totalTemperature BC
  #1
New Member
 
Paul Garlick
Join Date: Mar 2009
Location: Bournemouth, UK
Posts: 27
Rep Power: 17
pg22 is on a distinguished road
I am using OF1.5 and rhopSonicFoam for a compressible external flow case. On the far field boundary I would like to apply a totalTemperature boundary condition:

topBoundary
{
type totalTemperature;
T0 uniform 300;
U U;
phi phi;
psi psi;
gamma 1.4;
value uniform 300;
}

I find that solver aborts with the following message:

request for volVectorField U from objectRegistry region0 failed
available objects of type volVectorField are

0
(
)

I have found that a totalPressure boundary condition (with fixedValue for T) runs for a short time before inflow leads to rapid divergence.

In the source files for totalPressure and totalTemperature I see that the vector field for velocity is accessed in a different way in each case:

For totalTemperatureFvPatchScalarField.C:

const fvPatchVectorField& Up =
patch().lookupPatchField<volVectorField, vector>(UName_);

For totalPressureFvPatchScalarField.C:

void totalPressureFvPatchScalarField::updateCoeffs()
{
updateCoeffs(patch().lookupPatchField<volVectorField, vector>(UName_));
}

Can anyone explain why the former BC fails and the latter
succeeds; and even suggest a solution?

Many thanks.

pg22 is offline   Reply With Quote

Old   October 27, 2009, 10:15
Default
  #2
New Member
 
Paul Garlick
Join Date: Mar 2009
Location: Bournemouth, UK
Posts: 27
Rep Power: 17
pg22 is on a distinguished road
More information ...

I noticed from the log file (for rhopSonicFoam > log) that the totalTemperature BC causes the solver to abort after writing the message:

Reading field T

This message comes from the header file "createFields.H". There is a function T.correctBoundaryConditions() that is called before the vector field for U is established. The fields are created in the order p, T, psi, rho, U, rhoU, rhoE, phiv.

My question is; may I re-arrange the code so that the vector field for U is created before T.correctBoundaryConditions() is called? The order could be p, U, T, psi, rho, rhoU, rhoE, phiv, for example.
pg22 is offline   Reply With Quote

Old   October 28, 2009, 13:28
Default
  #3
New Member
 
Andrew Godfrey
Join Date: Mar 2009
Posts: 7
Rep Power: 17
agodfrey is on a distinguished road
Sorry, I can't help any, but I'm clawing my way through these bcs also. Any idea what psi and phi represent? I assume phi is the mass flux vector (rho U). Also, in the code, there's a 1 - pos(phip). Any idea where pos() is defined or what it does?
agodfrey is offline   Reply With Quote

Old   October 28, 2009, 13:38
Default
  #4
New Member
 
Andrew Godfrey
Join Date: Mar 2009
Posts: 7
Rep Power: 17
agodfrey is on a distinguished road
Found the pos() function in Doxygen.

00103 inline Scalar pos(const Scalar s)
00104 {
00105 return (s >= 0)? 1: 0;
00106 }

I still don't know what phip is though. I assume it's negative though, or else the bc isn't very useful.
agodfrey is offline   Reply With Quote

Old   October 28, 2009, 15:54
Default
  #5
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by agodfrey View Post
Found the pos() function in Doxygen.

00103 inline Scalar pos(const Scalar s)
00104 {
00105 return (s >= 0)? 1: 0;
00106 }

I still don't know what phip is though. I assume it's negative though, or else the bc isn't very useful.
phip: phi on a patch. The definition of phi (mass flow on the face) has been discussed a number of times. Sign says whether it's flowing in or out
gschaider is offline   Reply With Quote

Old   October 28, 2009, 20:18
Default
  #6
New Member
 
Andrew Godfrey
Join Date: Mar 2009
Posts: 7
Rep Power: 17
agodfrey is on a distinguished road
Thanks Berhard. Saw several of your talks in Montreal last June. I figured the phi part out after the post. From the code, psi must equal rho/p, but I don't know why or how this bc's dictionary works. Why is U part of the class?
agodfrey is offline   Reply With Quote

Old   October 29, 2009, 04:39
Default
  #7
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by agodfrey View Post
Thanks Berhard. Saw several of your talks in Montreal last June. I figured the phi part out after the post. From the code, psi must equal rho/p, but I don't know why or how this bc's dictionary works. Why is U part of the class?
Never worked with that boundary condition. But I guess for multiphase-solvers where more than one velocities exist
gschaider is offline   Reply With Quote

Old   October 29, 2009, 05:49
Default
  #8
New Member
 
Paul Garlick
Join Date: Mar 2009
Location: Bournemouth, UK
Posts: 27
Rep Power: 17
pg22 is on a distinguished road
Have made some progress with this problem...

First, I re-ordered the creation of the fields defined in "createFields.H". I used the order I mentioned above; p. U, T, psi, rho, rhoU, rhoE, phiv. I re-compiled and found that the solver aborted again, this time on searching for the scalar field phi.

Then I moved the T.correctBoundaryConditions() function down in the file, to the line below rhoU.correctBoundaryConditions().

I re-compiled and the solver ran successfully. However, in order to update the boundary condition after each time step one extra change is needed:

in rhopSonicFoam.C I added the update function just below the expression for U;

U=rhoU/rho;
T.correctBoundaryConditions();


I have re-compiled rhopSonicFoam and it works fine; the temperature at the far field boundary is adjusted as pressure waves move through and the local velocity changes.

To answer the question on why U is involved, the totalTemperature function is simply
an expression of the energy equation; as the velocity increases the temperature drops.
FrankFlow likes this.
pg22 is offline   Reply With Quote

Reply


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
[GAMBIT] Trouble meshing complex VOF geometry RPJones ANSYS Meshing & Geometry 2 February 14, 2011 18:54
Finned Pipe Trouble fabioxyz CFX 8 August 31, 2009 02:20
trouble with squeezing mesh adrianahscott OpenFOAM Running, Solving & CFD 0 August 29, 2009 07:25
Epsilon Convergence Trouble Carlos FLUENT 4 August 27, 2007 11:22
Could anybody help the trouble of the modifying the U liugx212 OpenFOAM Running, Solving & CFD 2 February 27, 2006 10:23


All times are GMT -4. The time now is 02:22.