CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

Understanding turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld

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

Reply
 
LinkBack Thread Tools Display Modes
Old   September 2, 2011, 16:02
Default Understanding turbulentTemperatureRadCoupledMixedFvPatchScalarFi eld
  #1
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
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();
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
mirko is offline   Reply With Quote

Old   September 2, 2011, 17:08
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,253
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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"
    Nice, it's a click-able link!
  4. On line 39 of that newly found file, you can see this: 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
wyldckat is offline   Reply With Quote

Old   September 6, 2011, 10:20
Default
  #3
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
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
mirko is offline   Reply With Quote

Old   September 15, 2011, 18:42
Default making progress ...
  #4
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
Quote:
Originally Posted by mirko View Post
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
mirko is offline   Reply With Quote

Old   September 17, 2011, 05:55
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,253
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   September 19, 2011, 16:35
Default
  #6
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
Thanks Bruno,

Quote:
Originally Posted by wyldckat View Post
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
mirko is offline   Reply With Quote

Old   September 19, 2011, 17:05
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,253
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   September 20, 2011, 13:42
Default
  #8
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
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?
b. updateCoeffs seems to set up the necessary variables, and evaluate then calculates the patch field

Quote:
Originally Posted by wyldckat View Post
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 View Post
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
mirko is offline   Reply With Quote

Old   September 20, 2011, 14:45
Default
  #9
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,253
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Mirko,

Quote:
Originally Posted by mirko View Post
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
wyldckat is offline   Reply With Quote

Old   September 21, 2011, 16:49
Default
  #10
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
Thanks :-)
mirko is offline   Reply With Quote

Old   September 22, 2011, 03:36
Default
  #11
Senior Member
 
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 184
Rep Power: 8
mabinty is on a distinguished road
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
mabinty is offline   Reply With Quote

Old   September 22, 2011, 08:59
Default
  #12
Senior Member
 
Mirko Vukovic
Join Date: Mar 2009
Posts: 159
Rep Power: 8
mirko is on a distinguished road
Quote:
Originally Posted by mabinty View Post
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
mirko is offline   Reply With Quote

Old   September 28, 2011, 09:43
Default
  #13
Senior Member
 
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 184
Rep Power: 8
mabinty is on a distinguished road
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
mabinty is offline   Reply With Quote

Old   October 12, 2011, 10:13
Default
  #14
Senior Member
 
Aram Amouzandeh
Join Date: Mar 2009
Location: Vienna, Vienna, Austria
Posts: 184
Rep Power: 8
mabinty is on a distinguished road
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
File Type: gz chtMultiRegionFoamRadBC.gz (18.4 KB, 10 views)
mabinty is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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


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


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