
[Sponsors] 
August 4, 2005, 03:21 
Hello All
If it is not

#1 
New Member
Michael McWilliam
Join Date: Mar 2009
Location: Waterloo, Ontario, Canada
Posts: 5
Rep Power: 10 
Hello All
If it is not too inconvinient coud someone explaine to me what is going on in the slide function. I am sure I can figure it out, but any tips will help out. So I have three questions: Q1) At first glance the slide code seems simple enough. First you move the points, then you update the topology, By update topology you adjust all the numbering or feild data. Then you move the old points vector. You move the oldAllPoints because the simple mesh uses this pointer in moving points. Is this correct? Q2) fvMesh::updateTopology() calls polyMesh::updateTopology() however polyMesh::updateTopology() is a virtual function. As such it would then call fvMesh::updateTopology(). That would start an infinite loop? I can't seem to find where updateTopology() is actually defined. Any hint? Q3) When does polyMesh::morphing_ ever get reset? Below is the mixerMesh.slide() code for simple reference. mixerMesh::slide() { movePoints ( cs_.toGlobal(cs_.toLocal(allPoints()) + vector( 0, rpm_*360.0*time().deltaT().value()/60.0, 0)*movingPointsMask() ) ); updateTopology(); /** fvMesh updateTopology() Code *** // fvMesh inherits polyMesh if (morphing()) // polymesh function { // Have polyMesh do all topo changes polyMesh::updateTopology();//virtual polymesh function handleMorph(); // in fvMesh } ****************************/ if (morphing()) { deleteDemandDrivenData(movingPointsMaskPtr_); } movePoints ( cs_.toGlobal( cs_.toLocal(oldAllPoints())+ vector(0, rpm_*360.0*time().deltaT().value()/60.0, 0) * movingPointsMask() ) ); 

August 4, 2005, 04:13 
In short, the inner part of th

#2 
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,803
Rep Power: 24 
In short, the inner part of the mesh moves relative to the outer bit. In each position, it is necessary to reconnect them, such that there is only one face between the two cells.
The code therefore projects one sliding surface onto the other and performs a cutting algorithm, creating new points and facets. These are then inserted into the mesh instead of the original faces to create valid polyhedra. As you can see, this topological change leads to the change in the number of points and faces (others may also change the number of cells) and the solution needs to be mapped from the "old" mesh to the new one  hence the change in the numbering. The old points field is also renumbered and resized, which answers your first question. Thinking about the operation, the first mesh motion triggers the topological change  if you do not move the points, the topology will not need to change, This is followed by the topo change, while the second mesh motion allows the points to get to their "correct" positions (consider introducing cells with zero volume as required by the discretisation). Finally, polyMesh::morphing_ is a private member of polyMesh, used only internally to the class. Therefore you don't need to do anything about it. Enjoy, Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk 

September 19, 2006, 09:44 
I am wondering what I could be

#3 
New Member
Joseph Kummer
Join Date: Mar 2009
Location: Fayetteville, NY, USA
Posts: 17
Rep Power: 10 
I am wondering what I could be doing wrong, or if anyone else has had the same thing happen:
I ran the Mixer2D case, and I set the rpm to 60. The mixer, then, should do one complete rotation in 1 second (or 90 degrees in .25 sec). After 1/4 sec, however, the mixer rotated about 135 degrees, and after 1 second a little less than 1 1/2 rotations (1 rotation was completed in about 0.72 sec). I'm wondering if anyone has any ideas what I am doing wrong here? From the code quoted above: mixerMesh::slide() { movePoints ( cs_.toGlobal(cs_.toLocal(allPoints()) + vector( 0, rpm_*360.0*time().deltaT().value()/60.0, 0)*movingPointsMask() ) ); I am trying to understand how this works. Am I correct that rpm needs to be changed to rad/s? I was wondering if someone could please explain the calculation: rpm_*360.0*time().deltaT().value()/60.0? What is value()? Or is time().deltaT().value() all one variable? rpm/60 would be revolutions per sec. Times 360 would give degrees per sec. Any help would be appreciated. Thanks Joe Kummer 

