# Fatal overflow error, singularity, due to local mesh form?

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 June 17, 2016, 07:39 Fatal overflow error, singularity, due to local mesh form? #1 Member   Thomas B Join Date: Apr 2016 Location: Germany Posts: 30 Rep Power: 8 Hello everyone, I'm trying to study the mass flow rate between two chambers: chamber 1 is a cylinder with atmospherical pressure 1 bar and chamber 2 is a bigger cylinder with a very high pressure of 15 bar. The two chambers are linked with a small duct, and are filled with air. The diagram below illustrates the situation (at t=0, beginning of the simulation). Because of the high pressure difference is a flow from chamber 2 to chamber 1 expected, with high Mach numbers (supersonic flow). The volume of chamber 2 has been determined, so that pressure and temperature in chamber 2 stay approximately constant within the duration of the simulation (between 1 and 10 ms real simulation time). Transient simulation Air Ideal Gas Total Energy 5% Intensity Chamber 1: no slip wall with outside temperature (300 K) and heat transfer coefficient Chamber 2 : no slip wall, adiabatic Duct in between : no slip wall with fixed temperature (300 K) Initial conditions: zero velocity in the whole domain, 300 K in the whole domain, pressure defined with a CEL expression if(y>h[mm],15[bar],1[bar]) (see diagram above) 1) Simulation on a quarter of the geometry I first ran several simulations with a quarter of the whole geometry, applying 2 symmetry BC : I played with the timesteps and the mesh size to get no errors such as "fatal overflow error" and residuals under 1e-4 (it's not always happening though, at some time steps residuals are between 1e-4 and 1e-3) and also a reasonable simulation time (between 5 and 10 hours as for now). So I got the physical time steps 30*1e-7,30*5e-7,30*1e-6,30*5e-6,60*1e-5,64*5e-5 : it is not optimal, as there are some brutal changes which cause the residuals to increase. But the simulation run without problems in a reasonable time and I can analyse the results. It will be naturally later improved to meet the RMS requirements (which are still to define in my case, but will be under 1e-4 anyway). My mesh : (approx. 500k elements and 120k nodes) The red zone is the zone where very high speed happen, hence the finest mesh. No grid independency has been conducted yet, but the results of the simulation match pretty well with the theory (Mach Number = 1 in the duct, then >1 by entering the chamber 1, as the flow is already sonic in the duct and the cross section increases, constant mass flow rate after a certain time, etc.). Maximum Mach Number for these simulations never exceeded 4,5. 2) Simulation on the whole geometry Then I wanted to conduct a simulation on the whole geometry, with the exact same parameters as for the quarter of the geometry (except that in the simulation with the whole geometry, no symmetry BC are needed), which implies approximately 2,2 millions of elements and 400k nodes (computing time rises then dramatically) (same timestepping). I did the same thing (body of influences, inflation) as for the quarter but the simulation crashes at the 13th time step with the famous "Fatal Overflow Error". I noticed that the Mach Number has diverged : timestep #9 Ma=2,867 timestep #10 Ma=4,624 timestep #11 Ma=7,571 timestep #12 Ma=40730 With CFX-Post I noticed that it happened in a thin region near the wall of the duct (singularity): Which leads me to think that this error is only due to the mesh in this area. Here are some pictures to see how my mesh looks like: (cross section of the duct (XZ Plane)) (cross section of the duct (XY Plane)) Regarding the mesh of the quarter of my geometry, I would say I have been luckily enough with the mesh generation, that no problematic cells which could bring singularities were produced. 3) My question So with that said, I know I should improve my mesh, in this problematic area at least. But I don't really know how: I mean, as you can see, my mesh is an unstructured mesh with a lots of tetraedral elements, therefore I have only little control on it. I was wondering if I should create an axisymmetric mesh (my geometry is axisymmetric) but it seems that with Ansys Meshing I can't (the inflation layers would always cause the mesh to become unstructured). Just refining the mesh in this area might not be enough, as it is imho a problem of quality, more than a problem of size. What do you guys think? Thomas

 June 18, 2016, 01:35 #2 Super Moderator   Glenn Horrocks Join Date: Mar 2009 Location: Sydney, Australia Posts: 17,326 Rep Power: 138 This looks 2D axisymmetric, so making use of that will speed up the simulation time a lot. FAQ: http://www.cfd-online.com/Wiki/Ansys...tion_in_CFX.3F The simulation in the whole geometry is probably due to round off errors. As the difference between the largest and smallest feature gets bigger then round off errors build up. Eventually they become large enough that they diverge. Ways to reduce round off include: * Double precision numerics * Improved mesh quality (I think you guessed that one) * A better initial condition * Smaller time steps Also, do you really need the inlet and outlet chambers? Can the conditions in these chambers be assumed constant in the time scales you are considering? Then you just need to do a steady state simulation of the throat region.

 June 21, 2016, 08:10 #3 Member   Thomas B Join Date: Apr 2016 Location: Germany Posts: 30 Rep Power: 8 Hello, thank you ghorrocks for your answer, this is very much appreciated. What do you mean by "As the difference between the largest and smallest feature gets bigger"? I tried to improve the mesh in this area, but because of the inflation layers, no matter what I did, the Element Quality remains poor. But I have some other tricks to try... I just hope I won't have to use ICEM because I only have a few weeks before me and it seems to be demanding... If I don't change the mesh but reduce the initial timestep from 1e-7s to 1e-8s it seems that I don't have this problem with the singularity (I am now working with adaptive timestepping). But the simulations are still running, I will have to check the Mach Number in the small duct, which theoretically shouldn't go above 1. To summarize, with a smaller timestep I don't have this Fatal Overflow Error anymore, but I still need to check the values of the Ma in the area where impossibly high Mach numbers happened in the simulation I was refering to in my original post. Double precision numerics was already checked. The initial condition I currently use is indeed not a perfect representation of the reality, as normally a valve between the two chambers would in a finite time >0 open (here it's like the valve opens instantaneously, therefore fluid with low pressure and fluid with high pressure come in contact on a relatively small area, which makes the begin of the simulation critical). I tried your suggestion with a "quasi-2D" geometry (axisymmetrical geometry). I took 2,5° for the angle of the wedge, the number of elements has decreased from 2,2 millions to 40 000. This is as expected very much faster (still need a couple hours though because of the small timesteps (between 1e-8 and 1e-7s to meet the 1e-4 RMS requirement)). I will keep this thread informed EDIT: I cannot do a steady simulation since the injected mass in the smaller chamber (chamber 1) increases, so does the pressure and it can impact the MFR (if critical pressure ratio is reached). Also, the chamber 2 in real life is a conduct supplied with air from a high pressure pump, and as the valve between the two chambers opens, there is a slight decrease in the supply pressure, which has to be taken into account in the simulation.

 June 21, 2016, 08:49 #4 Super Moderator   Glenn Horrocks Join Date: Mar 2009 Location: Sydney, Australia Posts: 17,326 Rep Power: 138 You have moved to 2D axisymmetric - good. that will speed things up a lot. I see another way to speed things up a lot more, see the last sentence in my first post. If you do a series of simple steady state simulations of just the throat you will get a flow versus pressure difference curve. You can then use this flow versus pressure curve to do a simple ODE simulation of the system. This ODE solver can be written in python, matlab or even excel as it is likely to be quite simple. This will allow you to get the time history of the pressures and flow, but only require you to do a few steady state simulations of the throat region. These will be simple simulations compared to what you are currently doing.

 July 7, 2016, 03:46 #5 Member   Thomas B Join Date: Apr 2016 Location: Germany Posts: 30 Rep Power: 8 Hi Glenn, you might have posted your answer while I was editing my message. I need the big chamber because the fall of pressure in it is of interest. I also need the smaller chamber because the pressure p(x,y,z,t) in it has an impact on the mass flow rate in the throat. And also because p and T in the small chamber are of interest. But what would be really nice, is to find a way to get rid of the big chamber (reservoir) because it adds a lot of cells although nothing really important happens in it (speed is 0). I have an appointment with my supervisor today and we'll discuss on this.

