Rotation boundary condition

Submitted by evansmuts on Wed, 03/02/2011 - 11:39

Hi All

I would like to create a rotating boundary condition for the STL geometry similar to the "conveyor" option in the mesh/gran fix, i.e. the wall will simulate rotational motion, not just translational motion. The current conveyor option does not allow for when the geometry "bends back on itself" as in the case of a circular geometry. Therefore all the particles move to one side, instead of circulating around in a circle. I am aware that there is an option to rotate the STL geometry with the "move/mesh/gran" fix, but this is computationally expensive and is unneccessary if the geometry does not need to be rotated (I have a smooth cylinder that I want to rotate).

The reason I am posting on the forum is to get comment on the code that I have written. As far as I can tell the code should work correctly (and is formatted similar to the conveyor code), but it produces no movement of the particles when I use it. Can anyone comment on my method, or give insight as to where I have gone wrong?

I have attached my versions of the "fix_meshGran.cpp" and "stl_tri.cpp" files which seem to handle to conveyor motion (they have been renamed to .txt so that I could upload them). The major changes to the files are on lines 123-136 in "fix_meshGran.cpp" and lines 165-198 in "stl_tri.cpp".

Thanks

Evan

AttachmentSize
Plain text icon fix_meshGran.txt15.91 KB
Plain text icon stl_tri.txt10.82 KB

Forums:

ckloss_ | Thu, 03/03/2011 - 02:51

Hi Evan,

this feature is actually a good idea, and I think it would be useful to other users too...

I had a look at your code and it looks fine to me. The only thing I noticed is that rescaling (line 193 of stl_tri) should be performed using the magnitude of the tangential velocity instead of rot_omega?

regards,
Christoph

evansmuts | Thu, 03/03/2011 - 12:41

Hi Christoph

You are correct, that does make more sense than what I had (tangential velocity instead of rot_omega).

Unfortunately that does not solve my problem. My particles still don't seem to be influenced by a moving wall. When I use "move/mesh/gran rotate" with the same rotational speed the movement of the particles is very noticeable. Could it be that my implementation is not correct and the value of v_node is either being overwritten somewhere to make it zero? Or is the value not being processed/registered by the programme (i.e. it doesn't "see" the wall velocity)? I have already added the necessary variables to the "stl_tri.h" file, but couldn't see anything important in the "fix_mesh_gran.h" file. Are there any other places that get affected by the "conveyor" class?

Regards
Evan

ckloss_ | Thu, 03/03/2011 - 16:48

Ah, I forgot... Look at line 691 in fix_wall_gran.cpp. If you add a similar statement for "rotate", then it will be fine

Best ,
Christoph

evansmuts | Fri, 03/04/2011 - 12:15

Ah, I must have missed that because I was using version 1.1.10 while I was coding. The "fix_wall_gran.cpp" file has virtually no code inside it in version 1.1.10. That file in the development version (1.2.6) has a lot more code in it. After adding a line for the rotation option, everything worked fine.

I think I will stick to the development version (1.2.6) from now on.

I have also changed the order of the input variables so that they match the order of the "move/mesh/gran rotate" command. I have also added a negative sign to the omega in the calculation so that the direction of the rotation matches the move/mesh/gran version as well (should have put it in there earlier).

When using my rotation command, I have noticed that the movement of the particles seems a bit slower than for the move/mesh/gran version. I am busy looking into this to see where the difference is coming from.

Thanks again for your help Christoph.

Evan

ckloss_ | Sat, 03/05/2011 - 04:46

I had an idea about the difference between the move/mesh gran simulation and the "rotate" simulation.
Maybe this is due to the fact that the cylinder is discretized, and this imposes a bit of (artificial) geometric constraint. So when you actually move the mesh, this constraint will also move and therefore tend to speed up the outermost layer to match the wall velocity. Whereas in the case of "rotate", the opposite takes place, and particle motion will be slightly hindered. But that's how numerics work, we will never obtain a 100% solution :-)
What difference (say in % of tangential velocity) do you see?

Christoph

evansmuts | Tue, 03/22/2011 - 16:51

Hi Christoph

Sorry for taking so long to comment on this, but I got sidetracked on something else.

