[Stab]

Today I have gone through this very interesting (and a bit old) discussion:

http://www.cfd-online.com/Forums/mai...luent-cfx.html

I think it would be interesting to analyze what is the current state, more than 7 years after this topic, and see how the situation has changed (or has not).

I have extracted some pros/cons of OpenFOAM and commercial solvers that were discussed back then (not saying that they were/are right). Obviously some of them still apply, but which ones do you think do not apply anymore? Is there any that has changed in an unexpected way? Is there something missing (I am sure there is)?

OpenFOAM:
+ Free license
+ Full control of the code (flexibility, modification)
+ You know what is going on
+ Affordable parallel simulations (free license)
+ Rapidly developing
+ Academic usage (potential future professionals)
- Meshing quality, CAD import
- No GUI, hard to use, steeper learning curve
- Slower
- No detailed documentation
- No integrated solution (vs commercial alternatives)
- Hard to get effective support
- Portability issues (Linux based)

Commercial Solvers:
+ Quicker and more accurate problem solving
+ Smart GUIs that facilitate the work, easier to use
+ You get support as a paying customer
+ Extended use in industry
- Black box
- Results always look good, even when they are not
- Slow developing and not open bug-fixing
- Expensive, prohibitive parallel CFD costs

[arjun]

I think people tried to create some sort of gui for openfoam too. I am not sure how easy are they to be used for some complicated case sets.

Another area where openFOAM lagged behind at the times of that old thread was solver stability. Not sure how much openfoam has come.

[Simbelmynë]

Fluent allows for some insane system setups. Try running an incompressible case with a pipe that is blocked in one end and has a velocity inlet in the other. You would think that such a bad setup would 1. give you a warning since it is badly posed if you solve for a single incompressible fluid, and 2. diverge/crash.

Instead we get a nice solution that is completely unphysical.

Setting up a problem in Fluent takes a fraction of the time I need to setup a similar problem in OpenFOAM, this is likely due to lack of usage on my part but all experience and skill equal I think Fluent is much faster in order to setup random problems.

Parallel licensing is the biggest issue for me at the moment, and I don't see that problem being solved any time soon, so open source software definitely have its place there.

[arjun]

Originally Posted by Simbelmynë

Fluent allows for some insane system setups. Try running an incompressible case with a pipe that is blocked in one end and has a velocity inlet in the other. You would think that such a bad setup would 1. give you a warning since it is badly posed if you solve for a single incompressible fluid, and 2. diverge/crash.

May be you but I would not.
You think you are solving a "physical" case for solver its just a model with some boundary condition. If it solution existed it would give you that. If you set up meaningless case meaningless solution you get. Solver can not check everything.

Further, i doubt openfoam would be able to tell you when the set will give you "physical" solution that you look for.


May be users shall take some responsibility too.

[Simbelmynë]

Originally Posted by arjun

May be you but I would not.
You think you are solving a "physical" case for solver its just a model with some boundary condition. If it solution existed it would give you that. If you set up meaningless case meaningless solution you get. Solver can not check everything.

Further, i doubt openfoam would be able to tell you when the set will give you "physical" solution that you look for.


May be users shall take some responsibility too.

OK, perhaps this example was a bit extreme, but it goes along the lines that Fluent is very "stable" and always gives you a solution. Of course you can (and perhaps should) blame the modeler and not the model, but there are different levels of understanding in all people using the software and some fail-safes are very easy to implement (Fluent is doing a great job at that, compared to many open source software).

You say that a meaningless setup would yield a meaningless result, but then you just blame all bad results on user input and never question the software itself. Perhaps you wish to purchase some of my at-home-developed codes? After all, if they give poor results it is just bad setup from your part, right? (Yes, yes I agree that the user should take some responsibility too)

Going back to the example, I have a very hard time understanding how a result can be produced at all. How can there be monotone convergence when it is impossible to satisfy the global continuity constraint?