July 7, 2016, 06:04
#6
Super Moderator

Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,326
Rep Power: 138
Quote:
 I need the big chamber because the fall of pressure in it is of interest. I also need the smaller chamber because the pressure p(x,y,z,t) in it has an impact on the mass flow rate in the throat. And also because p and T in the small chamber are of interest.
Sure - but you can also model this using a oriface flow restriction equation and a mass balance from the two chambers. You can then integrate this over time using a simple ODE solver. My point is that this reduced order model is likely to be just as accurate as the CFD model, and take an hour to write and a second to run. CFD will take weeks to write and validate, and then many hours to run.

I would only consider doing this by CFD if:
* I could not get good oriface coefficients over the range of flows required
* The transient nature of the flow in the oriface means that oriface coefficients are not suitable (this sounds unlikely)

You should always start modelling with the simplest possible model and only add complexity as is it required. Do not start with the most complex model and wonder why you still don't have any answer weeks after you started.

 July 7, 2016, 09:03 #7 Member   Thomas B Join Date: Apr 2016 Location: Germany Posts: 30 Rep Power: 8 Hi Glenn, thank you for your interest. Now I understand what you mean. Actually I have done something like that for the chamber: mass flow rate and heat transfer have been taken into account in a system of ODEs, and I could get the time dependance of the average temperature and pressure in the chamber (like you said, in a second with Matlab). The mass flow rate was taken here as input parameter. Another possibility is also to take the pressure als input parameter and then calculate the temperature and mass over time (particularly relevant as measurements of p(t) are available for my case). I can do the same for the throat only with the mass balance (so it would be possible to model the fall of the tank pressure). It is an interessant idea that I will keep under my hat (as this way of proceeding seems appropriate for considerations on the mass flow rate only) for later. I've just spoken with my supervisor, and it seems that the scope of my project has a little bit changed: the Heat Transfer in the chamber is also of interest (thickness of the boundary layer upon time, significance of the heat transfer for each wall of the chamber, determining of the heat transfer according to "similarity approach" ) and this requires p,T,v,k (turbulence kinetic energy) all dependent on (x,y,z,t). And heat transfer is the new priority. But for the further work where I will need to concentrate again on the mass flow rate, the idea with a simple system using ODE is not to disregard. Because the parameters that I will be likely to modify (temperatures, pressures in the chamber/tank) can be taken into account in the differential equations. Anyway, to refer to the original post, I am glad not to encounter this "fatal Overflow error" anymore. Solution for that was modifying the mesh and especially reducing the time step (now I work with adaptive time stepping).

 July 8, 2016, 09:57 #8 Member   Aleksandr Join Date: Dec 2015 Location: Kharkov, Ukraine Posts: 93 Blog Entries: 1 Rep Power: 9 Can you look on my Out file? out1 out2

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Ganesh FLUENT 15 November 18, 2020 06:09 xoitx OpenFOAM Running, Solving & CFD 14 March 25, 2016 07:09 lpz_michele OpenFOAM Running, Solving & CFD 53 October 19, 2015 02:50 wsmith02 OpenFOAM 3 July 27, 2015 05:37 [snappyHexMesh] snappyHexMesh won't work - zeros everywhere! sc298 OpenFOAM Meshing & Mesh Conversion 2 March 27, 2011 21:11

All times are GMT -4. The time now is 06:36.

 Contact Us - CFD Online - Privacy Statement - Top