CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   how to manipulate pointMotionU or pointdisplacement when running (https://www.cfd-online.com/Forums/openfoam-programming-development/122835-how-manipulate-pointmotionu-pointdisplacement-when-running.html)

cctv August 29, 2013 04:32

how to manipulate pointMotionU or pointdisplacement when running
 
Hi
Does anyone who knows how to manipulate pointMotionU file or pointdisplacement file when running in openfoam 2.1+? I mean if there is a way to change the speed of dynamic mesh according to the solution in openfoam 2.1+. Thanks.

fredo490 August 30, 2013 05:30

I put my code on this topic few day ago: http://www.cfd-online.com/Forums/ope...tml#post447947

Enjoy ;)

cctv August 30, 2013 16:36

Quote:

Originally Posted by fredo490 (Post 448865)
I put my code on this topic few day ago: http://www.cfd-online.com/Forums/ope...tml#post447947

Enjoy ;)

Yes, I have seen it ,and it is very useful. In addition, I am not quite sure about the meaning of pointNormal.Could you explain it briefly?
Thanks
Yu

fredo490 August 30, 2013 17:29

"pointNormal" is a function that returns a vector that is defined as the "normal direction at the node".

The problem here is to give the direction of the motion (the code can only moves nodes, not edges or faces). First you need to understand that each face has a "normal vector" that is defined at the center of the face. Then, you can understand the "pointnormal" as an average of the neigbours faces normal.

For example, if you are in 2D and that you have 2 faces: One face is vertical (its normal vector is then horizontal) and another is horizontal (its normal vector is vertical). The "pointNormal" would be a unit vector that is at 45 degrees (average of 0° and 90°).

Hope you get it ;)

cctv August 31, 2013 05:52

Quote:

Originally Posted by fredo490 (Post 448970)
"pointNormal" is a function that returns a vector that is defined as the "normal direction at the node".

The problem here is to give the direction of the motion (the code can only moves nodes, not edges or faces). First you need to understand that each face has a "normal vector" that is defined at the center of the face. Then, you can understand the "pointnormal" as an average of the neigbours faces normal.

For example, if you are in 2D and that you have 2 faces: One face is vertical (its normal vector is then horizontal) and another is horizontal (its normal vector is vertical). The "pointNormal" would be a unit vector that is at 45 degrees (average of 0° and 90°).

Hope you get it ;)

Thank you for your reply. I still have something unknown about it:
1. for 2D case, would the node on the most side own only one face? It seems to be so because I have printed them out ,and find the pointNormal for the node at the coner and for the internal node are the same.
2. I did an experince on a plane boundary yesterday, making half of the node on the boundary move at the same speed and the other half keep stable. In my opinion, only a few of nodes in the middle of the boundary should have an unusual pointNormal, others should be the same(e.g. (-1,0,0) for a vertical plane). However, the result is many of the are unusual. What's more , some of them did not only unnomalised, but also have a component of Z axis.(e.g. PointNormalVector.size(): 42
index0: (-1 1.57209e-15 2.35099e-32)), which confused me a lot.
Have you ever notice these thing? and have you got the answer?
Thanks

fredo490 September 1, 2013 14:38

Well, the best thing you can do is to export each step and to visualize it with paraview for example (you can really see the motion).

For your "strange" point: -1 1.57209e-15 2.35099e-32
you are talking about 2 time 10 power -32 that is 0.0000000000000000000000000000000235099 to be exact. In other words, it is a "computer mistake" that doesn't define exactly zero. There is nothing strange in this if you take a look at a computer architecture ;)

cctv September 2, 2013 04:24

Quote:

Originally Posted by fredo490 (Post 449240)
Well, the best thing you can do is to export each step and to visualize it with paraview for example (you can really see the motion).

For your "strange" point: -1 1.57209e-15 2.35099e-32
you are talking about 2 time 10 power -32 that is 0.0000000000000000000000000000000235099 to be exact. In other words, it is a "computer mistake" that doesn't define exactly zero. There is nothing strange in this if you take a look at a computer architecture ;)

OK,well, for another thing,could your code run parallelly? I have a simple test and seems not. and so you know how to set frozen points zone? thanks.

fredo490 September 6, 2013 08:54

The code can run in parallel under certain conditions... The main problem is when the deforming boundary belong to 2 (or more) domains. The node at the interface might have a strange behavior. But if your boundary belong to a single domain, everything should be ok.

cctv September 6, 2013 11:41

