nuEff()()[patchI] and nuEff()
 

Dear all,

I have a simple question about the following. In the fixedShearStress BC we find this:
As far as I understand it, turbModel.nuEff()()[patchI] should return the values of each face at the patch [patchI]. Therefore the scalarField nuEff should have a size of the nFaces.

At least nuEff is empty:

If I output the nuEff() field like that:
I get the list of all boundary's. So far so good. But the access to the patchI is somehow destroyed.

If I use this one, that is exactly the same, I get some complete different values:
And if I output it directly I get:
In a programming point of view this makes not real sense to me (especially the first two):

Okay there are differences but the field "turbModel.nuEff()()[patchI]" has to be the same as "turbModel.nuEff()()[patch().index()]".

At least the BC will fail because we use nuEff to divide:
Any advice?


Finally, if we output the turbModel.nuEff() we get the correct values:

I also made a bug report now because it seems really strange. http://openfoam.org/mantisbt/view.php?id=2020

Hi,

Maybe I am missing something but, turbulenceModel::nuEff() returns tmp<volScalarField>, so nuEff()() (http://foam.sourceforge.net/docs/cpp...2d975c8876d3d6) is volScalarField and nuEff()()[index] should be scalar.

Yet there is turbulenceModel::nuEff(label patchI), which returns viscosity on a patch.

Could you post whole code snippet (so it could be compiled and tested)?

Hey Bruno,

thanks for the reference about ()() ... here is the link to the file.
If you are correct and ()()[patchI] returns a scalar, why we use a scalarField nuEff than and can you tell me what scalar is returned? Mean value of the patch or sth. like that?

http://www.openfoam.com/documentatio...36_source.html

Hi,

Not quite Bruno, but OK ;)

Do you talk about line 112 of fixedShearStressFvPatchVectorField.C? It uses turbulenceModel::nuEff(label patchI), which returns tmp<scalarField> (http://www.openfoam.com/documentatio...4f85f6644d2d6a).

Aaa its version 3.0 Here it the file I was talking about...

As I read
it is that i have a scalarField with the size of faces and each field stores one face value, am I right?

You have scalarField with the size of the patch and it is has scalar for each face value.

Though BC uses this - turbModel.nuEff()()[patchI] - strange construction, turbulenceModel class has nuEff(label patchI) method even in 2.3.1.

Hi,

Henry changed it: https://github.com/OpenFOAM/OpenFOAM...1fe57e8a140c7c

For 3.0.x it is working now but for 2.3.1 I get an error if I use the code you (or henry) mentioned:
So at last, there is no method for nuEff(label)

Hi,

Even in 2.3.1 there are two types of turbulence models ones in src/turbulenceModels and another in src/TurbulenceModels (surprise, surprise). First type does not have nuEff(const label), second type has it and for RASModel it is implemented as:

nu(patchi) is implemented as (example from Newtonian.H):

nut(patchi) is implemented as (example from eddyViscosity.H):

so your (well, OpenFOAM's) quite frightening

could be in fact

Or you can use transportModel's ability to return nu for a given patch using

so it would be

Hi,

I will try it tomorrow but today I tried it with boundaryField() without success. Maybe I made a simple mistake. Thanks in advance.

I think there might also be problems with memory management. You receive a tmp<volScalarField> without storing it, and only access the boundary. I had a similar issue before and for me it helped to initialize a copy of the volScalarField before accessing the patch values like this:

volScalarField copy(turb->nuEff());

Afterwards you can use the boundaries of the copied field without worrying about the scope of the classes contained in the temporary object. In my case I even regarded it as a bug or atleast a design error.

Hey,

thanks for the hint. At last the code has to be:
I think I will also make a copy (:

strange things explained
 

Hello Tobi.
First thanks for your tuto and videos. Good job which could help some people and help OF to be more widely used than it is:)

For your problem described here, Alexeym gave you good answer (using turbModel.nuEf()().boundaryField()[patchI]).

To complete the post, I can give you some answers to the "strange" things you have mentioned in your first post. All things are related to the fact that turbModel.nuEff()()[patchI] (which is clearly a bug) is a scalar as mentioned by alexeym.

A) What happens is the following:
scalarField nuEff
--> create a scalarField of size 0
nuEff = turbModel.nuEff()()[patchI]
--> it is the UList<Type>::operator =(Type& v) (with Type=scalar) which assign all values of the List to v. But do nothing here since nuEff is of size 0! So nuEff is still empty list and Info << nuEff gives 0().

B) Other thing: your "scalarField nuEff2(turbmodel.nuEff()()[patchI])"...
In fact, you try to construct a scalarField with a constructor scalarField (scalar& v)
But this constructor doesn't exist...
You have scalarField(label i, scalar v) (build a scalarField of size i and all values equal v) but clearly it is not this one you use. In fact, you use the base constructor scalarField(label i) which construct a scalarField of size i and no prescribed values (so compiler dependant / something like VSMALL for most compilers). And what is your i? The integer part of the scalar turbModel.nuEff()()[patchI] (124 for your example).

