[Simbelmynë]

Originally Posted by FMDenaro

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?

Increased velocity to traverse domain in 5 seconds (u=0.1 m/s and L=0.5 m)

[cfdnewbie]

Originally Posted by arjun

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.

. Ok.

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.

No, not at all. Just saying that first order (upwind) schemes are too dissipative to be of good use for anything but steady, laminar flow - and discontinuities.

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

agreed!

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.

I am not saying that they add an extra diffusion term. All I am saying the baseline scheme is highly dissipative.

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.

I dont. As a matter of fact, I think that they know exactly what they are doing. Using a dissipative scheme as a baseline is perfectly ok from a practical standpoint. But other options (see above and the main topic of this thread) exists and gain more and more attention, because non-dissipative schemes have some nice properties.

(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) .

Now we are mixing spatial discretization with solver converge for steady state...

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

That wasnt said or implied. Low order codes are good at some stuff, and suck at other stuff. If you want to solve engineering everyday problems, use commercial stuff. If you want to do physics, use other codes. If you want to do something inbetween, do some reading and decide for yourself.

Do not try to compute the flow around an F-15 at Mach 3 with chemical reaction with a global spectral scheme, and do no do turbulence in a box with a commercial solver.

Live and let live!

[FMDenaro]

Originally Posted by Simbelmynë

Increased velocity to traverse domain in 5 seconds (u=0.1 m/s and L=0.5 m)

ok, did the same happen setting the fractional step (projection method)?

[FMDenaro]

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.

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)

I am not sure about this issue... Assuming you have the previous case of the closed channel with one inflow, a solution for the continuous problem does not exist because the compatibility relation is not satisfied. Therefore, I wonder what in the discrete approximated model changed in such a way to allow for the existence of a solution. That is not a sanity check, it simply should not work. I assume that the key is that the discrete pointwise div V = 0 constraint is relaxed, simulating a slow compressible solution. If you set this constraint at machine precisione, Fluent must not give a discrete solution.

[jmdf]

I have been working with openFoam for a year now and I can see a lot of potential inside it.

Truth is that getting comfortable with openFoam takes a lot of time, things like working with no GUI and very poor documentation makes it even hard. Although I would say that this is the price to pay to have such complete open source library with no licence needed.

Regarding commercial CFD solvers I see them as having what the industry needs. Despite of how it is done and what kind of things the code does to make the solution converge, it gives fast results with relatively ease of setting up everything form pre to post-processing. I am not very experienced with commercial CFD so this is just my opinion.

Do you think openFoam is, at the moment, ready to heavy industrial use?

[Simbelmynë]

Originally Posted by FMDenaro

ok, did the same happen setting the fractional step (projection method)?

Tried it now (transient) and the results are at least qualitatively the same.

[FMDenaro]

Originally Posted by Simbelmynë

Tried it now (transient) and the results are at least qualitatively the same.

that sounds really strange....it should not converge...could you plot the div v field?

[Simbelmynë]

Originally Posted by FMDenaro

that sounds really strange....it should not converge...could you plot the div v field?

The mass imbalance can be seen in the figure.

[FMDenaro]

Originally Posted by Simbelmynë

The mass imbalance can be seen in the figure.

is practically zero everywhere, it is not possible ... could you check directly only the div v field?

[Simbelmynë]

Originally Posted by FMDenaro

is practically zero everywhere, it is not possible ... could you check directly only the div v field?

Nice to see that this confuses more than just myself. Bogus setup yields bogus result, but in this case it should really not yield any result. I will see if I can plot the div v field.

[mprinkey]

Turn off "Node Values." You want to see the actual cell value of the mass imbalance, not the values interpolated to the nodes and then linearly interpolated to the plot.

I reiterate. The mass imbalance shown in the onscreen report is SOLELY a function of the defined boundary conditions, in this case. All of BCs are fixed flux--the value of the mass fluxs through all of the faces are set to those values:

