MICRESS Forum

Dear Bernd,

I have challenged three-dimensional calculation by MICRESS.
It takes more than 1 week to complete the calculation for ternary system
such as Fe-16Cr-13Ni solidification started from 1730K to 1710K.
It's only 40 steps!
I would like to learn how calculation progresses faster.
Calculation conditions used are shown in a PDF sheet attached.

And I expected FCC will appear, in the 1709K.
(I set a FCC grain deposition temperature at 1710K)
However, MICRESS couldn't reach a next step even if it hangs for 6 days.
Finally MICRESS outputted the error code and stopped.
The error code was “Error (72) : floating overflow”
It seems to me that the precipitation of FCC phase causes Phase Field time-step decrease and the delay of the calculation mentioned above.

Please give me some advice.

Regards,
Taka

Hi Taka,

impressive results! From size and resolution it seem reasonable that it takes one week to get there - but this does not necessarily mean that it cannot be improved! And that it hangs afterwards must have a reason...

First of all just one remark on your simulation setup: Why did you set the initial dendrites in this orientation producing a large "hole" of liquid in the center? Is this intended? It would be more natural to rotate their orientation by 45% around the z-axis to get a more dense and more typical dendrite array...

In order to get an overview over the performance of a simulation, you should always have a look into the .TabP output! If something is going wrong during run-time, and performance is not optimal, you will be probably able to see that in this file. Even if you are waiting 6 days for a mayor output, you can check this file as it is typically written with a much higher frequency.
The columns in the .TabP file give you the wallclock time as well as the cumulative CPU time which is spent in different routines or groups of routines. These are described in this thread.

Problems which typically can lead to a strong performance reduction are:

1.) The automatic time stepping selects a time-step value which is very small. You can see increased CPU times in the columns "PF time" and "List time" of .TabP, or directly the small time step values in the .TabT file. The problem is normally caused by numerical problems, too high interface mobilities or a too small value of the minimum time step (the latter could be the reason in your case, we already talked about that!)

2.) Fluctuations appear somewhere which you even cannot see directly. These fluctuations imply a lot of thermodynamic calculations because new cells periodically enter into the interface region and vanish again. In such cases, the "TQ time" in .TabP is strongly increased. You can verify fluctuations by checking the .numR file (see here).

3.) If numerical problems occur, it may be that the interface "explodes". Performance goes down due an increase of the interface size (see .TabL) or due to the reasons shown above. Typically, if coupled to a database, TQ-related error messages are displayed on screen. The only solution is to find out the reason for the instability...

Could you attach the .TabP output to your next post?

Best regards

Bernd