Lastly, I do not advocate either Fluent or OpenFOAM. I mostly use Fluent since I have access to it and also because I am lazy (I also mostly use GUI based operating systems for the same reasons). So perhaps I should also add the GUI to my list of positives with commercial software.

[cfdnewbie]

Originally Posted by arjun

May be you but I would not.
You think you are solving a "physical" case for solver its just a model with some boundary condition. If it solution existed it would give you that. If you set up meaningless case meaningless solution you get. Solver can not check everything.

hello all,
I disagree with that statement - if an numerical scheme can provide a stable solution to an ill-posed problem, then if and only if some major stabilization / diffusion goes on behind the scenes which regularizes the problem to such a great extent that becomes well-posed, but its solution meaningless. There are ways of detecting convergence problems or ill-posedness rather quickly, and it is not clear to me why commercial solvers do not employ them. I speculate that it is to keep the calls to their user support hotline down.

If a solver returns a solution no matter what you throw at it, then each solution has the potential to be garbage and is nothing but a colorful picture. I would much rather prefer a crashed solution than a wrong one!

[FMDenaro]

Originally Posted by Simbelmynë

Fluent allows for some insane system setups. Try running an incompressible case with a pipe that is blocked in one end and has a velocity inlet in the other. You would think that such a bad setup would 1. give you a warning since it is badly posed if you solve for a single incompressible fluid, and 2. diverge/crash.

Instead we get a nice solution that is completely unphysical.

Setting up a problem in Fluent takes a fraction of the time I need to setup a similar problem in OpenFOAM, this is likely due to lack of usage on my part but all experience and skill equal I think Fluent is much faster in order to setup random problems.

Parallel licensing is the biggest issue for me at the moment, and I don't see that problem being solved any time soon, so open source software definitely have its place there.

to tell the truth, I am not sure about your example...it seems your fluent solution is giving almost the quiet state ....

[FMDenaro]

Originally Posted by cfdnewbie

hello all,
I disagree with that statement - if an numerical scheme can provide a stable solution to an ill-posed problem, then if and only if some major stabilization / diffusion goes on behind the scenes which regularizes the problem to such a great extent that becomes well-posed, but its solution meaningless. There are ways of detecting convergence problems or ill-posedness rather quickly, and it is not clear to me why commercial solvers do not employ them. I speculate that it is to keep the calls to their user support hotline down.

If a solver returns a solution no matter what you throw at it, then each solution has the potential to be garbage and is nothing but a colorful picture. I would much rather prefer a crashed solution than a wrong one!

I agree that is much better a crashing solution rather than a converged and totally wrong solution...but no commercial codes would be successfully commercialized...

[cfdnewbie]

Originally Posted by FMDenaro

I agree that is much better a crashing solution rather than a converged and totally wrong solution...but no commercial codes would be successfully commercialized...

I think you hit the nail on the head!

[arjun]

Originally Posted by cfdnewbie

hello all,
I disagree with that statement - if an numerical scheme can provide a stable solution to an ill-posed problem, then if and only if some major stabilization / diffusion goes on behind the scenes which regularizes the problem to such a great extent that becomes well-posed, but its solution meaningless. There are ways of detecting convergence problems or ill-posedness rather quickly, and it is not clear to me why commercial solvers do not employ them. I speculate that it is to keep the calls to their user support hotline down.

If a solver returns a solution no matter what you throw at it, then each solution has the potential to be garbage and is nothing but a colorful picture. I would much rather prefer a crashed solution than a wrong one!

You have to demonstrate that despite setting up the solver properly and having no mesh related issues a commercial solver provide you a bogus solution.

I contest this point because as a developer (when i worked at adapco) I looked at the code step by step for navier stokes and could not find a single place where an error is introduced.

Also one need to demonstrate that commercial solver gives you solution no matter what. I can provide a case that very likely to blow fluent in within 5 iterations. (with 6.3 it did)

Being commercial code does not guarantee that code is always stable.

