[pilot]

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() )
);

[hjasak]

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

[jdkummer]

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

[hjasak]

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

[jdkummer]

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

[hjasak]

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

[jdkummer]

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