Register Blogs Members List Search Today's Posts Mark Forums Read

 September 2, 2011, 16:02 Understanding turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld #1 Senior Member   Mirko Vukovic Join Date: Mar 2009 Posts: 159 Rep Power: 13 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(QrName_); 00190 } 00191 00192 scalarField QrNbr(Tp.size(), 0.0); 00193 if (QrNbrName_ != "none") 00194 { 00195 QrNbr = nbrPatch.lookupPatchField(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();``` Questions: - 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
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,956
Blog Entries: 45
Rep Power: 122
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:
1. All starts with looking at "mixedFvPatchScalarField::" - The two ":" indicate that the method/variable on the right is not located on the current class or namespace. To the left of them is the name of the class to who the method/variable refers to. In this case, the class mixedFvPatchScalarField.
Note: when there is nothing to the left, it means it's on the global nameless namespace!
2. The class "mixedFvPatchScalarField" is inherited by "turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld" ( looong name! even the forum broke the name in two!). This is shown in turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld.H line 82.
3. Mmm, no link at line 82 due to some strange reason. Then lets look at the included files in that header file. In line 65 you can find this:
Code:
`#include "mixedFvPatchFields.H"`
4. On line 39 of that newly found file, you can see this:
Code:
`makePatchTypeFieldTypedefs(mixed);`
No wonder that in the point #3 the other line had no link. This class is completely defined using a macro!
5. Er... this link is pretty much as good as dead... it doesn't show the macro itself! Mmm, we have to go back to where the macro was being used.
6. On line 29 on the file at point #4, you can see a reference to "mixedFvPatchField.H". This link leads to a template header file. It's a generic definition to which it is adapted the term "mixed"! Mmm... let's see if "updateCoeffs" is in here... it's not! Then it's got to be even more upstream!
7. On line 52 of "mixedFvPatchField.H", the template class "mixedFvPatchField" inherits from another template class, namely fvPatchField. This link leads to a nice looking page with a graph with a list of classes that inherit their good looks from fvPatchField.
8. Searching on this new page, we can find "updateCoeffs", right here. Mmm, the description for it talks about a lot of evaluate methods that call this method... but where is the code!? Wait, what's this:
Quote:
 Definition at line 347 of file fvPatchField.H.
That looks suspicious
9. OK, line 347 at fvPatchField.H is... this!?
Code:
```00345             //- Update the coefficients associated with the patch field
00346             //  Sets Updated to true
00347             virtual void updateCoeffs()
00348             {
00349                 updated_ = true;
00350             }```
Well, since this method doesn't seem to have been reimplemented on one of the classes we've gone through, then I can only assume that this is what we were looking for!
I only used the online documentation to do the trailing back to the place where this method is defined, but for a quicker/easier way to do this is the one and great tool for trailing/tracing code in OpenFOAM (well, C/C++ code in general) - Eclipse CDT: http://openfoamwiki.net/index.php/Ho...M_with_Eclipse
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: 13 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: 13
Quote:
 Originally Posted by mirko 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
Well, I spent two days poring over doxygen and navigating the source files, and I think I have a better understanding (I actually enjoyed the exploration). But I am still missing some critical C++ steps.

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 Retired Super Moderator   Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,956 Blog Entries: 45 Rep Power: 122 Hi Mirko, Mmm... if I saw this correctly, it's as simple as inheritance: the class Code: `turbulentTemperatureCoupledBaffleMixedFvPatchScalarField` inherits its core structure from "mixedFvPatchField". Therefore, if you see the header file for the mixedFvPatchField class template, you can see that those 3 variables are accessible through dedicated methods (lines 148 to 176), because they are stored in this very same class template! 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 __________________ OpenFOAM: FAQ | Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM

September 19, 2011, 16:35
#6
Senior Member

Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 13
Thanks Bruno,

Quote:
 Originally Posted by wyldckat Hi Mirko, Mmm... if I saw this correctly, it's as simple as inheritance: ... snip ... Best regards, Bruno
I am aware about inheritance and it's role in this case. What I am confused is as follows:

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
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,956
Blog Entries: 45
Rep Power: 122
Hi Mirko,

Mmm... Now I'm having trouble understanding what is your specific doubt!? Is it:
1. You don't understand how "turbulentTemperatureRadCoupledMixedFvPatch::updateCoeffs" is called from mixedFvPatchField::evaluate()?
2. You don't understand how mixedFvPatchField::evaluate() is called in the first place?
As for one of your statements:
Quote:
 As I understand things now, evaluate() overloads the `=' operator.
As far as I can understand it, it's not specifically a method overload, it's a simple call to the "operator=" method; this means that the method is called as if it were any other normal method.

As for your other statement that follows:
Quote:
 When solve is invoked, at some point the `=' calls this piece of code to return the new patch field value.
I suppose so, that evaluate is in fact called by solve. I haven't checked this yet, but at the very least it looks to be a good guess.

Best regards,
Bruno
__________________

September 20, 2011, 13:42
#8
Senior Member

Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 13
Quote:
 Originally Posted by wyldckat Hi Mirko, Mmm... Now I'm having trouble understanding what is your specific doubt!? Is it:You don't understand how "turbulentTemperatureRadCoupledMixedFvPatch::updateCoeffs" is called from mixedFvPatchField::evaluate()? You don't understand how mixedFvPatchField::evaluate() is called in the first place?
b. updateCoeffs seems to set up the necessary variables, and evaluate then calculates the patch field

Quote:
 Originally Posted by wyldckat As for one of your statements: As far as I can understand it, it's not specifically a method overload, it's a simple call to the "operator=" method; this means that the method is called as if it were any other normal method.
I need to get hold of a C++ reference to understand exactly what operator= means. I assumed the it meant operator overloading.

Quote:
 Originally Posted by wyldckat As for your other statement that follows:I suppose so, that evaluate is in fact called by solve. I haven't checked this yet, but at the very least it looks to be a good guess. Best regards, Bruno
My guess too. I'll dig some more.

Mirko

September 20, 2011, 14:45
#9
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,956
Blog Entries: 45
Rep Power: 122
Hi Mirko,

Quote:
 Originally Posted by mirko I need to get hold of a C++ reference to understand exactly what operator= means. I assumed the it meant operator overloading.
Ah, then you can see this nearby example:
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 }```
This is an interesting example of overloading the "operator=". As you can see, whenever a variable defined to be "fvPatchField<Type>" is attributed a value with the "=" sign:
Code:
`fvPF_variable = other_variable;`
Then this method "operator=" is called in place of the normal value attribution between variables. In this case, it goes even further and allows the operation to go through to the parent class for assigning/copying the requested data.

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: 13 Thanks :-)

 September 22, 2011, 03:36 #11 Senior Member   Aram Amouzandeh Join Date: Mar 2009 Location: Vienna, Vienna, Austria Posts: 190 Rep Power: 13 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: 13
Quote:
 Originally Posted by mabinty 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
Hi Aram,

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: 190 Rep Power: 13 Hey Mirko, thanks for your answer. I tested the BC with different grids, refined the fluid-solid interfaces, both in the solid and fluid region, and as I use an adjustable time step (according to a prescribed Co-Number) 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: 190
Rep Power: 13
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
Attached Files