September 19, 2006, 09:54 
Not far: rpm stand for "revolu

#4 
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,803
Rep Power: 24 
Not far: rpm stand for "revolutions per minute", right. For the rest, 560 is the number of seconds in a minute and 360 is a number of degrees in a full circle.
Better? Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk 

September 19, 2006, 10:33 
I agree, rpm*360.0/60.0 would

#5 
New Member
Joseph Kummer
Join Date: Mar 2009
Location: Fayetteville, NY, USA
Posts: 17
Rep Power: 10 
I agree, rpm*360.0/60.0 would then have units of degrees per second. This times deltaT would give you number of degrees.
So is the calculation rpm_*360.0*time().deltaT().value()/60.0" in the above expression computing the number of degrees that the mesh needs to be rotated? If this is the case, and the rest of your code works in degrees, then I guess I was wrong thinking it needed to be converted to rad/s. I'm still a little stumped, however, with the fact that my mesh is rotating at a different speed than I set as the rpm setting in the dynamicMeshDict file. Under mixerFxMeshCoeffs, there are three settings under corrdinateSystem: origin, axis, and direction. What is the direction here (currently set as 1 0 0, which would be in the radial direction)? Maybe I'm not setting this correctly? I'm sure I'm doing something wrong, since these routines have been tested by many other people. I'm excited that it works, though. After this, I would like to add in the turbulence model into the rotating mesh calculation, and then try to simulate the crossflow fan. I will be happy to post results and testcases on the website for others to try once I get it to work. Thank you very much. Joe Kummer 

September 19, 2006, 10:46 
Hi,
Coordinate system is a

#6 
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,803
Rep Power: 24 
Hi,
Coordinate system is a cylindrical one: origin you know, axis is the zaxis around wich the thing spins and direction is the "x" thingy from which you measure rotation in degrees  in other words, at x you have zero degrees rotation. From what you say, it seems the code is working correctly  do you have a problem or just don't see how it's done? Enjoy (I've been busting my back on this all on my own or recently with Tommaso for way too long) :) Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk 

September 19, 2006, 13:31 
Thank you for all of your repl

#7 
New Member
Joseph Kummer
Join Date: Mar 2009
Location: Fayetteville, NY, USA
Posts: 17
Rep Power: 10 
Thank you for all of your replies. They are very helpful.
However, I am still having trouble. Hopefully you will be able to help me with this one, as it seems very strange. As I said, I tried the mixer case (as well as another similar case that I setup myself), and the actual rpm it rotated at was different from that which I specified in the dynamicMeshDict file. I did a little experimenting and found that if I set the rpm to 60 and timestep to 0.005, then the actual rpm varied from about 70 to 90 over the first 1/4 sec. Then I reduced the timestep to 0.001, and the actual rpm varied from about 62 to 66. I also reran the tutorial case exactly as specified, and found that the actual rpm over the first 0.25 sec varied as well, although not quite as much, but at least was close to 10 rpm this time (except between t=0.15 and t=0.175 sec, where it was 13.93 rpm). Why would the speed the mesh turns at be a function of timestep? Of course, if the timestep is reduced, then the rotation angle per timestep should also go down; however, for a given deltaT and rpm, the rotation angle should remain the same. I'm wondering if you have seen anything similar, or possibly know what I am doing wrong? Thank you very much. Joe Kummer 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Announcement for an discrete element code for foam  stephan  OpenFOAM Running, Solving & CFD  36  September 17, 2011 11:06 
VTK to Foam  liugx212  OpenFOAM Meshing & Mesh Conversion  2  October 20, 2010 06:40 
VTK to FOAM?  Milos  Main CFD Forum  0  March 11, 2009 11:57 
FOAM  CFDtoy  Main CFD Forum  5  September 21, 2004 14:09 
Foam  Chris Rand  FLUENT  0  May 4, 2004 04:37 