complex mesh deformation with compression
 

I am simulating compressible fluid exchange in a volume with complex geometry changes I was able to capture from separately meshed CAD data. Works great in the expansion phase where I have a mass outflow in the subdomain and thus continuity values of the total mass flow are of no concern. But now that I am moving to compression I seem to be stuck. Any solution to my problem?

You will have to explain what you are trying to do better. Some pictures would be nice, what is the working fluid and what is driving the flow (pressures, flow rates etc).

Thanks for your reply and interest.

I am trying to simulate a 4 cycle internal combustion cycle in a rotary piston engine. The volumes change in a very complex fashion so I resorted to setting up a separate mesh for each timestep. As far as I have figured, at the begin of each consecutive timestep, the density results from the previous timestep are interpolated onto the new mesh. This means that even though the mesh volume expands/contracts between timesteps, the pressure stays the same. To deal with that limitation in the mesh interpolation, I use a subdomain for the volume and under its Sources / Continuity / Option / Total Fluid Mass Source / Total Source I use an Expression that calculates a negative mass source for each timestep that corresponds to the volume change between steps. Since the mass source is negative for any volume expanding cycle, I don't have to worry about "Variables (sources & relevant sink options only) ". The setup works great for expanding volume cycles and the results are very accurate when summing the mass flow through the ports at each time step and comparing it with the total mass inside the volume at the last time step.

Now that I want to move on to a compression cycle where the volume gets smaller from step to step, I have to add a positive mass source with this approach. This requires supposedly that all Variables such as Temperature, Turbulence Kinetic Energy, Turbulence Eddy Frequency, Velocity are correctly entered for the added mass flow. That's where I'm stuck right now since I haven't figured out how to derive those variables from the previous result and make them available accordingly.

I wonder if I'm missing something on the larger picture here, since simulation of expanding and compressing volumes even with complex geometry changes in conjunction with compressible fluids should be a standard task with CFX?

Yes, it is a standard task and CFX can do compression and expansion very accurately. My thesis used CFX to model a rotary valve IC engine and I got the compression and expansion strokes very accurately (http://hdl.handle.net/2100/248). I don't think I put the basic compression and expansion validations I did in the thesis but trust me I did them (both on CFX4 and later on CFX5) and the results were within fractions of a percent of the analytical answer.

The problem is with your method. Interpolating results onto a new mesh too often creates problems maintaining conservation (as you have found), and accoutning for it with source terms is always going to be tricky. The momentum, energy and turbulence source terms are always going to be tricky.

What you want to do is to make sure your meshes have the same topology as far as possible, then you can move between them using moving mesh with no need for interpolation. Only do an interpolation step when the mesh is becoming too distorted and you need to remesh. This way you minimise the inaccurate interpolation steps and maximise the accurate mesh movement steps.

Assuming you are modelling something like a wankel rotary engine I would first look at the immersed solid approach. I suspect you may have problems with things like heat transfer on the rotor there, there is no easy answers.

Thanks for your input, I appreciate it. I agree with what you wrote. As I see it, the main mesh deformation tools in CFX are limited to linear mesh deformation only to deal with valves, oscillating pistons and such.

I'm also not sure if the Immersed Solid approach isn't good only for incompressible fluids? I am playing right now with the mesh morphing option, that seems promising so far. It seems to fit existing meshes into updated CAD geometry while maintaining original meshing parameters.

Yes, I think you are right - immersed solid does not support compressible flow yet.

The CFX moving mesh tools are not limited to linear motions. I explained a method which should work for you which would describe the complex motion of the chamber. You will need to do some fortran to get this to work.

BTW, have you checked the rotary valves Yamaha used to build into some of their motorcycle engines?

I can't remember seeing Yamaha RV engines. RV engines are not new and plenty of people have had a shot at it with various designs. Any idea which model or year they did it?

Slightly off topic here, but at some point you mentioned you were using volumeInt(Density), presumably to track mass. Don't do this - use the mass() function instead. The mass() function gives the mass at the end of the timestep. volumeInt(Density) gives the volume integral of the average Density during the timestep.

Thanks Stumpy, that might be the reason why I have difficulties comparing MassFlow sum of individual Timesteps with the accumulated mass. I've tried that mass() function in an Expression in Pre and Post, but I always get an error message "function not recognized". Any hints?

1964 125cc ya6

Here's my update on the Mesh Morphing option. It actually remeshes and creates e new mesh onto which the previous node values are interpolated. So that's disappointing. Seems like there is no way around diving into Fortran to solve this. On a different note, I have difficulties matching the sum of all MassFlows from the individual Timesteps with the final mass present in the volume at last Timestep. stumpy suggested the mass() function instead of volumeInt(Density) but for some reason I can't get it to work in any Expression.

Yes, you will almost certainly require fortran for a motion as complex as yours.

Just looked the 1964 125cc ya6 up on google - it only had a rotary valve to control the entry of inlet gas into the crankcase of a crankcase scavenged 2-stroke. Sounds, well, ancient. If you want to see some serious rotary valve technology, try this one home.people.net.au/~mrbdesign/PDF/AutoTechBRV.pdf

Uuh, I like that. With some ceramic coating the Heat Flux should be manage able. Almost as good as no valves at all, as we know from rotary engines. In case you're curious what I'm tinkering about, check out US Pat. 7347676. The engine I'm working on is designed very differently, but the alternating angularly expanding and contracting rotating volumes are similar.

As for the Mesh Morphing it seems I have to correct myself. It is supposed to relocate existing Mesh Nodes says the manual. Nevertheless, I was not able to get a mesh update in a linked Workbench setup. I'm trying now to update the relevant Mesh File via Fluent export. It seems to work. Very cumbersome though. That's why I'm following your promising train of thought and check out Angular Mesh Deformation Options. Wasn't there in R11, but I can see it now. What would an Expression have to look like that updates Theta Displacement Component proportional of all Boundary and Subdomain Nodes?

The heat flux was fine. We ran cooling oil through the valve and the temperature was stable. We did many endurance tests where the engine was cycled through a power cycle (including a good proportion of time at full noise, ie max revs max power) and it lasted hours. Bear in mind it was a race engine so hours is more than enough. We did consider ceramic valves to eliminate the cooling oil but the oil worked fine so that's what we ran with.

Interestingly the engine breathed similarly to equivalent poppet valve engines on a flowbench, it was only at full speed that the breathing advantage became apparent. But the rotary valve had other advantages, it set up a flow field in the cylider which was very advantagous for high bore-to-stroke ratio engines. Have a look at my thesis if you want details (http://hdl.handle.net/2100/248).

Your patent is a totally different concept. Good luck with it! As you can see from the article you need more than a good technology to make a difference.

All right, here's my final report on the subject as I am watching the Solver cranking one Timestep after another with fully automatized Mesh Deformation. No need for Fortran, it could do all the Mesh Deformation Definitions with CEL, and that with my rotary volumes. Anyway, two main tricks to consider. Firstly, its crucial to place the reference coordinate system at the right location. That way the mathematic formulation of the Nodes Displacement is most efficiently reduced. Secondly, all nodes can be proportionally scaled by use of x, y, z, r, theta. Defining the initial reference dimensions is key to setup an automatic scaling of them. Thanks Glen for your input.