How does it always ensure convergence?? Does it intelligently detect the pattern in residual behavior and adapt the URFs accordingly or is it due to more internal algorithms which nobody really is sure of and never been validated nor published?

EFD contains built-in criteria to stop the solution process, but it is best to use your own criteria, and make use of Goals. You specify the Goals as physical parameters of interest in your project, so their convergence can be considered as obtaining a steady state solution from the engineering viewpoint. Goals Convergence is one of the conditions for finishing the calculation. Specifying Goals not only prevents possible errors in the calculated values of these parameters, but in most cases also allows you to shorten the total solution time. It is possible to monitor the Goals convergence behavior during the calculations, and stop the solution process manually if further calculations are not required. A goal's progress bar is a qualitative and quantitative characteristic of the goal's convergence process. When EFD analyzes the goal's convergence, it calculates the goal's dispersion defined as the difference between the goal's maximum and minimum values over the analysis interval reckoned from the last iteration and compares this dispersion with the goal's convergence criterion dispersion, either specified by you or automatically determined by EFD as a fraction of the goal's physical parameter dispersion over the computational domain. The percentage of the goal's convergence criterion dispersion to the goal's real dispersion over the analysis interval is shown in the goal's convergence progress bar (when the goal's real dispersion becomes equal or smaller than the goal's convergence criterion dispersion, the progress bar is replaced by word "achieved"). Naturally, if the goal's real dispersion oscillates, the progress bar oscillates as well. Moreover, when a complex problem is solved, it can noticeably regress, in particular from the "achieved" level. The calculation can finish if the iterations (in travels) required for finishing the calculation have been performed, as well as if the goals' convergence criteria are satisfied before performing the required number of iterations. It is often convenient to specify an appropriate goal with the specified condition. For example, if you specify a pressure opening it makes sense to define a mass flow rate surface goal at this opening. EFD allows you to associate a type of a condition (boundary condition, fan, heat source or radiative surface) with a goal(s), which will be automatically created with the condition if the Create associated goals check box is selected in the condition's dialog box

In that case all of EFD models can be manipulated to achieve 99.9% accuracy compared to experimental values so easily. Would it be valid though for this goal criterion to be used further to predict results of design changes when not yet measured in experiment? Is there validation study published anywhere on EFD method of goal-convergence approach?

Scored, its possible to continue until everything is converged to the round-off error of the machine you're using. However, EFD is designed to allow the solution to be terminated when convergence has been achieved for those quantities that are of interest to the designer. For example, if the application is electronics and I'm interested in temperatures, why should I carry on the calculation after the temperatures of interest have stopped changing? Ditto pressure drop across a valve for example. Don't forget, what a designer wants is information to allow him or her to make an informed decision about changing the design, which is why we recommend that users set up goals to monitor the changes in things that are of interest to them, and check that these have stopped changing.

Scored,

The previous email was just an extract right out of the help file. How you come to the conclusion that you can manipulate the results through goals is a bit of a mystery. Using goals is just a way to tell the program what you are interested in and to terminate the compuations when those quantities have settled down - if they don't settle down the program chomps away till some other termination criteria has been reached. I have done hundreds of simulations with the tool over nearly 10 years and the stuff works very well indeed within its limitations.

Without goal (e.g. temperature) the computations will continue as you said, crunching the temperature, momentums, pressure, dissipation, etc. Will the results of all values be the same (the temperature let's say) if we did not set the temperature goal at the beginning and let it chomp away until old-fashion residuals are converged? You might see the mystery in answering this way. And is there publication somewhere... besides the self-published manuals?

yes the same answers will be obtained whether you set a goal for a parameter or not though the meshing is related to the specification of the some goals or at least that is my understanding. However, the goal may terminate the computation early depending on the convergence criteria. The Flomerics peolple can probably better speak to those subtleties. In my experience essentially the same answer is obtained in the bulk of cases. Remember the tool is designed to be an engineering level tool not a scientific level tool. That said though with the proper exploration of the solution (mesh refinements and other prudent techniques of confidence building) very decent answers can be had for a wide variety of problems within the programs limitations - at least in my experience.

[riz]

I'm only want to see the temperature. It always converged, but other variables (z velocity, sometime the pressure, x velocity, etc beside temperature) is not converged. It tickles me. If my goal is to find only the temperature, it is okay to stop the solution when temperature is already converged, right?

I'm a newbie and not with a strong engineering basic knowledge, and I'm forced to use flovent as a tool for my thesis.