These things explain what you have seen.

Dear Thomas,

thanks for completing the topic and the feedback to my webpage. I am familiar with c++ but the error reported here was from a collegue in the german openfoam forum, that I just investigated during other investigations (: So at last I wanted to report you the bug, learn new things (thanks to you and Alexeym) but I did not investigate into the code deeply and of course I am not a FOAM - code expert (what function will return what or what is doing that). Its good that there are people like you that will clear the questions.

So just one question. If I will create my scalarField nuEff with the size of the real field (lets say 200), and use
will it work? I could test it but its 01:32 a.m. and I am too tierd (:

Nice dreams,

Well if you write:

"
scalarField nuEff(200) // create a scalarField with size 200 (not yet inialized here)
....
nuEff = turbModel.nuEff()()[patchI] // assign all values of the scalarField as equal to the scalar on the right; comes from UList::operator =(scalar &v); doesn't change the size of the container as said in th previous post
"

at end, all the 200 values of the nuEff list will be equal to the same scalar value turbModel.nuEff()()[patchI]. It takes sense from informatic point of view but it is clearly not what you want I think. You should prefer the scalarField nuEff being equal to the scalarField turbModel.nuEff()().boundaryField()[patchI]. For this, you must use alexeym correct expression:

"
scalarField nuEff // create zero sized List (size doesn't matter here -- see later)
nuEff = turbModel.nuEff()().boundaryField()[patchI] // it is the UList::operator =(UList& f) function. This function resizes the calling list (nuEff here) to the size of the called one (f in the prototype / turbModel..... in the example -- this is why the instanciation of nuEff as a zero sized list doesn't matter) and equals the values.
"

Hi
I have a problem with nuEff() because as you said it creates list with size zero.

How to force nuEff() to create a list of mesh size?

Basically I overriden nu() to return my volScalarField.
And Now I get the error in nuEff() = this->nut() + this->nu()
that nut() returns zero size list and nu() returns the size equal to e.g. 1400
So the sizes are not equal during summation.

So I am wondering how to force nut() to return the same list size as nu()??

Hi
In the RASModel.H we have a function nuEff()
I have overriden nu() as
where dynamicVisc is a volScalarField and density is a dimensionedScalar.

When in the UEqn.H I have a code
nuEff() is run and it sums nut() and nu(). However there is an error because nut() returns zero size list and nu() returns non zero size list (it is equal to the mesh size).

How can I change the code to nut() returns also mesh size list?

Hi
I found how to solve the problem.
I had something like this
It compiled however during calculation I got errors like:
where Helium is my viscosityModel.

When I changed the nuCalc() function like this:

everything works well (at least solver runs). In my code eta_ is a volScalarField and rho_ is a dimensionedScalar.

Can anybody explain why this second solution works and the first doesn't?

Can you tell us how you access the field nuHelium() in your solver.

Hi Tobi,
I have a class that derives from singlePhaseTransportModel class.
Inside this class is a pointer to viscosity model. This pointer was private and now I changed it into protected to be able to use it. So I have an access to viscosity model and nu is calculated inside helium viscosity model class as shown in my previous post.

Okay, and how do you access the function? I mean, you should have something like that somewhere:

Actually I am interested in that line you should have somewhere (I guess in another form).

yes it is inside singlePhaseTransportModel
you can see it in doxygen. I changed only private to protected for viscosityModelPtr_.

Why are you asking?

Hi, actually I ment something different but it does not matter. I guess I know the answer to your question:

This code should be not working based on the fact that the object nu will be destroyed after the return statement. The returned tmp<> pointer points to a non-allocated memory address and thus you should get a run time error. However, your second example is working because you are returning the object returned by the max() function. The max() function will build a tmp<> object that will not be destroyed and thus, the object survives after returning.


To get your first approach running, this should be done:

Here, you build the tmp object which knows how many pointers point on the object. If you return it, you have to store the returned object in a tmp<> object again, in order to keep the object alive. After the end of calcNu() is reached, the returned tmp<> object survives and you should not get an run time error.

I hope I formulated it in a good way :) ...

This will work:
This will fail:

Hi Tobi,
Thank you very much for explanation, now it is clear for me.

Unfortunately I still have an error with nuEff() function.
This function is run in the line
in the UEqn.H. I have this error now
It results from that nuEff = nut() + nu() and nut() is size of zero and I do not know why.

There are too less information on what you changed. So it is not possible to give any advice, sorry.

Ok I found the origin of the error. I had the code in UEqn.H
If I comment the line
everything works well, but I do not know why???

How did you define your object nut. Can you give the definition of that object? And where do you use nut afterwards?

nut definition in createFields.H:

and I do not use it before line nut = turbulence->nut();

This cannot work because turbulence->nut() will return a tmp<> object which will be destoyed in your case :). So build your own field such as:

