Precipitation of boride in the Cr-Ni-B ternary phase diagram

dendritic solidification, eutectics, peritectics,....
lihaoge1994
Posts: 9
Joined: Mon Apr 02, 2018 2:33 pm
anti_bot: 333

Re: Precipitation of boride in the Cr-Ni-B ternary phase diagram

Post by lihaoge1994 » Mon Nov 19, 2018 10:56 am

Dear Bernd

I have removed the 1d_far_field and the warnings did not appear anymore. Thank you very much.
However, there is another problem: if I try to start with less primary seeds, the simulation started to show 'trying hard phases' errors and the simulation showed errors results which I put in attachments.

In order to start with less primary seeds, I changed the maximum number of new nuclei 1 (primary boride) from 100000 to 20. And increased the shield time from 0.5 to 2 and also shield distance from 2 to 10 of new nuclei 1. I just changed these three parts of things and the simulation started to show 'trying hard phases' errors. And from the results we can see that the primary boride grew strange. The primary boride is lath shaped and do you know how to revise the faceted data? Please help me to solve this problem.

# Data for phase 1:
# -----------------
# Simulation of recrystallisation in phase 1?
# Options: recrystall no_recrystall [verbose|no_verbose]
no_recrystall
# Is phase 1 anisotrop?
# Options: isotropic anisotropic faceted antifaceted
faceted
# Crystal symmetry of the phase?
# Options: none cubic hexagonal tetragonal orthorhombic
none
# Number of type of facets in phase 1
1
# kin. anisotropy parameter Kappa?
# only one value for all facets/phases
# 0 < kappa <= 1
0.8000000
# Number of possible orientations of a facet 1
1
# 1 -th normal vector facet 1 ? 3*
1.000000
0.000000
1.000000
# Should grains of phase 1 be reduced to categories?
# Options: categorize no_categorize
categorize

Another thing is that I used the syntax with "automatic_limited" in the time input data and I increased the time step. And it became an empty simulation this time. Do you know why?

Thank you all the time.

lihaoge
Attachments
CrNiB_in.txt
(38.71 KiB) Downloaded 259 times
2.png
2.png (31.13 KiB) Viewed 2943 times

Bernd
Posts: 1247
Joined: Mon Jun 23, 2008 9:29 pm

Re: Precipitation of boride in the Cr-Ni-B ternary phase diagram

Post by Bernd » Mon Nov 19, 2018 4:58 pm

Dear lihaoge,

The dendritic microstructure of the primary boride is due to the fact that you have a quite big undercooling, and the interface mobility is high. Reducing one or both would change the morphology.
I can imagine both: The primary borides under experimental conditions may form at higher temperature, and faceted phases may have some kinetic restriction of growth. You need to make assumptions on that because there is no data available.

With the second issue, I need to see your actual time step input. With "empty simulation" you certainly mean that you did not get outputs even after long time?

Bernd

lihaoge1994
Posts: 9
Joined: Mon Apr 02, 2018 2:33 pm
anti_bot: 333

Re: Precipitation of boride in the Cr-Ni-B ternary phase diagram

Post by lihaoge1994 » Mon Nov 19, 2018 5:33 pm

Dear Bernd

Thank youfor your advice. I will try to mak some assumptions on that to get the right morphology.

I will show you my actual time input and result tomorrow. Thank you very much.

And I still don't know why simulation started to show 'trying hard phases' errors and the simulation showed errors resuwhy. Do you mean that the interface mobility and undercooling is also the reason that caused the errors?

lihaoge

Bernd
Posts: 1247
Joined: Mon Jun 23, 2008 9:29 pm

Re: Precipitation of boride in the Cr-Ni-B ternary phase diagram

Post by Bernd » Mon Nov 19, 2018 7:31 pm

I think yes, because the local undercooling is the main factor which you change by reducing the nucleation density. But in order to be sure I would need to see all the results...

Bernd

lihaoge1994
Posts: 9
Joined: Mon Apr 02, 2018 2:33 pm
anti_bot: 333

