[Silmaril]

Hi, I'm new in this forum.
I have a problem with mesh deformation in a rather fine grid of a valve.

Is the first time I use mesh deformation and after doing the tutorial I tried to set up my problem accordingly in ANSYS CFX 12 (all mesh deformation parameters are as in default condition).

The mesh is completely hexaedral, the initial gap of the piston head is 0.1 mm (total stroke 8 mm) with 10 layers leading to quite a big refinement in the region near the gap. all the surfaces except for the piston head and piston stem are set to stationary, piston head has specified motion and the stem unspecified motion.

After few time steps the mesh quality fall and finally the calculation crashes due to some degenerate element. I post-processed the results looking for how the mesh is deforming and a picture can be viewed in the attachement. I think that the mesh quality will improve a lot if I can tell the code to deform the mesh as suggested by the red arrows (in the attachment). Anyone knows how can I do this, or do you have any suggestion on how the problem can be solved?

Thanks in advance

[michael_owen]

Use distinct subdomains and specify the mesh motion individually using CEL. This dictates the precise motion of all mesh nodes, not just surface notes. You may also want to consider sliding GGI interfaces.

[Silmaril]

Do you know if there is any example or tutorial to start with? The grid size is about 2 million nodes but the "problematic" part is smaller, do you think it is better to split the grid in different sub-domains and "manually" set the mesh only in few sub-domains?

Thanks

[ghorrocks]

Definitely, yes. If you can manually define the motion it is far better than using the global mesh smoothing method.

You may also wish to use GGI interfaces to create sliding interfaces. These can often be better than letting the mesh distort to join mesh sections when you have linear motions like poppet valves and pistons.

[Silmaril]

I tried to find some more or less detailed guide in the manual on how to set manually the motion, but havn't find any .
Do you know if there is such an information on the CFX 12 help? Do I have to change all the coordinate of each node every timestep in some file like the cfx5 file imported from ICEM for the grid or something similar?

Another possible solution that came to my mind is to set the nodes on a surface to have a motion only on such surface (not normal to it) so as to let the nodes "moves around" on the fixed surface, is it a possible feature in the code?

[ghorrocks]

You cannot define boundary nodes to stay on a surface, but move around on that surface.

The only way to fully specify mesh motion is with user fortran. Michael suggests that defining a region a subdomain allows you to define the motion of all nodes with CEL, I have not tried that. So that is two options.

[Silmaril]

Does anyone have some fortran routine for moving nodes that can share just to have an example to start with?

Thanks

[tillx]

I have run into similar problems and ended up setting up a separate mesh for each timestep. I did this just by duplicating a satisfying mesh with the current parameters, updating the geometry from CAD and then tweaking the parameters to optimize the mesh for the new geometry. Once all meshes are setup in workbench, its easy to relink them with CFX for each timestep in workbench and update the solve. I'm sure that can be further automatized that the consecutive meshes are automatically uploaded at each timestep. I'm just not there yet. Works great with even the most complex geometry changes in a rotary piston engine.
Nevertheless, a drawback seems to be that with that approach the mesh interpolator does not follow the continuous mass assumption in the changing mesh since new nodes are introduces each timestep rather then existing nodes relocated, I assume. For an expansion cycle I could solve that by using a negative total mass flow in the continuity setup of a subdomain. For the respective total mass flow for each timestep I use a nested if() array with the volumes of each current and previous mesh I preset from the CAD data. That makes convergence much more stable it seems. The mass outflow is then just the volume difference between meshes multiplied by volumeInt(Density). The results can be double checked by summing the Mass Flow at the interfaces of each timestep and comparing with volumeInt(Density) of the final timestep.
In the compression cycle this approach now looks a bit more complicated as it seems that I have to add mass with continuity values that match the ones existing ones. I'm currently waiting for feedback myself on that issue. Hope that helps.