My experience is that in-house codes are generally very fast for the specific flow problem for which they are coded. Not for general applications like in Fluent, of course.

In your question there are no details to understand your issue. Please, provide more infos.

Thanks for the response. The problem I am solving is a mixed convection flow inside a 3D lid driven cavity. I used SIMPLE algorithm for both my inhouse code and Fluent. The in house code uses a segregated formulation where pressure and velocity linear system are solved separately. I don't know if Fluent solves it in coupled formulation by default. But I am not concerned with the CPUTime of simulation. I want to know why the convergence of mass (continuity) and momentum residuals are faster (with respect to iterations) for Fluent. What can be the factors that affect this convergence?

First of all, you should compare the exact same method, but it appears you don't know exactly which one was used in Fluent. Thus, for example, if the Fluent reference you are using was based on a coupled method, that might be a first reason.

Given the exact same method, my aneddotical evidence about convergence speed is that it typically depends from a mixture of how well you take into account the implicit coefficients, how well you can solve the resulting system and how much the problem is elliptic in nature. Fluent is certainly best in class for the first two points (especially the AMG part), but this makes little differences in certain class of problems which are convection dominated. I don't exclude there might be also some convergence acceleration trick for convection dominated flow (where the bc info that should only propagate from inlet is somehow replicated at outlet for some fields like the pressure).

Concerning your case, I would classify it as mostly elliptic in nature, something where AMG would shine. Yet, how you discretize gravity and the equation of state has importance here. Fluent uses a very specific approach here that you must compare with your as well.

Long story short, Fluent is the result of more than 20 years of research and experience, with every single possible corner cut. More importantly, they had funds and time to just do that, their business. That is, there are people working there whose main job, every morning, is: how do we make this thing faster? And not all the solver features are actually documented, of course.

Thanks for the response. This was really helpful. I forgot to mention that the flow is steady hence I adopted the steady state approach for both my code as well as for Fluent. The flow regime that I am considering is laminar and hence I suppose is not convection dominated.

I checked once again the Fluent options. In the options for the solver, I used SIMPLE. But I also see an option for "coupled" along with other standard approaches such as PISO and SIMPLEC. So I suppose that means it's a segregated approach? For the linear solvers, it uses AMG by default with Gauss-Seidel smoother.

I wanted to know if the discretization schemes also play a dominant role in the residual convergence apart from the coupled vs segregated approach. I use second-order accurate (maximum) discretization for advection terms (Fluent uses second-order discretization for momentum) and an orthogonal correction approach to account for the non-orthogonal terms for pressure correction. But from my experience for the above particular problem, it didn't have much effect on the convergence when I switch off the non-orthogonal projection terms for the pressure correction equation possibly due to a good quality mesh.

In Fluent it uses Least squares for the gradient scheme whereas I use Green-Gauss which is maximum 2nd order accurate whereas LS is 2nd order for any mesh? By equation of state did you mean for convection-dominated flow? Or can you tell me how the equation of state comes into the model as the formulation is for incompressible flow?

Yes, SIMPLE is a segregated approach. And a relevant aspect for convergence is how tight is your convergence on the pressure equation that, in turn, will drive the divergence free constraint accuracy. Preserving a divergence free velocity field during iterations is kind of part of the speed in convergence most of the times.

Schemes, and how you treat their implicit part, do, indeed, have an effect. Fluent, to the best of my understanding, always uses a first order upwind for the implicit convective part and a straight finite difference approximation for the implicit diffusive part (using the so called deferred correction approach), which are both very beneficial for the convergence.

Moreover, Fluent also has several pressure discretizations, which can equally affect the convergence but, unfortunately, are not really open to the public.

Finally, Fluent has limiters, which are instead detrimental for convergence.

I don't know what mesh you used but, if I understand the case correctly, it's just a cube, so I expect the mesh to be fully orthogonal. It can be shown, in this case, that all the gradient methods become like a classical central finite difference. Moreover, for this mesh, there will be no non-orthogonal terms, which also means that diffusion-like terms will be treated as implicitly as possible.

For the gravity part, Fluent uses an approach where the gravity head with a reference constant density is absorbed by the pressure. Which means that you only use gravity for non constant density, which for a temperature based code like Fluent means that an equation of state is involved in going from the temperature to the density. This could be as simple as a Boussinesq treatment, but density needs to be variable and linked to the independent variables, which is what an equation of state does.

When something is convection dominated it also means that your current iteration linearization is pretty much far from the actual solution. Your solution is as close to convergence as the inlet bc is to the outlet, so to speak. So it means that, even if you are good at solving the system, that system is quite wrong and any AMG advantages are wasted. In such cases you still probably need a number of iterations proportional to the number of grid points in the relevant directions.

Just my stupid comment: how do you ensure that your guess condition is the same in both codes?

Thanks for the info about Fluent Paolo. I used a high-quality tet mesh (nearly orthogonal). For the gravity part, in order to make it consistent with my solver, I made the density of the working fluid with Boussinesq approximation in the properties tab in Fluent. Your last paragraph regarding the error in solution from the actual solution for convection dominant flows makes a lot of sense. You observe this as you increase the Reynolds number. Due to the complexity involved the convection part is at most 2nd order accurate in my code. Fluent is also using 2nd order upwind.

@Filippo, not a stupid comment at all. In fact I missed mentioning this. The trick is to get a good approximation (guess) for pressure. That is also the basis for developing SIMPLER algorithm. In my code, I use zero intial guess, and to make it consistent I used the standard initialisation in Fluent where you can specify values of dependent variables. Fluent can also guess a solution for you using its hybrid initialisation. You may find a discussion on this topic here:

https://www.cfd-online.com/Forums/fluent/183866-difference-between-standard-calculation-hybrid-calculation.html#:~:text=In%20standard%20initialization%20you%20must,and%20your%20mileage%20may%20vary.

Ok, so with a tetra grid involved, no matter how high quality, you get differences between gradients. Not only this, but some Green-Gauss implementations become just inconsistent on unstructured grids. You also get non-orthogonal terms and, most importantly, depending from how you split terms between orthogonal and non-orthogonal ones you get differences in the weight of explicit vs the implicit part, which obviously affects convergence.

In the end there are just a lot of things that affect convergence.

Also, don't underestimate the amount of testing, on both users and Ansys side, that Fluent has undergone, the fact that multiple times different teams merged in Ansys after an acquisition, etc., bringing together different experiences. CFD is an industry like many others, and you are comparing your code with basically one of the only two codes that got most things correctly.