[aja1345]

Hi,

As I explained in the my previous threads, I designed a turbine and Now I am simulating expressed turbine in fluent. But solution is not converged. I changed under-relaxation factors and discretization schemes, but I don't know that why solution is not converged. Case and Data files are placed in the following link, I am really grateful that you check these files and guide me and If It is possible, please place useful links about this problem until we can converge this simulation.

http://www.4shared.com/rar/klHltuXVba/Amir88-BC3.html

My tool of simulation is a Laptop(Fujitsu) with 6 G ram and core i7 CPU 2.2GHZ.

really thanks,

Best,

Amir

[CeesH]

How did you decide the simulation did not converge?

[aja1345]

Originally Posted by CeesH

How did you decide the simulation did not converge?

Hi,

because take to long time.

In fact, solution is not divergent but I think that this process is very long time. and I can't reach to convergence. How can I reach to convergence rapidly? I think that Values of under-relaxation factors and discretization schemes are not correct.

Thanks

[CeesH]

But how do you judge whether the simulation converged or not? That has nothing to do with time. You need to have some basis on which you say, now the outcome has converged, or it has not (and will not). So how did you decide that? What is your criterion for convergence?

[aja1345]

Originally Posted by CeesH

But how do you judge whether the simulation converged or not? That has nothing to do with time. You need to have some basis on which you say, now the outcome has converged, or it has not (and will not). So how did you decide that? What is your criterion for convergence?

Hi,

what is your exact meaning of 'That has nothing to do with time'?

I don't judge and I am New in fluent. maybe It is converged or not converged. But what is important to me, It is converged rapidly. According to recent simulations in this case, It took to a long time. I placed case and data until you guide me about this problem. The criterion is 1e-6.

Thanks

[CeesH]

I mean that it can take a long time to converge a solution based on your mesh density, geometry, etc. But that doesn't mean that it does or does not converge. Convergence has nothing to do with time - either a solution converges or not. The thing is, at some point you may have to decide whether it is good enough, and/or if it's not yet good enough - if it's worth waiting any longer. When is it worth the wait? If you see the solution is still moving towards a certain answer. When is it not? if it's clearly oscillating around a certain value, and not reducing in amplitude of oscillation. You can try to force that by playing with the under-relaxation factors - at the cost of speed. But sometimes it's clear that your solution will not get any closer to the solution.

Anyway, it is up to you to decide whether the solution is good enough or not. And never, ever, ever do that based on the residuals - they give some relative value. They are dependent on the quality of your initial guess, too, and they may depend on your problem. In some problems residuals of 1e-3 are more than sufficient, in others 1e-6 far from. Always judge convergence based on integral quantities. and specifically, integral quantities related to your problem at hand. A mean temperature or nusselt number if heat transfer is your point of interest, a mean velocity or power number if it's flow, a mixing time if it's mixing. Residuals, by themselves, are meaningless. And when is a solution converged? If the parameter of interest oscillates within less than 1%? less than 0.1%? It's up to you to decide - that's the job of a CFD engineer. You will have to judge that. Anyone can set up a simulation in FLUENT, and anyone can make a nice contour plot of that. But by far not everyone can judge whether that plot is meaningful, whether that solution makes sense, and whether it has converged. Luckily, otherwise we would not get paid as well as we do. But if you are not yet judging, you better start judging - and a good point to start is simply the 'convergence' section in the FLUENT manual.

Having said that, it seems your simulation is actually converging (although you should really judge that on something), but you just think it takes too long. So what is long? 1 hour? 10? 2 weeks? What you have to realize is that there are no shortcuts, there are no magic bullets and no quick fixes. Converging takes time, and is a matter of trade-offs. So I can give you guidelines, things to look at, but no conclusive answers.

In general, a denser mesh gives you a more accurate answer, a cruder mesh gives you an answer faster - but there's a risk the answer is not mesh independent (so, increasing the mesh density will give you a different answer), and perhaps that your solution will diverge or oscillate heavily - say more than 5% in velocity or power number despite being a steady state calculation.

When it comes to mesh quality, try to use hexahedral cells close to cubic in the bulk, and do local mesh refinement based on the expected gradients. A good mesh may speed up convergence significantly, but probably does mean spending more time in the mesh editor - once again, a tradeoff. And low quality meshes may again invoke divergence.

