I'm testing 2D heat-exchanger system(annular duct with two flow zones) in axial direction. Two flow fields are isolated separately by steel wall.

Did anyone try this case?

Are you not getting the solution???

I'm suffering from solving two separated flow field in one solver. Basically, when I solve that problem with same fluid properties the solver shows pretty reasonable result. However, in case of different fluid properties, situations are difficult to me. Briefly, continuity residual does not decrease below 10^-2 order. I can't catch the exact problem yet. (Just I guess that problem is caused by use of different fluids.)

Your problem is possible by Fluent. Contact the distributor, ATES, in your country.

Sincerely, Jinwook

Thanks. I will.

All residuals are calculated in basically the same way. The change (change from the previous iteration) of a property in each cell is calculated. These changes then are summed. This total change is now divided by an arbitrary number that Fluent chooses to make a dimensionless number. The result is the residual for that property.

You problem arises when the residual (which has been divided by an arbitrary number) never reaches another arbitrary number. Consider these two examples:

Case 1) The total change in all cells is 10 units. Fluent chooses to divide this by an arbitrary number of 100 units. The result is a residual of 0.1. This isn't below Fluent's default convergence criteria of 0.001, so it doesn't look converged.

Case 2) The total change in all cells is 10 units. Fluent chooses to divide this by an arbitrary number of 10000 units. The result is a residual of 0.001. This meets Fluent's default convergence criteria of 0.001, so Fluent says it is converged.

Did you notice in both cases the true solution changed by the same amount, meaning that either both are converged or neither is converged. However, in one case Fluent reports that it is converged and not the other. Therefore, RESIDUALS ARE ONLY A ROUGH GUIDE OF CONVERGENCE.

The only true measure of convergence is to watch the value you are interested. If that changes over each iteration, you are not converged yet. In your case you may be interested in the outlet temperature of the heat exchanger fluids.

If the temperature of one fluid follows this pattern you are not yet converged, but the solution is heading towards convergence: Iteration 1: T=300K, Iteration 2: T=290K, Iteration 3: T=285K, Iteration 4: T=283K.

If the temperature of one fluid follows this pattern you are converged: Iteration 1: T=300.0000K, Iteration 2: T=300.0001K, Iteration 3: T=300.0000K, Iteration 4: T=300.0001K. Note: there will always be some numerical differences, you have to make sure they are negligible for your problem.

The worst possible case is this, where the solution is oscillating: Iteration 1: T=300K, Iteration 2: T=310K, Iteration 3: T=300K, Iteration 4: T=310K, Iteration 5: T=300K, Iteration 6: T=310K.

And another case that occasionally occurs at the start of calculations is a diverging solution: Iteration 1: T=300K, Iteration 2: T=302K, Iteration 3: T=306K, Iteration 4: T=312K, Iteration 5: T=320K, Iteration 6: T=330K, Iteration 7: T=5000K.

(1). The use of a commercial cfd code is thought to avoid these problems, but unfortunately, it is creating more problems? (2). The vendor of the code should provide a set of parameters for the problem such that the converged solution is guaranteed. (3). Otherwise, I think, the commercial cfd codes are turning the users into researchers for the vendors.

There is one method that works: if your desired result doesn't change, it is converged. As far as I know, there is no other common method (such as residuals) that will guarantee the solution is converged. In your own programs, Dr. Chien, what do you use?

