
[Sponsors] 
Understanding turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld 

LinkBack  Thread Tools  Display Modes 
September 2, 2011, 16:02 
Understanding turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld

#1 
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
I don't understand the last couple of lines of updateCoeffs of
turbulentTemperatureRadCoupledMixedFvPatch Code:
00186 scalarField Qr(Tp.size(), 0.0); 00187 if (QrName_ != "none") 00188 { 00189 Qr = patch().lookupPatchField<volScalarField, scalar>(QrName_); 00190 } 00191 00192 scalarField QrNbr(Tp.size(), 0.0); 00193 if (QrNbrName_ != "none") 00194 { 00195 QrNbr = nbrPatch.lookupPatchField<volScalarField, scalar>(QrNbrName_); 00196 distMap.distribute(QrNbr); 00197 } 00198 00199 scalarField alpha(KDeltaNbr  (Qr + QrNbr)/Tp); 00200 00201 valueFraction() = alpha/(alpha + KDelta); 00202 00203 refValue() = (KDeltaNbr*TcNbr)/alpha; 00204 00205 mixedFvPatchScalarField::updateCoeffs();  what is alpha? (doxygen points to the fine structure constant)  what is valueFraction?  Where does the call on line 205 to updateCoeffs end up? Thank you, Mirko 

September 2, 2011, 17:08 

#2  
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,031
Blog Entries: 39
Rep Power: 110 
Hi Mirko,
Sadly I'm unable to answer you the first two questions, but the last one I think I'm able to answer you. The trail is as follows:
Eclipse CDT is not perfect, has some (and had many) flaws, but it's really great when it works! Good luck with trailing the code back and forth! Bruno
__________________
Last edited by wyldckat; September 2, 2011 at 17:12. Reason: typo 

September 6, 2011, 10:20 

#3 
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Dear lord, what a mess this looks to these old untrained eyes :) All that to update a flag.
But I am kidding. Objectively, it does make sense. Thank you very much! Mirko 

September 15, 2011, 18:42 
making progress ...

#4  
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Quote:
My best guess is that turbulentTemperaturCoupledBaffle and friends set up the values of refValue, refGradient, and valueFraction. These are passed (HOW???) to mixedFvPatchField::evaluate() to calculate the patch temperature. If one goes through the equations in evaluate, the patch temprature is calculated to preserve heat flux continuity across the patch. So that makes sense. What I don't understand from the C++ point of view is that turbulentTemperatureCoupledBaffle::updateCoeffs calls mixedFvPatchScalarField::updateCoeffs(); But I could not find that function. Instead, I found mixedFvPatchScalarField::evaluate(); So, I am still missing a critical step, or followig a wrong path. Finally, if the above scenario is correct, this boundary condition is correct for steady state calculations. But I don't see how it would work for transient calculations (and it is used in transient chtMultiRegion... tutorials). Then again, my background is not numerical analysis. Mirko 

September 17, 2011, 05:55 

#5 
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,031
Blog Entries: 39
Rep Power: 110 
Hi Mirko,
Mmm... if I saw this correctly, it's as simple as inheritance: the class Code:
turbulentTemperatureCoupledBaffleMixedFvPatchScalarField This is why the evaluate method called is actually the one inherited, using the very same variables that were also inherited, simply because the other methods for setting the 3 variables are transparent to the outer code (i.e., visible from outside of the original class). For more, see this tutorial on C++ inheritance: http://www.cplusplus.com/doc/tutoria...e/#inheritance Best regards, Bruno
__________________


September 19, 2011, 16:35 

#6  
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Thanks Bruno,
Quote:
The values of valueFraction, refValue are set in turbulentTemperatureRadCoupledMixedFvPatch::updateCoeffs, which then calls mixedFvPatchScalarField::updateCoeffs(); As you pointed out, this only sets a the updated_ flag. So far, so good. The confusing part is that valueFraction, refValue are used in mixedFvPatchField::evaluate() to calculate the patch field and not in updateCoeffs(). So my question is how does the code get to this part? As I understand things now, evaluate() overloads the `=' operator. When solve is invoked, at some point the `=' calls this piece of code to return the new patch field value. Eventually, I will look at solve Thanks, Mirko 

