code_saturne User's Forum

Hello everyone,

I would like to make a demonstration case of segregation phenomena during the solidification of a binary alloy. To do this, I'm trying to use the CS solidification module with CDO scheme approach (v8.0.2), and I'm facing a problem I don't understand concerning the gravity consideration.

I joined a simple case to illustrate my problem :
- A square 0.1*0.1m, 400 elements
- Activation and input of a binary alloy, with temporary simplification to cancel the Boussinesq term (Beta_T = Beta_C = 0)
- Adiabatic condition everywhere
- A uniform initial temperature above the melting temperature, so a full liquid domain

With such conditions, I expect nothing to happen. It's ok without gravity. But with standard gravity, I observe velocity along the gravity direction, with very strong values at the boundary facing this gravity direction, and a continuous warning in the listing file about the Picard algorithm which reaches the max. number of iterations when solving equation "momentum". There is no pressure, no density variation, so I don't understand what's going on. Would there be some opinion or advice?

Thank you for your help,
Best regards,

Matthieu

Here are some additional files concerning obtained results (listing file and images of Vz component field).

Best regards,
Matthieu

Hello Matthieu,

This is weird.
It looks like a non-convergence of the solver. The system to solve is a velocity/pressure coupled system (a saddle-point problem) which is difficult to solve in general. That's why, we usually rely on the MUMPS solver for this kind of system.
In the current case, this should be simpler...
Could you share your setup.log file so I can check your linear algebra settings, please ?

Jérôme.

Hello Jérôme,

Thank you for you answer.

Here is my setup.log file.

Concerning the MUMPS solver, it appears I can't use it ("cs_user_parameters: MUMPS is not available" if I try a simulation with the linked source file). I have an installed libmumps on my server, but I just checked and code_saturne seems to not see it ("MUMPS support: no" in the install_saturne.log file). Is there a manual manipulation to do in order to use this solver (a link to the concerned library?)?

Best regards,
Matthieu

Thank you for the additional information.

Regarding MUMPS, you have to add "--with-mumps=/path/to/your/mumps/install" at the "configure" step.
If the usage of the "--with-mumps" tag gives the same result, you have to check your config.log file to figure out what is wrong.

Best regards,
Jérôme.

Hello Jérôme,

Thank you for your answer.

It's ok concerning access to MUMPS library and solver. I tried to use it, but temperature is diverging in my test (cf. joined files).

Regarding "classical" solvers available in CS, is there a better option than the used GCR solver for velocity? I'm not so familiar with that.

Best regards,
Matthieu

Hello Matthieu,

I think there are two problems:
1. Your boundaries are defined twice. Since CDO schemes are not fully available from the GUI, some steps should be done only with user source files. This is not a satisfactory situation...

2. MUMPS as a solver for the full system is not robust since the system is singular (the pressure is defined up to a constant). The resolution can fail or can be very weird. A better choice to solve the coupled system is to consider an Augmented Lagrangian - Uzawa (ALU) algorithm.

You need to adapt your settings with

cs_navsto_param_set(nsp, CS_NSKEY_SLES_STRATEGY, "alu");

Here is the setup I used with a slight modification of your original settings (I used your mesh file). It looks better now.

Hello Jérôme,

Thank you very much for your help.

I'll try these modified settings in some configurations, and will give you feedback if you're interested.

Best regards,
Matthieu

Hello,

I carried out some tests based on the previous cs_user_parameters file (with gravity, but no physics about solidification at this time), here are some reports :

=> With the 2D square 0.1m*0.1m case previously described, simulations seems to make sense (negligible velocity), but I noticed a very (very) strong increase of time simulation and used memory with mesh refinement. For example, with a structured mesh of 250k elements, the joined performance.log file talks about 10.5Go of used memory, and a total CPU time of 174382s for 100 iterations (the simulation ran with 4 MPI ranks and 2 OpenMP threads), which sounds huge for this kind of mesh... Set the gravity to 0 doesn't change so much obtained results, except for a slighter MUMPS number of solves concerning velocity (10k vs 15k). Does it make sense with the solidification module / the CDO approach / the use of MUMPS, or do you think there is a problem with these stats?

=> With a similar setup in "industrial dimensions" (2D rectangle 0.65m*2.67m), the simulation is OK with a very coarse mesh (700 elements, dx=0.05m), but there is a non-convergence of the solver with a finer mesh (17k elements, dx=0.01m), similar to what I obtained at the beginning of this topic (cf. joined mesh et setup.log files).

I'm continuing tests on my side, don't hesitate if you want more information, and of course I'll be glad if you have any idea.

Best regards,
Matthieu

Hello,

I'll let Jérôme answer most of your questions, as I am the the expert for this part of the code.

Regarding memory use though, direct solvers such as MUMPS usually consume much more memory than iterative solvers (due to the inverse of a sparse matrix often being less sparse), so your results are not surprising. We only use MUMPS when iterative solvers fail or converge very slowly, because it is more robust, but at a cost in memory usage.

Best regards,

Yvan