orientedType

simrego · January 26, 2021, 12:22

Dear OF users!

Could you explain me what is the purpose of this class?
https://www.openfoam.com/documentati...entedType.html
I have tried to figure out, but to be honest I have no clue why is it good for, what it does, etc..

Thanks!

olesen · January 26, 2021, 14:07

Can't remember when, but was answered recently on the forum (maybe even by me)

simrego · January 26, 2021, 14:28

Thanks, google usually finds it but now it did not...

Your answer was:

Quote:

You can have a scalar face field (eg, concentration, temperature) where the face orientation is irrelevant - the scalar remains a scalar. Other scalar face fields (eg, phi) depend on the face orientation.

But it is still not clear for me why is it useful. In your example you are using phi as an example. If I'm correct you mean that the direction of phi is questionable (in-, or outwards).
But in case of phi as the flux (or it is not flux in this example?), it's sign will tells you if it points in the face normal direction or in the other direction. So for me it seems like "oriented_" is a redundant value.

EDIT: So if it is unoriented, then it is useless? Or what happens then?

simrego · January 26, 2021, 14:52

So after some "what the hell is happening" moment I think I've got an idea which still makes no sense to me.
Assume that I have to do something with a surface field which is given from someone. Then I can check if this field is oriented or not. Then I'll know it depends on the face orientation. Okay. And?

If I have the general rule that every surface field must point in the face normal direction (it is weird to think about a scalar pointing in a direction but I hope you understand what I mean), then this whole "orientedType" checking is pointless. I have to take care of this rule during the field construction so later I won't have headache. But in this case I still have to take care since I have to set the oriented_ value which means I could also orient the field.
And for example with phi. You interpolate the velocity, multiply with rho*Sf and your surface field is oriented immediately.
And still don't know what to do with the unoriented information. Stick with the flux example. I get a flux which is unoriented. Okay, then I must know if only some of it's values are unoriented, or all of them. Without this knowledge I can't use this field which means that I can't use any unoriented field.

I'm really trying to find some meaning for this class but I can't...

olesen · January 29, 2021, 03:41

Quote:

Originally Posted by simrego

If I have the general rule that every surface field must point in the face normal direction (it is weird to think about a scalar pointing in a direction but I hope you understand what I mean), then this whole "orientedType" checking is pointless.

That is the whole point though. You have a scalar like concentration or temperature, which is UNORIENTED - ie, completely independent of the face orientation. And you have a scalar such as phi which is ORIENTED.

Now suppose you split a cell into two cells. Assuming we retain the original cell id for one part of the cell, but the second part of the cell gets a new cell id at the end of the list (ie, id == nCells_old). With the face orientation rules, the cell points _outwards_ from owner to neighbour. For the split face, part 1 of the face keeps its orientation but part 2 of the face will be flipped, since the newly generated cell has a higher number than its neighbour. Existing ORIENTED surface fields may now need adjustment to change their sign, otherwise phi (flux) would be wrong.

Quote:

Originally Posted by simrego

I'm really trying to find some meaning for this class but I can't...

It's not the class, but a concept of how its used that gives it the meaning. The "class" isn't much more than an enumeration.

simrego · January 29, 2021, 04:27

I see now, but I still don't think if this class is really needed, but I guess that this is a "nice to have" safety feature. This whole stuff could be done during the mapping (I'm not sure if I have seen any surface-to-surface mapping yet where this class can be used) from the old to the new mesh or for example as I see phi is recalculated right after the mesh motion in *DyM* solvers which makes this class useless there.
But I believe you that it can be helpful in some cases.

Thank you for the clarification!

January 26, 2021, 12:22	orientedType	#1
simrego Senior Member anonymous Join Date: Jan 2016 Posts: 416 Rep Power: 14	Dear OF users! Could you explain me what is the purpose of this class? https://www.openfoam.com/documentati...entedType.html I have tried to figure out, but to be honest I have no clue why is it good for, what it does, etc.. Thanks!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Class orientedType	Jesper_Roland	OpenFOAM Programming & Development	1	November 4, 2020 10:57

January 26, 2021, 14:07		#2
olesen Senior Member Mark Olesen Join Date: Mar 2009 Location: https://olesenm.github.io/ Posts: 1,695 Rep Power: 40	Can't remember when, but was answered recently on the forum (maybe even by me)

January 26, 2021, 14:52		#4
simrego Senior Member anonymous Join Date: Jan 2016 Posts: 416 Rep Power: 14	So after some "what the hell is happening" moment I think I've got an idea which still makes no sense to me. Assume that I have to do something with a surface field which is given from someone. Then I can check if this field is oriented or not. Then I'll know it depends on the face orientation. Okay. And? If I have the general rule that every surface field must point in the face normal direction (it is weird to think about a scalar pointing in a direction but I hope you understand what I mean), then this whole "orientedType" checking is pointless. I have to take care of this rule during the field construction so later I won't have headache. But in this case I still have to take care since I have to set the oriented_ value which means I could also orient the field. And for example with phi. You interpolate the velocity, multiply with rho*Sf and your surface field is oriented immediately. And still don't know what to do with the unoriented information. Stick with the flux example. I get a flux which is unoriented. Okay, then I must know if only some of it's values are unoriented, or all of them. Without this knowledge I can't use this field which means that I can't use any unoriented field. I'm really trying to find some meaning for this class but I can't...

January 29, 2021, 04:27		#6
simrego Senior Member anonymous Join Date: Jan 2016 Posts: 416 Rep Power: 14	I see now, but I still don't think if this class is really needed, but I guess that this is a "nice to have" safety feature. This whole stuff could be done during the mapping (I'm not sure if I have seen any surface-to-surface mapping yet where this class can be used) from the old to the new mesh or for example as I see phi is recalculated right after the mesh motion in DyM solvers which makes this class useless there. But I believe you that it can be helpful in some cases. Thank you for the clarification!