Under-relaxation factors are easy: lower values mean slower convergence but more stability, higher values vice-versa. My advice: start high, and if you observe oscillations in the solution, reduce them for stability. So, end low.

Futhermore, I say once again, track integral quantities, use other monitors than only residuals. Maybe you are waiting forever for your monitors to reach 10^-6, while there are no significant in the solution anymore below 10^-3 - so you can stop much earlier.

That's what I can say. Of course, you could think about playing with domain decomposition for parallel and so on, but I would start with the above and see how far you can get. I know you posted your files online, and yes, I could open them and give you more concrete advice - but I'm not going to. One because that costs me too much time, and two because you won't learn from it. In the end it's your simulation - you are the one that has to decide what is an acceptable runtime and what is an acceptable answer, and you will learn most from it if you make those decisions rather than letting someone else do that for you. And in the end I guess that is why you are here, to learn. So go out, play, and learn. Good luck!

[aja1345]

Hi Ceesh

Really thanks for your answer and indeed the explanation was helpful.

Now I understood your mean. In fact, I almost study many papers in this case and as an example, I know that a region of high pressure(static pressure) begins to extend near leading edge of the pressure surface at low flow coefficient and also stagnation point is very near to leading edge of the turbine blade at this low flow coefficients. As the flow coefficient increases, it moves towards mid-portion of the blade from leading edge.the high-pressure region at particular flow coefficientexceeds the position of maximum thickness of blade, and hence, causes the turbine to be about to start stall. In other words, static pressure is my point of interest. In general, my information is good about this type of turbine. I think that I can find convergence by means of studied papers. But here, I have a question:

If I understood that solution is correct based on static pressure, Is other parameter correct? For example, other parameter can be tangential velocity. As you say, I use other monitors for example 1e-3, then when solution is converged, I judge convergence based on static pressure(by using studied papers). If it was correct, It means that solution is convergence. In other words, If static pressure contour is validated with these papers, It means that solution is convergence. Is this work correct?

Another question:

According to your explanations, It is possible that a model is not meshed well(bad mesh), But solution will become convergence and will not become accurate.Correct?

In other words, any converged solution is not correct and also we should consider integral quantities and criterion is a particular value in different problems. Correct?


I want to know your opinion and I am grateful that guide me. I am sorry that I can't speak English well.

Thanks,

Best,

Amir

[CeesH]

There's a difference between a correct solution and a converged solution, and also a mesh-independent solution.

A converged solution means the solution doesn't change significantly anymore when adding more iterations. A mesh independent solution means that, increasing the mesh density further, the results will not change significantly anymore. A correct solution means the solution is well in agreement with experimental data. But these are three fully different things.

You should first strive for your solution to converge; so, make sure a stable answer without significant oscillations or changes over a number of iterations is found. Then the solution is converged, but it does not have to be correct, or mesh independent.

Then, check for mesh dependency: Does the solution change when you add more elements to the mesh? For example, say I have a stirred tank (because I happen to have one), and I have 5 meshes - checking for the power number. The meshes (1-5) have 100.000 - 500.000 elements in increases of 100.000. I may find the following:

1. 100.000 elements - Po = 3.5
2. 200.000 elements - Po = 4.7
3. 300.000 elements - Po = 5.2
4. 400.000 elements - Po = 5.4
5. 500.000 elements - Po = 5.45

Based on this data, I can say that increasing the mesh density from 400.000 to 500.000 elements does not make my solution very different. Hence, mesh 4 is good enough. For certain applications, mesh 3 might suffice too, but mesh 1 and 2 are certainly not good. So, with mesh 4 I checked the solution to be mesh independent. Now that I know that, I will continue to use mesh 4, and check if the solution is correct.

Now in literature I find a value of the power number for this setup, and it is 4.7 This means that although the solution on mesh 4 converged, and the solution is mesh independent - it is not correct. There is a big offset in power number! This indicates that the turbulence model I was using, or the discretization method I was using, cannot properly capture the physical behavior of the tank. Knowing this, I can look for a better physical model. (Note: The PO of 4.7 does not mean mesh 2 was better! In mesh 2 the solution was mesh-depending, so there is certainly an error there! In this case the physical and numerical error balance eachother making it look like the mesh does very well, but in fact, it does pretty bad!)

