I've a problem in a instationary calculation with moving mesh. In particular I tryed to simulate an alternative motion for a piston by activating and disactivating cell layers. During the reactivation, near the finish of the calculation, yhe solver find negative density in a lot of cells in the cylinder mesh. I can't understand why the problem appear near the finish of the calculation. If the problem is in the reactivation process, I would have found the problem much many timesteps before!

You may try "switch 60 on"

if there is any cavitation in the system, and you have cavitation off, then you will get negative density. BTW, cavitation does not work in STAR-CD, so if that is your case, try fluent or CFX.

Wrong !!

If you have a fluid which is able to cavitate (like water) you usually have constant density switched on. How do you want to get negative densities if your density is fixed?

You might get negative absolute pressure in this case.

I am not certain of the physics you are interested in, but what I would suggest is to look at a couple of things.

First is timestep.

At the end of deactivation procedure, you may end up with some very small volume cells, and it can be that your courant number is becoming quite large relative to the numerical stability criteria. Have a look in the info file for the mean courant number. If this is the case then you may want to consider using the load step or dtstep.f options of STAR.

As a guide it is typical for an engine calculations to run 1/4 degree CA timesteps (or 1/8 at worst). Your local Support Office can tell you how to specify time in terms of degree CA via RCONSTS if this helps.

The other thing to have a look at is the URF for pressure in the PISO method. In the extreme case this should be no less than 0.3 (typically around 0.5-0.7 for difficult moving mesh eg sliding interfaces etc). If you are still having problems then it is back to reducing timestep.

My little experience with neg. density was resolved in 4 ways, some of which were already stated.

a) Time step - make it smaller but this will produce huge data size. b) Under-relaxation factor - this requires a lot of trials. c) Turbulence intensity and turb model - very seldom. d) Improve the mesh in the domain - this can solve it exclusively without spending any time in the three above. For some physics, the calculation is more sensitive to the mesh quality. However, if it is indeed mesh-related, I don't know why you don't get the error at an earlier stage of the calculation though.

The sliding motion also may cause a problem at the sliding interphase when the areas in contact are too arbitrary. Do you employ coupling also somewhere in the domain? If you do, the transition in sizes between the couple faces shouldn't be too large.

I would suggest to look into the mesh since from my experience that was a root cause.

Of course different physics create diferent problems. I haven't tried the other attempts as stated in this forum. They might be more effective. Let us know your own experience from this afterwards.

I think that problem is due to this facts: I need to use arbitrary sliding interfaces to model the real geometry of inlet/outlet ducts. The model rapresent a 2-strokes engine, so the arbitrary interfaces are "around" the cylinder. During the deactivation there are no problems, but when the calculation arrives near the reactivation problems occur and the calculation crashes. I tryed in a very simple model without ASI and the activation/deactivation works very well, but when I use arbitrary sliding interfaces...problems come back!