MASSFLUX[wallFaces] = 0.0.
MASSFLUX[velocityInletFaces] = prescribedNormalVelocity*prescribedDensity

So, if you integrate over those BCs, you get back exactly what you prescribed! The flux reports just adds up the MASSFLUX times the face AREA over a given boundary.

forFace(f,wallFaces):
    sum += MASSFLUX[f]*AREA[f]

Nothing being added up there comes from the solver. That is all based on your inputs. Wrong input -> wrong output.

Again, I am not here to speak for ANSYS. . If you want to know what the codes are doing, read the manual. Fluent's documentation on its discretization schemes is quite thorough and consistent with what I saw in the code.

[mprinkey]

Originally Posted by FMDenaro

I am not sure about this issue... Assuming you have the previous case of the closed channel with one inflow, a solution for the continuous problem does not exist because the compatibility relation is not satisfied. Therefore, I wonder what in the discrete approximated model changed in such a way to allow for the existence of a solution. That is not a sanity check, it simply should not work. I assume that the key is that the discrete pointwise div V = 0 constraint is relaxed, simulating a slow compressible solution. If you set this constraint at machine precisione, Fluent must not give a discrete solution.

No, this isn't the case. The code is iterating to try to minimize the residuals. In a well-posed problem, the mass imbalance (div V) should be zero everywhere, pressure corrections go to zero, and everything is fine. In this case, the mass balance is not zero, so the mass residual has a non-zero floor value. The code is trying its best to minimize that mass residual based on some norm. It is likely L2 (I don't remember), so it is trying to spread the mass error out evenly over the cells thus creating the "solution" shown. That is why I said we need to get over this idea that we are solving Navier Stokes. We are actually just coming up with an answer that tries to minimize some error norms of the discrete problem. That answer shown is the best that Fluent (and, I suspect any CFD code) can do for this ill-posed system. The only issue here is that Fluent declares the problem converged.

As this problem is posed, the pressure equation has no solution. That is obvious...just assume the entire domain meshed with one cell. Nothing but BCs on the cell faces. Div v != 0. You can subdivide that cell and build a pressure field inside, but its solution is meaningless with regard to the continuous problem. You can't find a pressure field that will make div v = 0 everywhere. But you CAN find a pressure field that minimizes the error norm of the mass imbalance and that is what Fluent is doing. Maybe if LU factorization with pivoting were applied to that pressure equation, it would find a zero pivot and error out. But any real CFD is going to use iterative linear solvers, and those are all designed to relax solutions to reduce some error norm. It is doing exactly what it is supposed to.

I will say that all real CFD codes that do anything much harder than simple pressure/density/velocity solutions will have tweaks in them to keep the solution sane, especially during the early stages of iteration. "Turbulent viscosity limited to 1e5 of laminar viscosity" is a common Fluent limit that is hit. I wrote some electrochemistry code many years ago, and when it started, the concentration of reactants was high with no products (from initialization) and I would see MEGA-AMP currents in my fuel cell models. That needed to be tamped down to keep the solution sane. The list of these is long, especial if you start doing anything with multiphase, reacting flows, or radiation. But those guide rails exist solely to keep the solution on track and will not be active as the solution reaches convergence. (keep density positive, keep mass fractions between 0 and 1, etc) They make CFD codes more robust and let you get an answer instead of NaNs or division by zero errors.

[FMDenaro]

Originally Posted by mprinkey

No, this isn't the case. The code is iterating to try to minimize the residuals. In a well-posed problem, the mass imbalance (div V) should be zero everywhere, pressure corrections go to zero, and everything is fine. In this case, the mass balance is not zero, so the mass residual has a non-zero floor value. The code is trying its best to minimize that mass residual based on some norm. It is likely L2 (I don't remember), so it is trying to spread the mass error out evenly over the cells thus creating the "solution" shown. That is why I said we need to get over this idea that we are solving Navier Stokes. We are actually just coming up with an answer that tries to minimize some error norms of the discrete problem. That answer shown is the best that Fluent (and, I suspect any CFD code) can do for this ill-posed system. The only issue here is that Fluent declares the problem converged.