September 19, 2011, 17:05 

#7  
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,031
Blog Entries: 39
Rep Power: 110 
Hi Mirko,
Mmm... Now I'm having trouble understanding what is your specific doubt!? Is it:
Quote:
As for your other statement that follows: Quote:
Best regards, Bruno
__________________


September 20, 2011, 13:42 

#8  
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Quote:
Quote:
Quote:
Mirko 

September 20, 2011, 14:45 

#9  
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,031
Blog Entries: 39
Rep Power: 110 
Hi Mirko,
Quote:
http://foam.sourceforge.net/docs/cpp...ce.html#l00267 Code:
00265 template<class Type> 00266 void Foam::fvPatchField<Type>::operator= 00267 ( 00268 const UList<Type>& ul 00269 ) 00270 { 00271 Field<Type>::operator=(ul); 00272 } Code:
fvPF_variable = other_variable; A little below those lines you'll see yet another overload for this same method, but that one allows for another kind of attribution, including a sanity check operation. As for going around checking the solve methods or functions, I would suggest starting back at a specific solver, since according to the source code documentation there seems to be hundreds of solve methods Best regards and happy code trailing! Bruno
__________________


September 21, 2011, 16:49 

#10 
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Thanks :)


September 22, 2011, 03:36 

#11 
Senior Member
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 10 
hi mirko!
did you succeed in using the BC? For me, at a certain level of radiative wall heat flux Qr, the BC causes unrealistic (high and low) temperatures and causes the solver to crash. regards, aram 

September 22, 2011, 08:59 

#12  
Senior Member
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 10 
Quote:
I don't have much experience in using it. I used it as a template to build a simpler interface boundary condition. I am not sure I gained much, except understanding the underlying machinery. If you have a sample problem that you can post, I would gladly take a look at it. I get the distinct impression that the BC is explicit, and thus may be susceptible to instabilities due to large time steps. Did you try shorter time steps? Also, what I do, is to make & use my own copy of the BC source. I can then sprinkle it with tracing statements. FYI, there is also gdbOF, a tool for debugging OF. I have not tried it. Mirko 

September 28, 2011, 09:43 

#13 
Senior Member
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 10 
Hey Mirko,
thanks for your answer. I tested the BC with different grids, refined the fluidsolid interfaces, both in the solid and fluid region, and as I use an adjustable time step (according to a prescribed CoNumber) also the time step changed; the solver always crashed due to unrealistically low/high temperatures at the interfaces. But no, I did not explicitly analysed the sensitivity of the BC with respect to the time step. In any case I cannot afford smaller time steps in my applications. Currently, I m testing a different approach (introduce radiative wall heat flux from fluid into solid) which seems to be much more stable but for now just runs on single CPU and not in parallel. I ll keep you informed and would also be interested in your experiences with the mentioned BC. Cheers, Aram 

October 12, 2011, 10:13 

#14 
Senior Member
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 186
Rep Power: 10 
Hallo,
finally I managed to modify the conjugate heat transfer BC including radiation, and implement the introduction of the radiative wall heat flux from the fluid side into the solid region. Its not optimal as a boundary (fluid_solid_interface) is handled on the solver level and not in an own boundary condition. Unfortunately, I couldn t figure out how to realize this approach in an own BC. Anyway, maybe somebody is interested so I attached the code (OF 1.7.x). In case you try the code, I d greatly appreciate your feedback. Cheers, Aram 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Problems in understanding BuoyantBoussinesqSimpleFoam  Anne Lincke  OpenFOAM  8  September 14, 2011 04:16 
Is this understanding of turbulence models correct?  3kha  Main CFD Forum  3  January 31, 2011 22:31 
basic understanding of sHM  colinB  OpenFOAM Native Meshers: snappyHexMesh and Others  1  October 6, 2010 08:17 
Problem understanding rhoPisoFoam  MatP  OpenFOAM Running, Solving & CFD  1  May 15, 2010 13:21 
Understanding of channelOodles and oodles solver  fs82  OpenFOAM  1  September 23, 2009 10:36 