Basically both the basic assumptions are not true.

[arjun]

Originally Posted by cfdnewbie

I think you hit the nail on the head!

Nobody debating otherwise. Somebody made a comment without proving it and people going gaga over it.

[cfdnewbie]

Originally Posted by arjun

I contest this point because as a developer (when i worked at adapco) I looked at the code step by step for navier stokes and could not find a single place where an error is introduced.

There might be no errors in the code, although that seems unlikely, but that was not my point. The numerical schemes used are just often so dissipative (first order or TVD) that they are stable by design - anything can be made stable with enough damping, and low order commercial solvers are horribly diffusive. That's why they work well for RANS, but not DNS (or meaningful LES).

So a bug-free dissipative code can be stable and still produce completely bogus results.

Commercial codes have their place, no doubt, but also grave limitations by design. It would be nice to see a high order code...

[arjun]

Originally Posted by cfdnewbie

There might be no errors in the code, although that seems unlikely,

In the SIMPLE algorithm. No, there is none. This is what I studied.

Originally Posted by cfdnewbie

There might be no errors in the code, although that seems unlikely, but that was not my point. The numerical schemes used are just often so dissipative (first order or TVD) that they are stable by design - anything can be made stable with enough damping, and low order commercial solvers are horribly diffusive. That's why they work well for RANS, but not DNS (or meaningful LES).

So a bug-free dissipative code can be stable and still produce completely bogus results.

Commercial codes have their place, no doubt, but also grave limitations by design. It would be nice to see a high order code...

And open source does not have all these issues. Can you name one code that does not have all these issues.

Just because a code is stable it does not mean it has all that extra-dissipation that you talk of. There are many ways code is made stable and stablity may have to do with how final result is achieved and not what final result look like.

If you are arguing that if a code is more stable then it produces wrong results then I am sorry you are wrong.

[Simbelmynë]

Originally Posted by FMDenaro

to tell the truth, I am not sure about your example...it seems your fluent solution is giving almost the quiet state ....

Could you please define "the quiet state"? I have a hard time finding relevant information about it when I Google.

[cfdnewbie]

Originally Posted by arjun

In the SIMPLE algorithm. No, there is none. This is what I studied.

Well, that is not very modest then but ok, that might be the case. But then you have checked just a part of the discretization, and maybe 5% of the lines of code. Just guessing, and that is not the topic here.

And open source does not have all these issues. Can you name one code that does not have all these

Pyfr, hifiles, nek5000, nektran and many more.

Just because a code is stable it does not mean it has all that extra-dissipation that you talk of. There are many ways code is made stable and stablity may have to do with how final result is achieved and not what final result look like.

Can you name some? Also I am not saying that stability equals dissipation. But dissipation is the easiest way to achieve boundedness.

If you are arguing that if a code is more stable then it produces wrong results then I am sorry you are wrong.

i am not. I am arguing that typically, commercial codes are at most second order FV TVD codes, and there is no arguing that theses schemes are dissipative. Here is a simple test case: compute the Taylor Green vortex at Re=1600 with 64 ^3 DOF and compare the results. Or google "workshop on high order cfd", do one of the test cases and check against reference results. You will find that the results with most commercial codes are orders of magnitude less accurate for scale resolving simulations.

Commercial codes are good for certain problems, but inappropriate for others. That shouldnt be too hard to accept.

[FMDenaro]

Originally Posted by Simbelmynë

Could you please define "the quiet state"? I have a hard time finding relevant information about it when I Google.

the inlet flow rate appears quite low, such to be like producing a flow at rest... have you fixed a velocity inlet profile producing a greater flow rate? does it still work?

[mprinkey]