As this problem is posed, the pressure equation has no solution. That is obvious...just assume the entire domain meshed with one cell. Nothing but BCs on the cell faces. Div v != 0. You can subdivide that cell and build a pressure field inside, but its solution is meaningless with regard to the continuous problem. Maybe if LU factorization with pivoting were applied to that pressure equation, it would find a zero pivot and error out. But any real CFD is going to use iterative linear solvers, and those are all designed to relax solutions to reduce some error norm. It is doing exactly what it is supposed to.

I will say that all real CFD codes that do anything much harder than simple pressure/density/velocity solutions will have tweaks in them to keep the solution sane, especially during the early stages of iteration. "Turbulent viscosity limited to 1e5 of laminar viscosity" is a common Fluent limit that is hit. I wrote some electrochemistry code many years ago, and when it started, the concentration of reactants was high with no products (from initialization) and I would see MEGA-AMP currents in my fuel cell models. That needed to be tamped down to keep the solution sane. The list of these is long, especial if you start doing anything with multiphase, reacting flows, or radiation. But those guide rails exist solely to keep the solution on track and will not be active as the solution reaches convergence. (keep density positive, keep mass fractions between 0 and 1, etc) They make CFD codes more robust and let you get an answer instead of NaNs or division by zero errors.

sorry, I still do not understand your point....
let me follow your example, the single cell covering all the domain. the constraint div v= 0 implies that int [S] vn ds = 0. That is not verified (vn at inflow is not zeor) and Fluent cannot minimize nothing in the interior...
On the other hand, in a FV discretization, the telescopic property of the numerical fluxes, reduces still the mass conservation consistence at the boundaries...
Again, in the incompressiblem model, the Poisson equation has a solution provided that the compatibility relation is fulfilled. This property must be ensured not only in the continuous form but is fundamental also in the discrete form. Conversely, the fractional step method (projection) still works...
I am sure that something in the Fluent computation is not known to me...

[mprinkey]

Originally Posted by FMDenaro

sorry, I still do not understand your point....
let me follow your example, the single cell covering all the domain. the constraint div v= 0 implies that int [S] vn ds = 0. That is not verified (vn at inflow is not zeor) and Fluent cannot minimize nothing in the interior...
On the other hand, in a FV discretization, the telescopic property of the numerical fluxes, reduces still the mass conservation consistence at the boundaries...
Again, in the incompressiblem model, the Poisson equation has a solution provided that the compatibility relation is fulfilled. This property must be ensured not only in the continuous form but is fundamental also in the discrete form. Conversely, the fractional step method (projection) still works...
I am sure that something in the Fluent computation is not known to me...

Let me come at this differently. There is a mass defect in the system, M, that is equal to the integral of the mass flux over the boundaries. By the FV method, what flows out of one cell must flow into another, so there is conservation between cells. The mass imbalance in a given cell is div v integrated over the cell and is the sum of the mass fluxes of each of the cell's faces. In a well posed problem at convergence, the mass imbalance (div v) will be zero in every cell. In this ill-posed case, it cannot be. Because the volume integral of the mass imbalance must equal M. Mass can't be lost between cells...it can only be lost INSIDE cells via the mass imbalance. So, there is a mass imbalance field...that is (within scaling factors) equivalent to the pressure residual. So, we build that pressure equation and give it to the iterative solver. The solver is effectively trying to make the L2 of div v as small as possible. That implicitly means making the mass imbalance spread as evenly as possible over the cells--that is how you minimize L2, right...smooth the defects out. So, mass defect is spread out over the cells and a velocity field is established to distribute the mass defect among the cells. But the value of the mass imbalance (and pressure residual) cannot go to zero because it has to all integrate to match the mass defect. The pressure residual will have a floor, even in the linear equation solver.