So to summarize, always work in this order.
if your solution does not coverge, there's no point in checking mesh dependency or physical accuracy.


if the solution converges but is not mesh independent, there's in no point in physical interpretation.


only if your solution converges and is sufficiently independent of the mesh, you can truly interpret the physical results.

[aja1345]

Under-relaxation factors are easy: lower values mean slower convergence but more stability, higher values vice-versa. My advice: start high, and if you observe oscillations in the solution, reduce them for stability. So, end low.

Hi Ceesh,

Really thanks for your guide, I fully realized. But another questions:

1. you said that i start high value, But how much? 0.3? or 0.7? etc.

If it is possible, please place useful links and papers about Under-relaxation factors.

2. what is your exact meaning of 'So, end low'? Is it means that I continue with low values?


I am grateful that guide me about values of Under-relaxation factors.

Thanks,

Best,

Amir

[CeesH]

Hi Amir,

It depends a bit on the situation you are modeling. Typically I just start with the default values for all factors, unless I know upfront that certain equations may be difficult to stabilize. For example in stirred tanks with radial impellers, I may start with 0.2 for momentum (following Andre Bakker, you can find some advice on www.bakker.org) if I know that I won't be around the computer for a while to check how convergence is going - because I know at some point I may have to alter the value.

Other than that, I suggest to start default, and if during the process you notice that one of the residuals gets 'stuck' (so is oscillating up and down without any general downward trend), reduce the underrelaxation factors. What I typically do for stirred tanks when I am around to change things, is start with momentum at 0.7 to make some fast first iterations, then after 2500 iterations change to 0.1 - 0.2 or so to finish more accurately. That's what I mean with start high, end low. I do not know of any papers discussion URFs at length, or at least, I never referenced them since they very much focus on the mathmatical implemenation, and I regard them more as a tool - so knowing the basic idea behind them suffices for me.

Also I'd recommend; if the URFs need to be below 0.1 for your simulation to converge, you probably need to change your mesh. Otherwise the solution is going to take very long at best, and probably won't converge at all. This is no hard limit or so, just a lesson from experience.

[aja1345]

Originally Posted by CeesH

Hi Amir,

It depends a bit on the situation you are modeling. Typically I just start with the default values for all factors, unless I know upfront that certain equations may be difficult to stabilize. For example in stirred tanks with radial impellers, I may start with 0.2 for momentum (following Andre Bakker, you can find some advice on www.bakker.org) if I know that I won't be around the computer for a while to check how convergence is going - because I know at some point I may have to alter the value.

Other than that, I suggest to start default, and if during the process you notice that one of the residuals gets 'stuck' (so is oscillating up and down without any general downward trend), reduce the underrelaxation factors. What I typically do for stirred tanks when I am around to change things, is start with momentum at 0.7 to make some fast first iterations, then after 2500 iterations change to 0.1 - 0.2 or so to finish more accurately. That's what I mean with start high, end low. I do not know of any papers discussion URFs at length, or at least, I never referenced them since they very much focus on the mathmatical implemenation, and I regard them more as a tool - so knowing the basic idea behind them suffices for me.

Also I'd recommend; if the URFs need to be below 0.1 for your simulation to converge, you probably need to change your mesh. Otherwise the solution is going to take very long at best, and probably won't converge at all. This is no hard limit or so, just a lesson from experience.

Hi CeesH,

Really thanks,

Can you explain about discretization? For example, I think that second order upwind for momentum make convergence will become fast in my simulation. what is your opinion?

I am grateful that also guide me about turbulent kenitic energy and turbulent dissipation rate.

Thanks for allocating your time.

Best,

Amir

[mahayheidari]

Hello
I simulate a cylinder in ansys apdl
I have this error
solution not converged at time ansys apdl
Please help me

[RaiderDoctor]

Unfortunately, I think you're asking the wrong people, dude. Not only is this post well over 3 years old, but what they were talking about isn't really close to your problem.

