CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   STAR-CCM+ (https://www.cfd-online.com/Forums/star-ccm/)
-   -   Pressure and Temperature out of Range (https://www.cfd-online.com/Forums/star-ccm/98737-pressure-temperature-out-range.html)

rks171 March 17, 2012 14:15

Pressure and Temperature out of Range
 
I have a simulation that was working before, but I refined the mesh to try and improve simulation accuracy. Now when I run, after only 4 iterations, I get the error:

Code:

Temperature corrections limited in 1 cells in region Body 1
min. Temperature limited to 100 in 1 faces on boundary grid
IAPWS_IF97::evalEnthalpy(p,T): p, T out of range

Anybody have an idea of the source of this error or how I could find the source of the error?
I used a mesh very similar to this one on an unheated case and had no problems with it (obviously, temperature wasn't changing in that case).

rks171 March 18, 2012 06:40

I tried putting a maximum limit on the temperature in the continuum of 640 K, which is below the critical point. I tried reducing the under-relaxation factors for the energy solution in the fluid and solid. I tried switching the energy solution to first order. I tried reducing the heat flux going into the fluid by 25%. All had relatively no effect and all produce the same error.

abdul099 March 18, 2012 15:48

The message is "MIN temperature limited...", therefore it can not work to reduce the heat flux or increase the max temperature.
Messages like this often occur when the mesh is too bad. You should check your mesh for bad quality cells.

rks171 March 18, 2012 19:34

Yes, you're right. I don't know why I though to put a max limit on it. Perhaps because there's already a min temp limit on it. But the min temp limit is 100 K, which is much lower than it should be anywhere in my mesh. What puzzles me, though, is that my initial temperature through the mesh was set to ~500 K and I have heaters in the continuum. So I don't understand how the temp could go down to 100 K anywhere. I did check for high skewness cells and there were some, but not an excessive amount. Like I said, I ran this mesh before for an unheated case, so perhaps adding in the energy solution is making the mesh invalid. I'll get on checking that mesh further tomorrow, but I usually don't have a lot of luck with improving my meshes, so I have some backup strategies also.

Earlier today, I gave it a shot to try using the coupled implicit flow/energy solver instead of segregated with a Courant number of 1. That's been working, but it's converging very slowly. I'm also going to try to run the solution without the energy equation or heat input for a while to get the velocities closer to their right values before turning the energy on. I'll post back with the results.

rks171 March 19, 2012 16:35

So trying to run without energy produced some crazy residuals. I found this odd because the residuals looked great when I ran the similar mesh for an unheated case with slightly different boundary conditions. That's not to say that the results wouldn't have still worked out, but I had a better idea. I remembered that in starccm+ you could import solutions to use as initial conditions for a mesh. I ran this case before with a coarser mesh that converged successfully. So I exported that solution and imported it into my fine mesh and started running it from that point. I'm using segregated flow and energy again and it's moving along fine for now.

To sum up this thread and conclude it, solutions that worked to avoid this error were:

1. use coupled implicit solver instead of segregated flow/energy
2. use the exact same refined mesh that I produced for the unheated case and import the heated case coarse mesh solution to use as initial conditions

abdul099 March 21, 2012 05:32

Nice to hear that it works now. But I've got some points to consider:

You wrote there are just a few cells with a high skewness angle. Well, my answer is: There is just ONE cell where the temperature drops down to the limiter. Just a few bad cells are causing just a few problems.
But when it's just a few cells, I usually ignore it as long as the simulation doesn't break. It will not have too much impact on the solution as long as it is a big mesh.
Anyway I wouldn't just check for high skewness angles. Make a right-click on the region, choose "remove invalid cells" and hit the preview button. It will check the overall cell quality which is much more than just skewness (I've heard something about 17 different criteria going into the cell quality). Also try to make a threshold with the cell quality and check WHERE the bad cells are and inspect your mesh around this location.

Another point: What happens when you run it for more than 4 iterations with the segregated solver? Will it stabilise? When you run it unsteady: What happens when you reduce the time step? When it's a steady case: Ever tried to reduce under relaxation factors for the first let's say 100 iterations?

Did you switch on cell quality remediation?

rks171 March 21, 2012 09:42

I checked the 'remove invalid cells' dialogue and no cells were flagged for removal based on the default criteria. Assuming a minimum cell quality of 1E-8 is sufficient, there are no bad quality cells to find in a threshold.

Running past 4 iterations with segregated solver was not possible because the solution crashed due to 'out of bounds' error. When I initialize the case to a coarse mesh solution, I do not encounter this problem. Nor do I encounter it when I run using coupled solver from the test case initial conditions. I already did try to half the URFs for the segregated solver and that did not work to prevent the 'out of bounds' error. I did not attempt an unsteady solution. I figured that would take much more time than the coupled solver and, since the coupled solver worked, I didn't try unsteady.

I'm unaware of what 'cell quality remediation' is.


All times are GMT -4. The time now is 23:32.