I am going to disagree with the general sentiment in this thread. Let's disabuse ourselves of the notion that we are "solving the Navier Stokes equations." CFD codes, at best, attempt to find within a limited set of degrees of freedom resolved to some finite precision some combination that approximates a solution of Navier Stokes and boundary conditions. If you specify a set of boundary conditions that are ill-posed *for the continuous problem*, how can you be in anyway critical of the numerical solution that doesn't meet those ill-posed constraints? You will get whatever you get? And that is not a question of 1st-order, TVD, WENO, Spectral...the continuous problem has no answer--no approximation of the continuous problem to the n-th order will fix that.

Try a similar but simpler test--run different linear equations solvers against a matrix that is singular. Is LU factorization with pivoting superior because it can identify an invalid pivot and error out versus an iterative method that just wanders around trying to find an answer that isn't there? It is really a pointless question...like (literally) asking which is better at dividing by zero.

Of course, you could argue that CFD codes should preprocess the problem setup to identify physical inconsistencies like this, but I don't think that can be categorized as code failure--that would just be a sanity check against incorrect usage of the tool.

What I see in those Fluent results are basically a "least-squares" best attempt to satisfy the incompatible boundary conditions and the governing equations. Is it unphysical? Of course. But it is as valid a solution to an ill-posed problem as any other, I suppose. Those surface integrals are not damning at all, in my opinion--they arise completely from the BC specification. The walls are zero flux--those face fluxes perfectly sum to zero because the BCs define them that way. The velocity inlet condition for incompressible flow is equivalent to specifying the mass flux on that boundary. Those sums are just a regurgitation of the BC settings and are unaffected by the solution in bulk.

The most problematic issue with Fluent here is the residuals...specifically the normalization of the residuals. This is a problem in all computational science problems...how do you extract physical meaning from those numbers and use it to estimate accuracy...10^-3, 10^-4, 10^-6 convergence is not meaningful apart from careful understanding of how those residuals are normalized. Residual normalization is really more heuristic in nature than mathematical...the schemes used to normalize residuals tend to work pretty well, but in this ill-posed case, they fail.

Full disclosure: I was a developer at Fluent in a previous life, so I might be a little touchy here. 8)

[arjun]

Originally Posted by cfdnewbie

Well, that is not very modest then but ok, that might be the case. But then you have checked just a part of the discretization, and maybe 5% of the lines of code. Just guessing, and that is not the topic here.

It is nothing to do with being modest or not. I was developer for segregated flow model and I spend 3 months making sure I understand what starccm does. I went through it line by line and wrote down what ccm does. And no did not see there was bug. Later for various bugs reported by users had to go through it many times and never could point finger to bug in segregated flow model.

Starccm has bugs like any other code, but that was not point I made.

Originally Posted by cfdnewbie

Pyfr, hifiles, nek5000, nektran and many more.
.

So basically your point is that if first order scheme is used in them then it some how becomes more accurate in these codes but same first order scheme in fluent ccm will be less accurate because these codes are more stable.

These schemes behaviour remains the same what so ever is the code.

Originally Posted by cfdnewbie

Can you name some? Also I am not saying that stability equals dissipation. But dissipation is the easiest way to achieve boundedness.
.

But it does not implies that commercial codes use this to keep it stable.
Here is the thing, starccm mentions exactly what it looks like in descretised form in their document. There is no hidden dissipation.

The extra dissipation that could be applied is called delta v dissipation in case of starccm and that is given to user as an option and is switched off by default.
You can switch it on but still in current versions it is only applied to porous medium.

You know why it is so. Because people who work there also know that extra dissipation can create bogus results. When this was on by default their user let them know too.

Dont think that people who work at fluent etc do not understand cfd.

Originally Posted by cfdnewbie

i am not. I am arguing that typically, commercial codes are at most second order FV TVD codes, and there is no arguing that theses schemes are dissipative. Here is a simple test case: compute the Taylor Green vortex at Re=1600 with 64 ^3 DOF and compare the results. Or google "workshop on high order cfd", do one of the test cases and check against reference results. You will find that the results with most commercial codes are orders of magnitude less accurate for scale resolving simulations.

Commercial codes are good for certain problems, but inappropriate for others. That shouldnt be too hard to accept.