The confusion here may arise because, unlike fractional step, the pressure equation here is not being solved to high precision for each iteration/timestep. Normally, in SIMPLE, you only iterate each linear equation solver enough to reduce the error norm by a factor of 0.1-0.001. It is inefficient to "over-solve" linear systems as the nonlinear error is what we are trying to drive down--the linear solvers just give us successive corrections to that nonlinear error. If the error tolerance for the linear solver of the pressure equation were reduced, you will likely find that the linear solver can't converge because it cannot get the L2 norm any lower due to the presence of the mass defect.

Your criticisms are valid, but they are likely criticisms of SIMPLE-type solvers and common CFD practice moreso than Fluent in particular. And, again, we are looking at a failure mode that exists because of user error--a car doesn't run very well if you try to drive it on a lake. 8)

[FMDenaro]

Originally Posted by mprinkey

Let me come at this differently. There is a mass defect in the system, M, that is equal to the integral of the mass flux over the boundaries. By the FV method, what flows out of one cell must flow into another, so there is conservation between cells. The mass imbalance in a given cell is div v integrated over the cell and is the sum of the mass fluxes of each of the cell's faces. In a well posed problem at convergence, the mass imbalance (div v) will be zero in every cell. In this ill-posed case, it cannot be. Because the volume integral of the mass imbalance must equal M. Mass can't be lost between cells...it can only be lost INSIDE cells via the mass imbalance. So, there is a mass imbalance field...that is (within scaling factors) equivalent to the pressure residual. So, we build that pressure equation and give it to the iterative solver. The solver is effectively trying to make the L2 of div v as small as possible. That implicitly means making the mass imbalance spread as evenly as possible over the cells--that is how you minimize L2, right...smooth the defects out. So, mass defect is spread out over the cells and a velocity field is established to distribute the mass defect among the cells. But the value of the mass imbalance (and pressure residual) cannot go to zero because it has to all integrate to match the mass defect. The pressure residual will have a floor, even in the linear equation solver.

The confusion here may arise because, unlike fractional step, the pressure equation here is not being solved to high precision for each iteration/timestep. Normally, in SIMPLE, you only iterate each linear equation solver enough to reduce the error norm by a factor of 0.1-0.001. It is inefficient to "over-solve" linear systems as the nonlinear error is what we are trying to drive down--the linear solvers just give us successive corrections to that nonlinear error. If the error tolerance for the linear solver of the pressure equation were reduced, you will likely find that the linear solver can't converge because it cannot get the L2 norm any lower due to the presence of the mass defect.

Your criticisms are valid, but they are likely criticisms of SIMPLE-type solvers and common CFD practice moreso than Fluent in particular. And, again, we are looking at a failure mode that exists because of user error--a car doesn't run very well if you try to drive it on a lake. 8)

ok, so the question is: why setting the fractional step method produces the same kind of solution instead of crashing?? In this case there is no other possibility that driven the pressure equation at convergence at each time step. That should not work starting from the first time step...

[Simbelmynë]

Originally Posted by mprinkey

The confusion here may arise because, unlike fractional step, the pressure equation here is not being solved to high precision for each iteration/timestep. Normally, in SIMPLE, you only iterate each linear equation solver enough to reduce the error norm by a factor of 0.1-0.001. It is inefficient to "over-solve" linear systems as the nonlinear error is what we are trying to drive down--the linear solvers just give us successive corrections to that nonlinear error. If the error tolerance for the linear solver of the pressure equation were reduced, you will likely find that the linear solver can't converge because it cannot get the L2 norm any lower due to the presence of the mass defect.

Your criticisms are valid, but they are likely criticisms of SIMPLE-type solvers and common CFD practice moreso than Fluent in particular. And, again, we are looking at a failure mode that exists because of user error--a car doesn't run very well if you try to drive it on a lake. 8)

But I ran the case with the fractional step method in Fluent as well. Also, the residuals were lowered by 1e-6 in the SIMPLE example, and when continued they flatten out at 4e-15 (see figure).

[mprinkey]

Originally Posted by FMDenaro