I looked at the wall velocities calculated my rotation procedure (stl_tri.cpp lines 170 - 200) and the move/mesh/gran procedure (lines 540 - 580). They are calculated very differently, but in general they give very similar results, within 4% of each other. To do this I compared the "v_node" values from my rotation procedure, and the "v" values from the "move/mesh/gran rotate" procedure. I assume that "v" is the wall velocity resulting from by the movement of the STL geometry.

Even though the values agree in general, I get some strange results from move/mesh/gran. I find that amongst the "normal" expected velocity values, I get many extremely large values as well, about 100 times larger than they should be. I find a similar trend in the "x" variable, with corresponding "x" and "v" values being either normal or extremely large. I think it is the occasional "high velocity spots" that could be increasing the speed of the particles as the travel around.

My first question is, why is the "v" array much larger than the "v_node" array? It is about 11/3 times bigger. Do these variables not represent the same thing? Have I compared the wrong variables? Is "v_node" the velocity of the wall face, and "v" the velocity of each node?

There seems to be a recurring pattern of large values in the "x"/"v" arrays. Could this mean that the error comes from a bad (coarse) STL file? I tried a finer STL file, but that did not make any difference.

Any comments would be appreciated, but for now I will use my own procedure as there are less unknowns (and it is quicker).

Evan

ckloss's picture

ckloss | Wed, 03/23/2011 - 21:12

Well, good questions... Firstly, have you updated to 1.2.7? Unfortunately a bug slipped in in 1.2.6 that might have caused what you describe.

Secondly, note v_node is of type double ***, and x,v are of type double **. So the velocity vecotr of type double* for tri i, node j would be v_node[i][j] or v[i*3+j]. Have you accounted for that?

Christoph

evansmuts | Mon, 03/28/2011 - 16:41

I have now upgraded to 1.2.7, but I still get the same values as before.

When I compared the velocity vectors, I have been comparing v_node[i][j][0] (and [1], [2]) with v[i*3+j][0] (and [1], [2]) as I have assumed v_node[i][j] = v[i*3+j] and the 0/1/2 represent x/y/z components. But this is were the problem comes in.

I have 192 triangles, with 3 nodes each. This means that v and v_node should both have 576 entries. However, v has 2112 entries. I am not sure where all these extra values come from and what they stand for. What are "nlocal" (in fix_move_tri.cpp) and "VECPERTRI" (stl_tri.h)? Does "VECPERTRI = 11" mean three vector components at 3 nodes and face centre? This would give me 192 * 11 = 2112 entries which I have, but then why the 0/1/2 entries for v if it already includes vector components?

I hope I am not bothering you with all these questions. I really just want to output the wall velocities that get passed on to the particles during contact as I believe these are the values I should be comparing. Are v_node and v the variables I should be looking at? If not, which ones are they?

ckloss's picture

ckloss | Wed, 03/30/2011 - 13:08

yes, you are looking at the right quantity.
sorry, my posting before was incorrect - see the STLtri::init_move() function how the pointers and quantities are connected.

Christoph

evansmuts | Thu, 04/14/2011 - 12:29

Hi Christoph

I compared the different velocity values and found them to be virtually identical. However, when I displayed the particle motion in paraview, the particles with "move/mesh/gran" still moved faster than with my rotation model. After looking more closely, I realised that the faster speed was not continuous as the particles would be speeded up in certain areas. I suspected these areas were where the shape of my STL geomtery was badly defined due to the coarse resolution of my geometry. This made me try a much finer STL geometry. I found that the particles now moved at similar speeds when comparing the two methods (move/mesh/gran and my rotation code).

So, as far as I can tell, the majority of the discrepancy is probably due to a rough (not perfectly) circular surface causing the particles to speed up in places because the faces were not accurate enough. The particle motion when using my rotation code was the same for both the coarse and fine STL mesh.

This explanation seems plausible to me, so I hope it is the end of of this issue.

Thanks for all your help.

Evan

renekaiser | Wed, 06/08/2011 - 12:05

Hello Evan,
may I have your liggghts modification, because I need a rotating cylinder, too. you It would be great if you put the code files in the forumlike in your first post.

Rene