CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

IcoTopo mixerMeshslide Foam Code

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   August 4, 2005, 03:21
Default Hello All If it is not
  #1
New Member
 
Michael McWilliam
Join Date: Mar 2009
Location: Waterloo, Ontario, Canada
Posts: 5
Rep Power: 8
pilot is on a distinguished road
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() )
);
pilot is offline   Reply With Quote

Old   August 4, 2005, 04:13
Default In short, the inner part of th
  #2
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,758
Rep Power: 21
hjasak will become famous soon enough
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
hjasak is offline   Reply With Quote

Old   September 19, 2006, 09:44
Default I am wondering what I could be
  #3
New Member
 
Joseph Kummer
Join Date: Mar 2009
Location: Fayetteville, NY, USA
Posts: 17
Rep Power: 8
jdkummer is on a distinguished road
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
jdkummer is offline   Reply With Quote

Old   September 19, 2006, 09:54
Default Not far: rpm stand for "revolu
  #4
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,758
Rep Power: 21
hjasak will become famous soon enough
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
hjasak is offline   Reply With Quote

Old   September 19, 2006, 10:33
Default 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: 8
jdkummer is on a distinguished road
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 cross-flow fan. I will be happy to post results and test-cases on the website for others to try once I get it to work.

Thank you very much.

Joe Kummer
jdkummer is offline   Reply With Quote

Old   September 19, 2006, 10:46
Default Hi, Coordinate system is a
  #6
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,758
Rep Power: 21
hjasak will become famous soon enough
Hi,

Coordinate system is a cylindrical one: origin you know, axis is the z-axis 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
hjasak is offline   Reply With Quote

Old   September 19, 2006, 13:31
Default Thank you for all of your repl
  #7
New Member
 
Joseph Kummer
Join Date: Mar 2009
Location: Fayetteville, NY, USA
Posts: 17
Rep Power: 8
jdkummer is on a distinguished road
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
jdkummer is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


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


All times are GMT -4. The time now is 00:53.