Re: Precipitation of boride in the Cr-Ni-B ternary phase diagram

Post by lihaoge1994 » Fri Nov 23, 2018 5:48 am

Dear Bernd

I have reduced the interface mobility of the primary boride microstructure became better. And the time step input is:

# Time input data
# ===============
# Finish input of output times (in seconds) with 'end_of_simulation'
# 'regularly-spaced' outputs can be set with 'linear_step'
# or 'logarithmic_step' and then specifying the increment
# and end value
# ('automatic_outputs' optionally followed by the number
# of outputs can be used in conjuction with 'linear_from_file')
# 'first' : additional output for first time-step
# 'end_at_temperature' : additional output and end of simulation
# at given temperature
0.0005
linear_step 0.001 1
end_of_simulation
# Time-step?
# Options: fix ...[s] automatic automatic_limited
automatic_limited
# Options: constant from_file
constant
# Limits: (real) min./s, [max./s], [phase-field factor], [segregation factor]
1.E-7 1.E-5
# Coefficient for phase-field criterion 1.00
# Coefficient for segregation criterion 0.900
# Number of steps to adjust profiles of initially sharp interfaces [exclude_inactive]?
20

And the cooling rate is -2000K/s. I put the result in the attachment as you can see.

However, if I changed the time input data and cooling rate like the dri. fill which I put in the attachment, the simulation time became very long and after 24 hours I still cannot get outputs. I am wondering if I can get the result when I wait for more time.
Please help to solve this problem. Thank you very much.

lihaoge
Attachments
CrNiB_log.txt
(130.71 KiB) Downloaded 161 times
CrNiB_in.txt
(37.35 KiB) Downloaded 124 times
CrNiB_phas_mcr.png
CrNiB_phas_mcr.png (32.79 KiB) Viewed 2648 times

Bernd
Posts: 1247
Joined: Mon Jun 23, 2008 9:29 pm

The minimum time step width and performance

Post by Bernd » Fri Nov 23, 2018 1:09 pm

Dear lihaoge,

It is obvious that with smaller phase-field time-steps the required simulation time increases. This is the reason why we introduced the input of the mínimum time step together with the "automatic_limited" keyword: It allows using bigger time steps even if some exceptional interface cells would require a smaller time step. Then, for keeping the simulation stable, the interface mobility is automatically reduced in those cells which would require a smaller time step.
In your case, before, you reduced the interface mobility for all interface cells by specifying a too big value for the minimum time step width. However, maintaining the interface mobility high requires smaller time steps and higher simulation times. Thus, optimisation of the minimum time step width can be essential for performance optimisation.

The ingredients of such an optimisation are:

1.) The .TabP (text) output which tells you how much time is spent in time-step sensitive parts of the code (PF time, List time)
2.) The .TabT (text) output which tells you which phase interaction is the one which requires the smallest time steps.
3.) The .mueS (graphical) output which tells you in which interface cells and how much the interface mobility has been reduced.

The minimum time step should always be chosen such that mobility reduction happens only in a small percentage of the interface cells for the critical phase interactions which requires the smallest time steps. This assures that there is no relevant effect on the phase transformation kinetics observed in simulation. Here we assume, that the required interface mobility is already known and either has been obtained automatically by the "mob_corr" option, has been correctly calibrated, or is regarded as a known physical parameter. This required mobility strongly affects the required phase-field time step with and, of course, has to to be chosen before optimisation of the minimum time step.

In many simulation case, performance is limited by the phase-field time step width, especially if resolution is relatively low and there are wide-spread interface regions. Then, performance is often proportional to the time step width, and a factor of 2 for the minimum time step may speed up the simulation by a factor of 2.

For having a quick estimation of the time required for a simulation, the tab_log interval should be chosen small enough to produce fast output of the "tablog" files .TabL, .TabP, .TabTQ and .TabT. This is also important to provide the information for optimisation of the minimum time step as shown above.

Bernd

Post Reply