Quote:

Originally Posted by fredo490 (Post 450214)
The code can run in parallel under certain conditions... The main problem is when the deforming boundary belong to 2 (or more) domains. The node at the interface might have a strange behavior. But if your boundary belong to a single domain, everything should be ok.

Have you tried this yet? I found my case did not work whatever I decompose it. In my case, not all the nodes at the boundary move at the same speed.

fredo490 September 7, 2013 06:17

I tried few cases but I didn't really care about it since I had to run my simulation with 1 cpu for some other reasons. I mainly found that it is the interface between two domains that start to mess up.

You can try to export each time step and read the value in the pointdisplacement file.


Anyway, running a deforming mesh in parallel is always hard, even in Fluent :rolleyes:

cctv September 7, 2013 06:58

Quote:

Originally Posted by fredo490 (Post 450341)
I tried few cases but I didn't really care about it since I had to run my simulation with 1 cpu for some other reasons. I mainly found that it is the interface between two domains that start to mess up.

You can try to export each time step and read the value in the pointdisplacement file.


Anyway, running a deforming mesh in parallel is always hard, even in Fluent :rolleyes:

Thank you very much. I would try it latter.

cctv September 11, 2013 12:49

Quote:

Originally Posted by fredo490 (Post 450341)
I tried few cases but I didn't really care about it since I had to run my simulation with 1 cpu for some other reasons. I mainly found that it is the interface between two domains that start to mess up.

You can try to export each time step and read the value in the pointdisplacement file.


Anyway, running a deforming mesh in parallel is always hard, even in Fluent :rolleyes:

I had a try on parallel computing and found that using pointMotionU could work and using pointdisplacement doesn't, what's your result?

fredo490 September 11, 2013 13:28

I haven't been able to run any test yet. I am currently working on another project that takes 200% of my time.

I have to say that your notice is quite interesting ! Maybe the programmers only made half of the work by optimizing the pointMotionU concept and not the pointdisplacement.

It would be interesting to compare the codes.

ngj September 11, 2013 14:19

Hello,

I might add that I have been running into the same problems using deforming boundaries in OpenFoam-1.6-ext. I solved the problem by synchronising the point displacement/point velocity on the parallel boundaries prior to executing the mesh motion.

To be more specific, then I synchronised the values before I added them to the boundary patch(es) of my moving variable.

Kind regards

Niels

fredo490 September 11, 2013 15:05

Nice idea ! Would you mind posting the corresponding piece of code ?

cctv September 11, 2013 16:08

Quote:

Originally Posted by ngj (Post 451197)
Hello,

I might add that I have been running into the same problems using deforming boundaries in OpenFoam-1.6-ext. I solved the problem by synchronising the point displacement/point velocity on the parallel boundaries prior to executing the mesh motion.

To be more specific, then I synchronised the values before I added them to the boundary patch(es) of my moving variable.

Kind regards

Niels

Hi Niels:
I think my problem is not this. I implemented the deforming boundaries in OpenFoam-2.1.1, however, my work did not run even one processor did not contained the deforming boundary(two in total). I am not sure if there is something wrong in my work. I think version difference is not the problem because I have ever had a look at them and found they are the same. And I think you solution only solved the problem when the deforming boundary is located in several processors, am I right?

ngj September 11, 2013 16:57

Yes, my problem occurred, when multiple processors shared the same (moving) patch.

Kind regards,

Niels

cctv October 7, 2013 10:19

Quote:

Originally Posted by ngj (Post 451217)
Yes, my problem occurred, when multiple processors shared the same (moving) patch.

Kind regards,

Niels

Hi Niels:
Could you tell me what kind of solver for moving do you usually use. displacementLaplaceion,velocityComponentLaplacian. etc.
Thanks

ngj October 7, 2013 14:50

Hi Yu,

I am using the laplaceFaceDecomposition method, which is available in 1.6-ext.

Kind regards

Niels

cctv October 7, 2013 15:58

Quote:

Originally Posted by ngj (Post 455553)
Hi Yu,

I am using the laplaceFaceDecomposition method, which is available in 1.6-ext.

Kind regards

Niels

It seems that this solver did not exist in 2.1.0+? Did your codes similar to interTrackFoam when running them in parallel? Have you ever tried any other solver for motion in parallel? As far as I know, laplaceFaceDecomposition method is time-consuming as it would probablelly redraw the mesh?


All times are GMT -4. The time now is 09:27.