[mirko]

I don't understand the last couple of lines of updateCoeffs of
turbulentTemperatureRadCoupledMixedFvPatch

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

[wyldckat]

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:

   #include "mixedFvPatchFields.H"

   Nice, it's a click-able link!
4. On line 39 of that newly found file, you can see this:

   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:

   Definition at line 347 of file fvPatchField.H.

   That looks suspicious
9. OK, line 347 at fvPatchField.H is... this!?

   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

[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

[mirko]

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

[wyldckat]

Hi Mirko,

Mmm... if I saw this correctly, it's as simple as inheritance: the class

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

[mirko]

Thanks Bruno,

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

[wyldckat]

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:

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:

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

[mirko]

Originally Posted by wyldckat

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

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.

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

[wyldckat]

Hi Mirko,

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

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:

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

[mirko]

Thanks :-)

[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

[mirko]

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

[mabinty]

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]

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