[vitors]

Hello all,

I've been studying swak4foam and groovyBC source codes in order to implement a boundary condition in which I define a non-uniform profile in my patch.

I did it using groovyBC and it works. Since I need this feature coded in a BC, I am trying to the same as groovyBC implementation. But I'm stucked in PatchValueExpressionDriverI.H file trying to figure out how the PatchResultExpressionDriver::evaluate method works.

My question: after evaluating the expression, how (and where) groovyBC creates a patch with the calculated values and write it in the boundary condition?

Thanks,

Vitor

[gschaider]

Originally Posted by vitors

Hello all,

I've been studying swak4foam and groovyBC source codes in order to implement a boundary condition in which I define a non-uniform profile in my patch.

I did it using groovyBC and it works. Since I need this feature coded in a BC, I am trying to the same as groovyBC implementation. But I'm stucked in PatchValueExpressionDriverI.H file trying to figure out how the PatchResultExpressionDriver::evaluate method works.

My question: after evaluating the expression, how (and where) groovyBC creates a patch with the calculated values and write it in the boundary condition?

Thanks,

Vitor

Don't think that the swak-stuff is the best place to learn how boundary conditions are being implemented because there is a lot of other stuff around it.

But the actual setting of the boundary condition (as in all BCs) happens in the updateCoeffs-method of the groovyBCFvPatchField

[vitors]

Thanks for your reply.

But I think now I'm in trouble... I came to patchValueExpressionDriver because groovyBCFvPatchField::updateCoeffs() encapsulates its work doing:

this->refValue() = driver_.evaluate<type>(this->valueExpression_);

Since driver_ is a PatchValueExpressionDriver I saw no other way.

It's still a mystery for me how to be able to set a direction (like z) in my patch independent of its surface is structured or not. I'll keep seeking into the source code to realize, after parsing for example cos(pos().z), the cos function results are set into the patch.

ANY suggestions are welcome.

And thanks for your very fast reply!

[gschaider]

Originally Posted by vitors

Thanks for your reply.

But I think now I'm in trouble... I came to patchValueExpressionDriver because groovyBCFvPatchField::updateCoeffs() encapsulates its work doing:

this->refValue() = driver_.evaluate<type>(this->valueExpression_);

Since driver_ is a PatchValueExpressionDriver I saw no other way.

It's still a mystery for me how to be able to set a direction (like z) in my patch independent of its surface is structured or not. I'll keep seeking into the source code to realize, after parsing for example cos(pos().z), the cos function results are set into the patch.

ANY suggestions are welcome.

And thanks for your very fast reply!

If you want to understand the OF-side of things (and that is what you said you want to understand) it is sufficient to understand that the refValue on the left hand side is set to a specific value. That value is a Field<Type> of exactly the right size (size of the patch). Then these values are used to set up the matrix correctly (that is done by calling the updateCoeffs of the superclass). Where the values come from depends on the implementation of the BC. With groovyBC that implementation is a bit more complicated than in the "usual" BCs so I'd recommend looking there

[vitors]

Originally Posted by gschaider

If you want to understand the OF-side of things (and that is what you said you want to understand) it is sufficient to understand that the refValue on the left hand side is set to a specific value. That value is a Field<Type> of exactly the right size (size of the patch). Then these values are used to set up the matrix correctly (that is done by calling the updateCoeffs of the superclass). Where the values come from depends on the implementation of the BC. With groovyBC that implementation is a bit more complicated than in the "usual" BCs so I'd recommend looking there

Thanks Bernhard. You got my point. I want to know how to set a profile function in a specific direction of my patch. Basically, I want to know how to set matrix values correctly since I don't know how to manipulate the data strucutures from a fvPatch to a fvField.

I'm trying to check how this is done in groovyBC and my start point is: after parsing the expression value (I'm not interested in the parsing itself), how groovyBC come from an expression like

cos(pos().z)

and sets the profile in the patch. My guess is check how thinks are done in CommonValueExpressionDriver, PatchResult, PatchValueExpressionDriver and GroovyBCFvPatchField.

Thanks for you valuable comments. I feel more confident I'm going in the right way. I'll let you know about my progress (probably you'll see more questions here before this progress I think...).

Regards,

Vitor

[gschaider]

Originally Posted by vitors

Thanks Bernhard. You got my point. I want to know how to set a profile function in a specific direction of my patch. Basically, I want to know how to set matrix values correctly since I don't know how to manipulate the data strucutures from a fvPatch to a fvField.

I'm trying to check how this is done in groovyBC and my start point is: after parsing the expression value (I'm not interested in the parsing itself), how groovyBC come from an expression like

cos(pos().z)

and sets the profile in the patch. My guess is check how thinks are done in CommonValueExpressionDriver, PatchResult, PatchValueExpressionDriver and GroovyBCFvPatchField.

Thanks for you valuable comments. I feel more confident I'm going in the right way. I'll let you know about my progress (probably you'll see more questions here before this progress I think...).

I think you're looking at a much too complicated thing: for examples on assembling a Field to assign to the refValue (and similar) have a look at totalPressure or other BCs in $FOAM_SRC/finiteVolume/fields/fvPatch/derived

In order to be flexible groovyBC does certain things in a way that is more complicated than is necessary if you want to write your own hardcoded BCs. And understanding all these details is only necessary if you want to write a better version of the swak-parsers

[vitors]

Originally Posted by gschaider

I think you're looking at a much too complicated thing: for examples on assembling a Field to assign to the refValue (and similar) have a look at totalPressure or other BCs in $FOAM_SRC/finiteVolume/fields/fvPatch/derived

In order to be flexible groovyBC does certain things in a way that is more complicated than is necessary if you want to write your own hardcoded BCs. And understanding all these details is only necessary if you want to write a better version of the swak-parsers

Thanks for the pointers Bernhard.

I've been through many different OpenFOAM BC's. But for some simple questions it's difficult to find answers. Answers which make things much simpler. For example, I took I lot of time to realize that I can use a fixedGradient class for my problem instead of more complex like mixed. (I hope, at least...)

I'll check totalPressure.

For instance, I found no way to initialize my patch values (or gradients) in a function profile correctly without doing it hard-coded. Moreover, since I'm trying to implement a very particular boundary condition simulating a fuel rod I don't want to leave more than the heat flux specification to the potential users of my BC.

One more time, thanks again for your comments.

Regards,

Vitor