Nobody is arguing that higher order schemes are more accurate or there are schemes which are less dissipative etc.

Read the thread again.

A more dissipative code could be made more stable. (No arguments here)

A more stable code is more dissipative and thus can create bogus results. (May not be true, because there are various forms of stability , some of them do not affect final result simple example under-relaxation -> stable, no effect on final result) .

or
a less stable code is more accurate. (Again not true).

[arjun]

Originally Posted by mprinkey

I am going to disagree with the general sentiment in this thread. Let's disabuse ourselves of the notion that we are "solving the Navier Stokes equations." CFD codes, at best, attempt to find within a limited set of degrees of freedom resolved to some finite precision some combination that approximates a solution of Navier Stokes and boundary conditions. If you specify a set of boundary conditions that are ill-posed *for the continuous problem*, how can you be in anyway critical of the numerical solution that doesn't meet those ill-posed constraints? You will get whatever you get? And that is not a question of 1st-order, TVD, WENO, Spectral...the continuous problem has no answer--no approximation of the continuous problem to the n-th order will fix that.

Exactly.


djshsjkhskjhdjksahdjkahsdjkahdkjhadsjk

[cfdnewbie]

Originally Posted by mprinkey

I am going to disagree with the general sentiment in this thread. Let's disabuse ourselves of the notion that we are "solving the Navier Stokes equations." CFD codes, at best, attempt to find within a limited set of degrees of freedom resolved to some finite precision some combination that approximates a solution of Navier Stokes and boundary conditions. If you specify a set of boundary conditions that are ill-posed *for the continuous problem*, how can you be in anyway critical of the numerical solution that doesn't meet those ill-posed constraints? You will get whatever you get? And that is not a question of 1st-order, TVD, WENO, Spectral...the continuous problem has no answer--no approximation of the continuous problem to the n-th order will fix that.

That's true, but not the point - I believe - we are discussing here. If the BCs are ill-posed for the continuous problem AND the numerical scheme is consistent in its implementation of both the solution and the IC/BC, then it should not converge (at least in an h-convergence sense). Either it converges to the "true" (non-existent / ill-posed) solution and blows up, or it converges to some bogus solution by non-consistent (in the sense that the nature of the BCs in terms of characteristics can be lost due to excessive numerical errors) implementation.

What I see in those Fluent results are basically a "least-squares" best attempt to satisfy the incompatible boundary conditions and the governing equations. Is it unphysical? Of course. But it is as valid a solution to an ill-posed problem as any other, I suppose. Those surface integrals are not damning at all, in my opinion--they arise completely from the BC specification. The walls are zero flux--those face fluxes perfectly sum to zero because the BCs define them that way. The velocity inlet condition for incompressible flow is equivalent to specifying the mass flux on that boundary. Those sums are just a regurgitation of the BC settings and are unaffected by the solution in bulk.

I agree. But again, this is not the point I was trying to make. Ill-posednes is not a problem of the numerics, but of the guy using it.

The most problematic issue with Fluent here is the residuals...specifically the normalization of the residuals. This is a problem in all computational science problems...how do you extract physical meaning from those numbers and use it to estimate accuracy...10^-3, 10^-4, 10^-6 convergence is not meaningful apart from careful understanding of how those residuals are normalized. Residual normalization is really more heuristic in nature than mathematical...the schemes used to normalize residuals tend to work pretty well, but in this ill-posed case, they fail.

total agreement. One can always ask: "drop of 3 orders of magnitude...but from WHERE? What is the significance of the reference / normalization state w.r.t. the accuracy of the solution?

Full disclosure: I was a developer at Fluent in a previous life, so I might be a little touchy here. 8)

Nice to have someone with real experience here! As I said, commercial codes are useful, but just not for everything.
I am curious: what is under the hood in terms of spatial discretization in fluent? Is it 1st order FV with Jameson's central flux with 4th order dissipation still?

Thank you for your comments!