then you should get access to the field such as:
Or simply use:
without creating a volScalarField in the createFields.H

This should be corrected a little bit:
To my understanding it is essential that the object of volScalarField type is to be created in dynamic memory (on the heap) with operator new. If so, tmp can store a pointer to some place in dynamic memory which will stay untouched while tmp is returned from calcNu. On the other hand, when you initialize tmp with a pointer/reference to an automatic object (i.e., in simple words, you don't use operator new to create an object) tmp stores a pointer to a place in automatic memory (on the stack) which will be "erased" as soon as you return from calcNu and it yields undefinite behaviour.

Is is like that? I don't think so because the tmp<> class knows how much pointer points to the object. Therefore, if one returns the object such as:
while taking the returned pointer such as:
The object should be still alive, even if we leave the calcNu() function because a pointer still points onto the object. But out of the box I cannot proof that. Bruno told me once the following:

Any automatic object created within the body of a function can live untill the execution flow leaves the function. Then a destructor of the object is invoked rendering the object basically dead. A pointer to the automatic object can be incapsulated into a smart pointer object and returned from the function, but it will be useless anyway because the object it points to is dead. If you want an object to stay alive when the execution flow leaves the function you should create it with operator new as a dynamically allocated memory object.

Hmmm,.... actually without the new keyword it is not working at all based on the fact that the pointer has to point to an explicit allocated memory build by new. So you are right. Thanks for correcting me. For those who want to test it:

Hi, Tobias
Are you sure this piece of code issues an error? I didn't try it personally, but I believe it should be ok. myCalc returns a temporary object which is assigned to a const reference foo. And c++ rules make it possible: a constant reference can be "initialized" with a temporary object. The temporary object doesn't die right away, it's lifetime prolongates up to the constant reference lifetime. And they both will live untill the execution flow leaves the scope where the constant reference was defined. This code might not work for one reason though: myCalc returns tmp and foo expects volScalarField, I am not sure tmp can "converts" to volScalarField implicitly. If you do the conversion explicitly (with operator()) it should work like a breeze:

Hi,

yes it will give an runtime error. If one test the above code, the error appears. I was struggling about that in my openComfort library too because here I need access to the nut field which comes from the turbulence model. Right at the beginning I did this one:
However, this code failed always. Therefore, I replaced it with a copy operator which worked (obviously):
I was not happy about copying the object and asked Bruno. He gave me the explanation, that we have to keep a object of the tmp<> class alive by doing that:
Otherwise the object returned by the nut() function will be destroyed. You might be right that it will work with smart pointers like the auto_ptr in c++ but with the FOAM tmp<> class actually not (tested it).

Hopefully I could test it tomorrow and then get back to this thread.

I played around with the code and have to confirm that
fails at runtime. You have to use a pair of round brackets at the end of this expression to obtain (a reference to) volScalarField out of tmp. Otherwise it won't even compile let alone run.

Hmmm.... :/
Sure, it is obvious now.
After the operator () we have access to the object and can take the reference. My way was wrong. Should think more before I reply.

As always Sergei. Good point. Thanks for sharing.

Hi Tobi and Zeppo
Thank you guys for explanation all of these things and help. I solved my problem mentioned in #25.
It was caused by the bed use of tmp object.

I fixed the code according Zeppo solution as in the citation.
Also I added this line according to Tobi:
Thank's for sharing :)