Discussion Forum

Can't open the file unfortunately due to "CAD module" license.

I am not very surprised about a moderate speed difference, though 100 times really sounds like a not well-tuned comsol model. The highlight of Comsol is not really the speed - though they're trying to improve it -- but flexibility and extendibility. With Ansys you're doomed if you wanna add another physic.

Overall, I hear you. I am struggling with Comsol solvers myself for my specific case. There are general solvers that can solve most of the problems, but naturally they're not tuned for a special case like CFD. You may try the multigrid methods which suit CFD more than PARDISO.


--
Comsol 4.1
Ubuntu 10.04.1

Dear Markus,

Your model presents a challenge in terms of the top and bottom boundaries that with the current set-up can become both inlet and outlet boundaries at the same time. Especially, complicated patterns tend to form at the top boundary and in such a situation the exact details of the boundary conditions become decisive for the solution. This could explain why COMSOL has a hard time finding an accurate solution in this case. I would also advice you to check if your solution is independent of the position of the outlet and inlet boundaries. The rule of thumb that "if something interesting is happening on an outlet, move the outlet further away" is definitely applicable to this case.

Time stepping of some kind is often needed in natural convection models to make the iterations pass through physically reasonable states. The time stepping can be in "pseudo time" (also sometimes referred to as local time stepping). While COMSOL provides a sort of pseudo time stepping, it is mainly designed for forced convection problems. We are aware of this shortcoming and are investigating possible improvements for the pseudo time stepping algorithm.

Best regards,
Magnus Ringh, COMSOL

Dear Magnus,

thanks for your comprehensive answer!

Your completely right about the inlet/outlet problem, the strange thing is that nothing interesting happens at the
inlet/outlet boundaries...
What really puzzles me ist that the model (watch the convergence log) starts off solving fast in large timesteps and as the solution approaches stationarity, where one would expect the timesteps to become larger, the timesteps become smaller and smaller instead. So most of the computational is at the end, while the really transient part of the timeline solves easily. If I could work around that strange slow-down in the nearly stationary part the solution time would be apsolutely acceptable.

Regards,
Markus

Hi all
i must say this is like the 5th thread i see dealing with natural convection and problems with the analysis.
this is also not the first time i have seen reference to "natural convection must be solved under transient solver".

well, the solution to the whole natural convection problem is complex but possible in both STATIONARY and TRANSIENT (i personally prefer for engineering application to use the stationary solution unless i am interested in the "Ramp-up" process) if only you define the physics properly , see below:

the system:
1. you need to create a large enough volume of fluid around the object to make sure that you don't get artifacts in the computation field due to the boundaries (usually 2-5 times the nominal dimension of the object in length in all directions)
2. define the fluid field: under 'absolute pressure' choose "pressure(nitf/fluid1)" , and as reference pressure enter the ambient pressure.

Mesh:
1. choose a "fine" mesh for most cases where the geometry is more elaborate then cubic presentations (you need a fine enough mesh to capture the fine temperature gradients in the near wall region, as well as the sharp directional acceleration gradients of the velocity field from the entrainment into the plum)

Boundary conditions:
1. the face where the plum (the heat plum raising from the object) is to be defined as "outflow" (under heat transfer BC) AND "outlet" (under laminar BC - set P0=P, ambient)
2. the faces where the fluid enters the system (to satisfy the entrainment of the plum) is to be defined as "open boundary" (with "no viscus stress" condition and T0=T, ambient)
3. Volume force, is to be defined as "-g_const*(nitf.rho-rho_ref)"
4. heat source, what ever is relevant to you system.

summation of BC:
1. volume force
2. open boundary
3. outflow
4. outlet
5. heat source

Solver:
1. choose the stationary solver and change
under study>solver configurations>solver1>fully coupled 1 , change the 'damping and termination' definition to being "automatic highly non-linear"

regarding convergence in Stationary studies:
as we all know and like you can find in many places in the literature, indeed natural convection has a transient element to it, as the plum and flow field fluctuates along the heated surface, HOWEVER, there is still the possibility to achieve a Stationary study that complies with the system.

the thing is, should you run a stationary solver, you will see that after some iterations as the convergence 'green bar' goes all the way to 90% it will then drop sharply to approximately 50%... this phenomena will fluctuate back and forth ENDLESSLY!
what you need to understand it that this is happening because the solver set on one solution then loss stability as it "moves" to another.

What you need to do: let the solution fluctuates aback and forth 1-2 times, once you see the pattern - stop the solver, and there you have it!!! - your solution (you will see that should you stop the solver at a different fluctuation the flow filed will look slightly different 'Plum-wise' but the temperature will be identical)

i have attached a working example, that has been lab tested to make sure the solver results are accurate.

Best regards to all
M.sc Yoav matia.