ok, so the question is: why setting the fractional step method produces the same kind of solution instead of crashing?? In this case there is no other possibility that driven the pressure equation at convergence at each time step. That should not work starting from the first time step...

You are talking about the NITA solver in Fluent of fractional step in general? I ask only because I haven't used or worked on NITA. It was fairly new around the time I left. I probably doesn't matter, but just for clarity.

If we view fractional step "pressure-like" variable phi as a projection mechanism that removes the div v component.

vCorrected = v - grad(phi)

, so find phi s.t.

div(vCorrected) = 0

then the situation is the same. I think it doesn't even matter if you do a velocity update. A phi field cannot be found that corrects any velocity field to be divergence free with these boundary conditions.

The question is then what is the error tolerance with the fractional step method? How is that error tolerance normalized? Is it kg/s or kg/s/m^3. Some code normalize linear error versus the residual. Fractional step in this case could be building a velocity field that has huge mass imbalance and the solver normalizes to that big residual and reduces it down to some level and stops.

If you look at real mass imbalance as the metric of phi convergence (kg/s/m^3) and look at it relative to the mass defect (kg/s) for the system divided by the solution volume, you should see that there is a floor to that residual at that scale. Sorting this out requires getting deep into the weeds about normalization of both linear and nonlinear error and again, it is putting linear equation solvers in the position of finding a minimum error solution to singular problem.

[mprinkey]

Originally Posted by Simbelmynë

But I ran the case with the fractional step method in Fluent as well. Also, the residuals were lowered by 1e-6 in the SIMPLE example, and when continued they flatten out at 4e-15 (see figure).

I don't know if I can help with this. I'd didn't spend any time working on the NITA parts of the code. My assertion remains that the linear system for pressure/mass imbalance is singular and the residual limits on the LINEAR solvers may need to be set very low in order to see it. But I don't speak for ANSYS.

If you remain concerned that Fluent is "cooking the books" with mass conservation here, I'd direct those concerns to your support engineer and they can have a developer take a look. My suspicion is that it will go something like:

Q: "It gives me garbage answers when I give it an ill-posed problem."
A: "So, don't give it ill-posed problems."

Developers are jerks that way. 8)

[FMDenaro]

Originally Posted by mprinkey

I don't know if I can help with this. I'd didn't spend any time working on the NITA parts of the code. My assertion remains that the linear system for pressure/mass imbalance is singular and the residual limits on the LINEAR solvers may need to be set very low in order to see it. But I don't speak for ANSYS.

If you remain concerned that Fluent is "cooking the books" with mass conservation here, I'd direct those concerns to your support engineer and they can have a developer take a look. My suspicion is that it will go something like:

Q: "It gives me garbage answers when I give it an ill-posed problem."
A: "So, don't give it ill-posed problems."

Developers are jerks that way. 8)

yes, I was talking about the NITA solver.... it is quite simple to see that it is based on the solution of the Hodge decomposition

v* = v + Grad phi

with prescribed normal component on the boundary
vn* = vn + d phi/dn

Therefore the pressure equation is

Div Grad Phi = Div v*

with d phi/dn = vn* - vn on the boundaries.

You can easily see that convergence of a linear system solver for this pressure problem is obtained provided that int [S] vn dS = 0. Therefore, I expect Fluent giving a message to the user ....

If that is not the case, I don't know what NITA would really solve....

[mprinkey]

Originally Posted by FMDenaro

You can easily see that convergence of a linear system solver for this pressure problem is obtained provided that int [S] vn dS = 0. Therefore, I expect Fluent giving a message to the user ....

If that is not the case, I don't know what NITA would really solve....

Yeah, I don't know anything about the NITA solver other than what you do. I think it is normalization of the pressure residual for the MG solver that is the culprit. If you turn up the verbosity on the AMG solver, it should show iteration by iteration what the residual is. From that, it should be possible to determine exactly how those residuals relate to the mass defect norm. As I said, this requires getting into the weeds.