(1). A couple of weeks ago, I translated a Fortran code (which I wrote back in late 80's) into a VC++ code. (2). The code solved Navier-Stokes equations for a lid driven cavity flow. (3). To check the convergence of the iterative process, I printed the flow variables at two locations, one at the center of the cavity and the other at the mid-point of the moving wall. (4). When I run the code, I can easily see these variables vs iteration numbers(every 10 or 50 iterations, to avoid excessive output) on the screen. In the process, you can easily see the change of these variables. The change will move from left to right, until the numbers are identical and remain the same. (5). It is fun to watch the convergence process this way. Normally, the output to the screen has 7 digits of accuracy. (6). In one test, the converged solution was obtained in 6 seconds, for Re=1000, and mesh size= 51x51. I had the simple program set to run 1001x1001 case, but I don't think I need the solution for this particular Reynolds number. (7). If you are using a good formulation and a good method, then convergence is fun to watch. If you are not getting good convergence, then the formulation and the method both must be improved. (mesh is no problem, because you have to pass the mesh independent solution anyway. You run into mesh problem because the mesh is not consistent with the formulation, not because the mesh is bad.)(8). So, the key issue is: are you sure that the formulation and the method used are going to give you the converged solution? If you are not sure, then you are still trying to invent something.(instead of solving the problem)

Thanks for your advice.

I'm afraid you guys understand my question exactly because english is not my mother tongue. What I exactly wanted to know was... "Is it acceptable to solve two isolated flows in one solver?" Of couse, Fluent did it well but I'm not sure that is meaningful to me. The reason why I mentioned above solution was "pretty reasonable" was because of reasonble flow field in my system.(in my view)

Briefly, did you guys solve this kind of system? If so(or not), could you explain the logic to me? I personally don't understand how that approach is possible to solve two system in one solver. Residual was the second problem to me.(As Whitney said, there could be proper criteria for determining convergence.)

P.S : I know there is another approach to solve my system. Solving each flow field first,coupling those results and solving energy equation with converged momentum solutions. However, I tried to solve my system in that way because of my curiosity. Unfortunately,I think, I'm not qualified to know the exact logic.

This is somewhat scary and I agree with John here. There have been previous threads on this Forum regarding how Fluent defines convergence. The amount of change of solution between iterations is simply wrong. There is no way that Fluent can guarantee converged solutions using this as a metric. Run a simple temperature diffusion problem with an explicit code and the change in solution will stall long before conservation is guaranteed.

If you assemble algebraic equations then the residual is simply the amount by which a given control volume equation is out of balance with that particular set of coefficients. You can easily calculate a normalised residual at each timestep for each control volume. You normalise with the central coefficient times a scale based on a characteristic range (eg: max-min) for the variable of interest. This way you can think of your convergence level as "1 part in 10/100/1000/etc" of your solution range.

The other way to define convergence is to look at global balances. i.e., add up the total boundary flows for each equation you solve and see if they sum to zero or not. I don't think this is possible in Fluent. Well, at least it wasn't the last time I saw the GUI. (I think that a mass imbalance calculation was possible).

The point is that Fluent's definition of convergence is flaky at best.

Dan.

(1). I thought that you had already figured out how to deal with the formulation. (2). You have two pipes and each has different fluid flowing through the pipe. So, you are going to have (a). centerline, symmetric boundary condition, (b). center pipe flow with fluid-A, (c). finite thickness wall of the center pipe, this is a solid wall region, (d). outer pipe flow with fluid-B, and (e). finite thickness wall of the outer pipe, then (f). the fluid flow or insulated material outside the outer pipe. (g). Since there is no mixing between fluid-A, fluid-B, and outside fluid, you have 5 separate problems to solve, three fluid flows and two heat conduction in solid walls. (3). Even if you decide to write your own code, it still requires 5 separate zones to deal with 5 separate problems. (coupled through heat transfer) In this case, you need to find out whether there is a sample case of the same type so that you can apply the formulation to your 5-zone problem. (4). So, it is a matter of convenience. It has nothing to do with the convergence issue at all. (it is likely that you are not doing the right thing, or the code as is, is not capable of handling your problem without modification.)

Thank you for your advice again. I understand your approach to solve my system. Actually, I think that's the proper way.

Anyway, did you try to solve totally different systems at a same time in Fluent solver? If so, just tell me "SOLVED or NOT" and if "SOLVED", tell me solution was "REASONABLE or NOT". Just two more things, please.

(1). Why not try to get the answer for your problem from the vendor's support engineer. Since you are using their code, you should be able to get good answer from them, right?

Thank you. Mr.John.

First, how you have defined the problem in fluent?

Fluent code provides some specific boundary conditions like fan BC, radiator, heat exchanger model etc.

I am also trying to solve a 3D heat exchanger problem using heat exchanger model available in fluent. Actually if your problem doesn't involve any phase change of the fluid in heat exchanger tubes, you can use the "macro" concept defined in fluent to represent the fluid zone. Again you need to input some additional parameters like relating to momentum pressure drop in heat exchanger and other air side flow parameters.

However, it is difficult to find any single example like this in fluent documentation.