[cfd seeker]

Hello,

you were right. As i was exporting the mesh in .msh format but i was not telling CFX under "Mesh Reload Options" that the mesh is in .msh format. After selecting this option, remesh happened normally but now a new problem has appeared.

The mesh is not imported/interpolated as it should be. In first pic you can see the instant where new mesh should be imported but 1 time step after import/remesh whole of the rotating domain has rotated too much and some faces also did remain at their intented positions as can bse seen in pic 2. Pistons are rotating whole as a domain and individual piston is also making reciprocating movement in its own axis (due to which mesh is deforming). Attached pics mesh on piston 1 highligted for the reference.

remesh_30.jpg remesh_31.jpg

Did you face any such problem? What kind of motion you were modelling?

[Lance]

Im not sure what you are showing, but since you have already generated the meshes do some checks that they are imported correctly through file/import/mesh before using the icem replay option. How are you prescribing the motion? Check that it makes sense after remeshing - mesh displacement variables are always relative a specific mesh topology and after remesh this is reset to the new mesh.

[cfd seeker]

ok i try to explain once again. In the 1st pic you can see the piston 1 at top most position (at start of simulation), when this piston has been rotated 90 degree (at 30th time step), first Remeshing is done. After after the Remeshing, this piston has been rotated 180 degree (instead of 90 degree) as can be seen in the figure 2.

piston1_0deg.jpg piston1_180deg.jpg

Actually what happening is that after 30th step the pistons has been rotated 2.94 * 30 = 88,2 degrees and this is w.r.t to the initial mesh. After after remesh in 31st time step, the rotation should again start from zero w.r.t to the New Mesh (now the New mesh is the initial mesh) but in 31st time step, the pistons have been rotated 2,94 * 31 = 91,14 degrees, so that's why i see an extra rotation of about 90 degrees. I also placed Monitor points at the centroid of each boundary to see their displacements and after the remesh they also show a Jump which obviously is wrong, as can be seen in the figure 3.

monitor_points.jpg

Any idea how to tackle this?

[Lance]

Originally Posted by cfd seeker

Any idea how to tackle this?

It is impossible for us to debug your model. But have a look at the definitions regarding mesh motion/rotation as they appear to produce unwanted results.

[ghorrocks]

I recall posting some time ago that the best work-around for your simulation was to split your piston domains into two, a moving mesh section to model the piston motion and a stationary section for the interface so you do not get these problems with the interface moving and doing weird things.

All these attempts you have made on this model are failing for what appears to be the same reason - there appears to be a bug in CFX where moving mesh and interfaces does not work properly if you define the interface as stationary.

If you ignore our assistance and keep asking the same question different ways then what is the point of helping you?

[cfd seeker]

Originally Posted by ghorrocks

I recall posting some time ago that the best work-around for your simulation was to split your piston domains into two, a moving mesh section to model the piston motion and a stationary section for the interface so you do not get these problems with the interface moving and doing weird things.

All these attempts you have made on this model are failing for what appears to be the same reason - there appears to be a bug in CFX where moving mesh and interfaces does not work properly if you define the interface as stationary.

If you ignore our assistance and keep asking the same question different ways then what is the point of helping you?

Sorry i forgot to update in the other thread, the problem of mesh moving on the interface had been solved. The two sides of the interface were not at the same location, so almost whole of the interface was in "Nonoverlap Condition". I corrected the geometry and problem got solved.

Now the problem is with the Domain rotation after the first Remeshing. Somehow the new mesh after the first Remeshing is inherting the displacement/rotation of old mesh also e.g. first Remeshing was done at the 30th timestep and uptill 30th timestep the pistons have been rotated almost 90 degrees. So in 31st timestep (1st step after Remeshing) the total rotation should be 90 deg+2.94 deg (2.94 degree is rotation in every timestep). But in the 31st timestep the total rotation is 90+90+2.94 degrees. So the new mesh is somehow inherting the rotation of old mesh also.

I am also talking to CFX support for this problem. If you have any idea then it will be welcomed.

And yes sorry again for not updating the other thread, i will do it ín future

[ghorrocks]