For future reference, read this in regards on how to ask a question (Guide: How to ask a question on the forums). Then, if you really can't figure it out, go ahead and post a new question to the forum. If you tack on to old conversations, new people reading it will have no clue what's going on or where their solution is. We, as a community, are here to help one another.

Also, you do realize this is a website dedicated to CFD, right? ANSYS APDL (which I'm assuming is Mechanical APDL) is a structural program and, while some people do use it to run fluid-structure interactions (FSI), we typically only talk about fluid solvers here. More specifically, since this is the Fluent forum, we talk about Fluent here. I'd recommend finding a structural forum (I think XANSYS might be good). Good luck!

[vivjk94]

Originally Posted by CeesH

I mean that it can take a long time to converge a solution based on your mesh density, geometry, etc. But that doesn't mean that it does or does not converge. Convergence has nothing to do with time - either a solution converges or not. The thing is, at some point you may have to decide whether it is good enough, and/or if it's not yet good enough - if it's worth waiting any longer. When is it worth the wait? If you see the solution is still moving towards a certain answer. When is it not? if it's clearly oscillating around a certain value, and not reducing in amplitude of oscillation. You can try to force that by playing with the under-relaxation factors - at the cost of speed. But sometimes it's clear that your solution will not get any closer to the solution.

Anyway, it is up to you to decide whether the solution is good enough or not. And never, ever, ever do that based on the residuals - they give some relative value. They are dependent on the quality of your initial guess, too, and they may depend on your problem. In some problems residuals of 1e-3 are more than sufficient, in others 1e-6 far from. Always judge convergence based on integral quantities. and specifically, integral quantities related to your problem at hand. A mean temperature or nusselt number if heat transfer is your point of interest, a mean velocity or power number if it's flow, a mixing time if it's mixing. Residuals, by themselves, are meaningless. And when is a solution converged? If the parameter of interest oscillates within less than 1%? less than 0.1%? It's up to you to decide - that's the job of a CFD engineer. You will have to judge that. Anyone can set up a simulation in FLUENT, and anyone can make a nice contour plot of that. But by far not everyone can judge whether that plot is meaningful, whether that solution makes sense, and whether it has converged. Luckily, otherwise we would not get paid as well as we do. But if you are not yet judging, you better start judging - and a good point to start is simply the 'convergence' section in the FLUENT manual.

Having said that, it seems your simulation is actually converging (although you should really judge that on something), but you just think it takes too long. So what is long? 1 hour? 10? 2 weeks? What you have to realize is that there are no shortcuts, there are no magic bullets and no quick fixes. Converging takes time, and is a matter of trade-offs. So I can give you guidelines, things to look at, but no conclusive answers.

In general, a denser mesh gives you a more accurate answer, a cruder mesh gives you an answer faster - but there's a risk the answer is not mesh independent (so, increasing the mesh density will give you a different answer), and perhaps that your solution will diverge or oscillate heavily - say more than 5% in velocity or power number despite being a steady state calculation.

When it comes to mesh quality, try to use hexahedral cells close to cubic in the bulk, and do local mesh refinement based on the expected gradients. A good mesh may speed up convergence significantly, but probably does mean spending more time in the mesh editor - once again, a tradeoff. And low quality meshes may again invoke divergence.

Under-relaxation factors are easy: lower values mean slower convergence but more stability, higher values vice-versa. My advice: start high, and if you observe oscillations in the solution, reduce them for stability. So, end low.

Futhermore, I say once again, track integral quantities, use other monitors than only residuals. Maybe you are waiting forever for your monitors to reach 10^-6, while there are no significant in the solution anymore below 10^-3 - so you can stop much earlier.

That's what I can say. Of course, you could think about playing with domain decomposition for parallel and so on, but I would start with the above and see how far you can get. I know you posted your files online, and yes, I could open them and give you more concrete advice - but I'm not going to. One because that costs me too much time, and two because you won't learn from it. In the end it's your simulation - you are the one that has to decide what is an acceptable runtime and what is an acceptable answer, and you will learn most from it if you make those decisions rather than letting someone else do that for you. And in the end I guess that is why you are here, to learn. So go out, play, and learn. Good luck!

Thank you for your detailed and well written explanation.