Page 1 of 2

pearlite

Posted: Mon Mar 21, 2022 2:26 pm
by shaojielv
Hi, everyone!
In the pearlite transformation process of Fe-C binary alloy, I have determined ferrite and cementite as the initial phase. The specific model is shown in the figure, but there are still some problems. The model does not grow according to lamellar (lamellar pearlite). I hope that the friends of the forum can provide some improvement suggestions for me in their spare time. I will be very grateful. The following is the attached driver file.
The little son jack

Re: pearlite

Posted: Mon Mar 21, 2022 5:17 pm
by Bernd
Dear shaojielv,

There are some parameters in your driving file which seem unreasonable to me:

- σ1/2=1.0E-3 J/cm2 is a very big value for an interface energy/stiffness! More realistic are values around ~1.0E-5 J/cm2, otherwise you get extremely high curvature driving forces. Furthermore, all interface energies of interfaces which interact in a common triple junction should be in a narrow range with less than a factor of 2 between them (otherwise one would get full wetting or no wetting at all). I propose to start with a value of σ=1.0E-3 J/cm2 for all interfaces.

- You still apply a very small temperature gradient, which practically has no effect because the T-difference between bottom and top of your domain is just 56 mK (which is much smaller than the typical curvature undercooling).

- You are using an interface thickness of only 2 cells which is below the recommended range of ~2.5 - 4.0 cells. Besides a very low accuracy you may experience problems of nucleation at interfaces or others...

- In section "Numerical Parameters / Phase Field solver" you have set the minimum value of phase-field time steps to 1.0E-3. This parameter is typically used for numerical performance optimization (see here), and cannot be reasonably set before the simulation setup is close to be finished. You should put a sufficiently small value there to be sure that you are not limiting phase transformation kinetics unwillingly.

Bernd

Re: pearlite

Posted: Tue Mar 22, 2022 7:56 am
by shaojielv
Bernd,
Yes, what you said makes a lot of sense, and I have modified it according to the related questions, but there are still some problems with the transition, the evolution has disappeared, I am trying to find the related problems, but still no good solution, if If possible, I hope you can run the driver file, I believe you will come up with a better solution. wish you a happy life.

Re: pearlite

Posted: Tue Mar 22, 2022 10:04 pm
by Bernd
Hi shaojielv,

Looks as if the initial temperature is too high, so that the reaction goes backwards...

Please have a look at the initial linearisation data in the .log-file, especially to the driving force dG: For both interfaces, 1/2 and 1/3, the values should be slightly negative in order to signalize the correct direction of the transformation. Before, take care that the "Temperature at which the initial equilibrium will be calculated" is set to the same value as the initial temperature (otherwise the dG values will not reflect the conditions at start).

Please account for additional undercooling for overcoming curvature!

Bernd

Re: pearlite

Posted: Wed Mar 23, 2022 11:53 am
by shaojielv
Bernd,
Thank you very much for your help, I can basically complete my simulation now, but I still have some questions to ask you, the mesh of my previous simulation domain is 0.028um, I think the boundary is too thick (rough), so I want to refine the mesh. When I adjust the mesh to 0.01um, the following phenomenon occurs. What do you think caused this result? In addition, pearlite will grow to both sides during the growth process. I think this is automatically adjusting the distance between the lamellae. Do you think so?
Thank you again and wish you a happy life.

Re: pearlite

Posted: Wed Mar 23, 2022 1:58 pm
by Bernd
Dear shaojielv,

The image at the left looks fine, the position of the cementite lamellae is adjusting such as to achieve similar lamellae width of the ferrite (and such minimal curvature). You could try using periodic conditions on the right (east) and left (west) side to reduce the impact of the domain boundaries.

The right image looks like a display artifact: You have an overlay by alternating right and left half lines of the original image! I never saw that, but could it be that you displayed the .phas result with high resolution together with the .geoF file with low resolution?

Bernd

Re: pearlite

Posted: Wed Mar 23, 2022 2:28 pm
by shaojielv
Bernd,
I have used the periodic symmetry condition here, but the results are very rough, so I want to further optimize the results by refining the mesh, but the results shown above appear. And what I am showing here is phas., so I am also very puzzled why this result occurs.

Re: pearlite

Posted: Wed Mar 23, 2022 2:49 pm
by Bernd
Dear shaojielv,

This is definitively no simulation result. I still think you use a wrong .geoF file for displaying the results. Please explicitly delete this file before running MICRESS again with the higher resolution.

Bernd

Re: pearlite

Posted: Wed Mar 23, 2022 3:25 pm
by shaojielv
Dear Bernd,
Thank you very much, you are right, I did use a .geof file to display the results, but I don't quite understand what you mean, what should I do specifically, thank you for helping me solve it Confuse.
shaojie lv

Re: pearlite

Posted: Wed Mar 23, 2022 3:37 pm
by Bernd
Dear shaojie lv,

Each time you run MICRESS, besides the result files (e.g. name.phas) also a geometry file (name.geoF) is created. When opening name.phas with the DP_MICRESS postprocessor, name.geoF is also automatically opened in the same location in order to provide information about grid size and resolution.
If it happens that the file "name.geoF" were from a prior simulation with 0.028 µm resolution, and you have changed grid size or resolution for the result file "name.phas", than the information would not fit, and you would see display artifacts exactly like yours. This could be the case e.g. if you copy result files for inspection to another directory, but forget to copy also the corresponding "name.geoF" file...

Bernd