Why do you need to remesh this at all? Can't a single mesh topology with mesh motion cover the motion?

[cfd seeker]

Originally Posted by ghorrocks

Why do you need to remesh this at all? Can't a single mesh topology with mesh motion cover the motion?

sorry for the late reply. I was very busy.

Unfortunately not, the mesh in the piston with maximum stroke gets folded and gives negative volume error. I tried various options for smoothing the mesh and even tried expression (1/Wall Distance) but unfortunately they also didn't work. So i am left with no choice but to do Remeshing.

If i just translate the pistons in their own axis and don't rotate them. Instead rotate the Inlet and Outlet ports in counter clockwise direction then it will give almost the same effect. But will i be inducing the extra turbulence (because of rotating flow) in the system if i choose to rotate the ports instead of pistons?

[ghorrocks]

If you are modelling piston meshes it is common that you have to start them from top dead centre and stretch the mesh out from there. squashing the mesh up often causes mesh folding errors. So if you start your pistons at TDC and stretch the mesh out from there you won't get the negative volume element error. Even if you have to do an artificial start point with all the pistons at TDC (which is not physically possible) and move the into position before starting the actual motion, this will be much easier then keyframe meshing.

I don't understand your final paragraph. The rotating bits of your model need to be modelled rotating and the stationary bits need to be modelled stationary. You can't swap them over. The centripetal and coriolis terms mean rotating frames of reference are not inertial.

[cfd seeker]

Originally Posted by ghorrocks

I don't understand your final paragraph. The rotating bits of your model need to be modelled rotating and the stationary bits need to be modelled stationary. You can't swap them over. The centripetal and coriolis terms mean rotating frames of reference are not inertial.

5 pistons make Rotating Domain and Inlet and Outlet ports make Stationary Domain. 5 pistons as a Domain are rotating (clockwise) and each individual piston is also making translation motion in its own axis(while it is rotating). I am attching the figure so that you can understand the motion.

domain.jpg

What i am trying to say is that instead of rotating 5 pistons in Clockwise direction, i would rotate the stationary domain in the Counterclockwise direction and only translate the pistons in their own axis. Would this practise make a large difference in the solution?

5 pistons: Rotation around Global axis (clockwise) + Each piston translate in its local axis
Inlet and Outlet ports: Stationary

Instead:

5 pistons: Each piston translate in its local axis
Inlet and Outlet: Rotation around Global axis (counterclockwise)

I hope now i have conveyed the point.

[ghorrocks]

As stated in my previous post, the centripetal and coriolis terms mean that a rotational frame of reference is not inertial so you cannot swap them over. If you do swap them over as you suggest the error will be however large the centripetal and coriolis terms are in your model. Whether that is small or large will depend on what you are modelling and how accurate you want to be.

But the easiest way to check would be to run both options and compare the results.

[cfd seeker]

Originally Posted by ghorrocks

As stated in my previous post, the centripetal and coriolis terms mean that a rotational frame of reference is not inertial so you cannot swap them over.

yes you are right, even that was my concern while asking about it.

Is it possible to add Centrifugal force and Coriolis force as Source terms? Like donot rotate the pistons and just add the Source terms for these forces in the fluid domain of rotors and rotate the inlet and outlet ports in counterclockwise direction and subtract the source terms for these forces from the fluid domain of inlet and outlet ports? If yes, then how easy/difficult it is?

[ghorrocks]

I have never done this (although I did consider it recently for an analysis I was doing). So I cannot say how hard is it to implement. Give it a go and tell us

[cfd seeker]

Originally Posted by ghorrocks

I have never done this (although I did consider it recently for an analysis I was doing). So I cannot say how hard is it to implement. Give it a go and tell us

I would give it a try. maybe in the process i can get some help from you

sourceterms.jpg

This is from the CFX theory guide. Do you have idea how the "r" location vector can be calculated/implemented through the CFX expression?

[ghorrocks]

r is a vector so you will need 3 components, let's call them rx, ry and rz. Then rx = x-x_origin, ry = y-y_origin, rz = z-z_origin. x/y/z_origin is a point on the rotation axis.