Dear Bernd:
Firstly I have to thank you for your help.Now I am modeling the solidification process of Fe-C-Mn-Al quaternary alloy system, but I encounter difficulties.
The MICRESS and ThermoCalc version Iam running are 6.200 and 2015b respective. I am having thermodynamic and mobility databases for FE based alloy system. In my model, I use ThermoCalc provide thermodynamic parameters for MICRESS, there are two phases in my model: LIQUID and FCC_A1, and it can normal work at the baginning. But when it run to 0.02s, it display "trying hard phases 1 0" and "Error" in the screen, such as:
Warning: Demixing in interface LIQUID/FCC_A1. component AL
......
trying hard phases 1 0 level: 5 zq= 77399 error= 2
trying harder! Error= 2
trying hard phases 1 0 level: 7 zq= 78173 error= 2
trying harder! Error= 2
trying hard phases 1 0 level: 4 zq= 78173 error= 3
trying hard phases 1 0 level: 7 zq= 78173 error= 2
trying harder! Error= 2
trying hard phases 1 0 level: 4 zq= 78173 error= 3
trying hard phases 1 0 level: 7 zq= 78173 error= 2
trying harder! Error= 2
......
And they can cycle for long time. I don't know why this is so and how to deal with it, can you help me?
At the same time, I want to know the principle of how the solutes diffuse in the solid during the solidification process, completely diffuse, completely non-proliferation or partial diffusion? Corresponds to the lever-rule, Scheil-Gulliver model or others. Or can you tell me the control equation of the diffuse in the solid? I don't find it in the manual.
Thank you again!
Running problem
Re: Running problem
Dear Shenyz,
Welcome again to the MICRESS forum.
MICRESS by default uses the multi-binary extrapolation scheme which is used for independent redistribution of solute between the phases for each element based on the linearisation parameters obtained from TQ-coupling. While being most accurate for dilute alloys, it sometimes suffers from problems of "demixing" in higher alloyed systems which may lead also to numerical errors like those you show. If the problem does not originate from nearly-stoichiometric elements (which here is not the case), the problem can be solved by switching to a diagonal extrapolation scheme using the keyword "interaction", which could solve the problem you describe:
# Phase diagram - input data
# ==========================
#
# List of phases and components which are stoichiometric:
# phase and component(s) numbers
# List of concentration limits (at%):
# <Limits>, phase number and component number
# List for ternary extrapolation (2 elements + main comp.):
# <interaction>, component 1, component 2
# Switches: <stoich_enhanced_{on|off}> <solubility_{on|off}>
# End with 'no_more_stoichio' or 'no_stoichio'
interaction
no_more_stoichio
#
Diffusion in the solid phase is defined in the section "Diiffusion Data" in the same way as for the liquid phase. If you set diffusion in the solid, e.g.
# How shall diffusion of component 1 in phase 1 be solved?
multi ggg
you will use the complete line of the diffusion matrix for element 1 in phase 1 read from the diffusion data in your .ges5 file with "global" characteristics (i.e. locally T-dependent but not c-dependent)
# How shall diffusion of component 1 in phase 1 be solved?
diagonal g
would take only the diagonal term
# How shall diffusion of component 1 in phase 1 be solved?
diagonal d
would allow you to specify manually an Arrhenius description
# How shall diffusion of component 1 in phase 1 be solved?
diagonal n
would not do any diffusion for this term.
Bernd
Welcome again to the MICRESS forum.
MICRESS by default uses the multi-binary extrapolation scheme which is used for independent redistribution of solute between the phases for each element based on the linearisation parameters obtained from TQ-coupling. While being most accurate for dilute alloys, it sometimes suffers from problems of "demixing" in higher alloyed systems which may lead also to numerical errors like those you show. If the problem does not originate from nearly-stoichiometric elements (which here is not the case), the problem can be solved by switching to a diagonal extrapolation scheme using the keyword "interaction", which could solve the problem you describe:
# Phase diagram - input data
# ==========================
#
# List of phases and components which are stoichiometric:
# phase and component(s) numbers
# List of concentration limits (at%):
# <Limits>, phase number and component number
# List for ternary extrapolation (2 elements + main comp.):
# <interaction>, component 1, component 2
# Switches: <stoich_enhanced_{on|off}> <solubility_{on|off}>
# End with 'no_more_stoichio' or 'no_stoichio'
interaction
no_more_stoichio
#
Diffusion in the solid phase is defined in the section "Diiffusion Data" in the same way as for the liquid phase. If you set diffusion in the solid, e.g.
# How shall diffusion of component 1 in phase 1 be solved?
multi ggg
you will use the complete line of the diffusion matrix for element 1 in phase 1 read from the diffusion data in your .ges5 file with "global" characteristics (i.e. locally T-dependent but not c-dependent)
# How shall diffusion of component 1 in phase 1 be solved?
diagonal g
would take only the diagonal term
# How shall diffusion of component 1 in phase 1 be solved?
diagonal d
would allow you to specify manually an Arrhenius description
# How shall diffusion of component 1 in phase 1 be solved?
diagonal n
would not do any diffusion for this term.
Bernd
Re: Running problem
Dear Bernd:
Thanks for your kindly help, and I'm very glad that my model can work well after your guidance. But there is another problem that I'm confused.
That problem is that the microstructure morphology I get during the solidification process by MICRESS is not a typical dendritic morphology (Fe-C-Mn-Al alloy system). That's say if I put only one nucleation seed in the middle of the simulation area and let it grow, sometimes it well grow like a quadrilateral or four triangles(in two-dimensional), not a dendritic dendrites. The same problem I have met before and I have try to modify a series of parameters such as the interface energy, the orientation and so on to deal with it, but I failed.
Can you tell me where I did wrong and how I can do to get the typical dendritic morphology, or the correct way to adjust the parameters to get a right result.
Thanks a lot.
Thanks for your kindly help, and I'm very glad that my model can work well after your guidance. But there is another problem that I'm confused.
That problem is that the microstructure morphology I get during the solidification process by MICRESS is not a typical dendritic morphology (Fe-C-Mn-Al alloy system). That's say if I put only one nucleation seed in the middle of the simulation area and let it grow, sometimes it well grow like a quadrilateral or four triangles(in two-dimensional), not a dendritic dendrites. The same problem I have met before and I have try to modify a series of parameters such as the interface energy, the orientation and so on to deal with it, but I failed.
Can you tell me where I did wrong and how I can do to get the typical dendritic morphology, or the correct way to adjust the parameters to get a right result.
Thanks a lot.
Re: Running problem
Dear Shenyz,
This is difficult to imagine and can have various reasons. It would be much easier if you append a typical image and your input file...
Bernd
This is difficult to imagine and can have various reasons. It would be much easier if you append a typical image and your input file...
Bernd
Re: Running problem
Dear Shenyz,
from the data you sent me by e-mail I can see that you apply a too high initial undercooling in both cases. This leads to a situation where the system is either just overrunning the pile-up before the front (FeC) or would form an extremely fine structure which is not resolved at the given grid spacing.
In the second case, cutting the driving force to 20 J/cm3 is additionally hiding this problem.
In both cases, the sharp corners of the "dendrites" indicate that due to the huge kinetic undercooling curvature is not having any effect.
You will notice that the behaviour drastically changes when increasing the initial temperature.
Bernd
from the data you sent me by e-mail I can see that you apply a too high initial undercooling in both cases. This leads to a situation where the system is either just overrunning the pile-up before the front (FeC) or would form an extremely fine structure which is not resolved at the given grid spacing.
In the second case, cutting the driving force to 20 J/cm3 is additionally hiding this problem.
In both cases, the sharp corners of the "dendrites" indicate that due to the huge kinetic undercooling curvature is not having any effect.
You will notice that the behaviour drastically changes when increasing the initial temperature.
Bernd
Re: Running problem
Dear Bernd:
Thanks a lot.
The reason is that I apply a too high initial undercooling in both cases as you say. I have adjusted the initial temperature in both cases and get a beter result. But there are still little confused I have. One of you advice is that "In the second case, cutting the driving force to 20 J/cm3 is additionally hiding this problem", but what I use is already 20 J/cm3:
# 'DeltaG' options: default
# avg ... [] max ... [J/cm**3] smooth ... [degrees] noise ... [J/cm**3]
avg 1 max 20
# I.e.: avg +1.00 smooth +0.0 max +2.00000E+01
# Type of surface energy definition between phases LIQUID and 1?
# Options: constant temp_dependent
constant
# Surface energy between phases LIQUID and 1? [J/cm**2]
# [max. value for num. interface stabilisation [J/cm**2]]
2.8000E-05
# Type of mobility definition between phases LIQUID and 1?
# Options: constant temp_dependent dg_dependent thin_interface_correction [fixed_minimum]
constant
# Kinetic coefficient mu between phases LIQUID and 1 [ min. value ] [cm**4/(Js)] ?
4.00000E-03
So what is a beter value?
And I am confused about the Kinetic coefficient mu, how I could confirm the value? Thanks!
Shenyz
Thanks a lot.
The reason is that I apply a too high initial undercooling in both cases as you say. I have adjusted the initial temperature in both cases and get a beter result. But there are still little confused I have. One of you advice is that "In the second case, cutting the driving force to 20 J/cm3 is additionally hiding this problem", but what I use is already 20 J/cm3:
# 'DeltaG' options: default
# avg ... [] max ... [J/cm**3] smooth ... [degrees] noise ... [J/cm**3]
avg 1 max 20
# I.e.: avg +1.00 smooth +0.0 max +2.00000E+01
# Type of surface energy definition between phases LIQUID and 1?
# Options: constant temp_dependent
constant
# Surface energy between phases LIQUID and 1? [J/cm**2]
# [max. value for num. interface stabilisation [J/cm**2]]
2.8000E-05
# Type of mobility definition between phases LIQUID and 1?
# Options: constant temp_dependent dg_dependent thin_interface_correction [fixed_minimum]
constant
# Kinetic coefficient mu between phases LIQUID and 1 [ min. value ] [cm**4/(Js)] ?
4.00000E-03
So what is a beter value?
And I am confused about the Kinetic coefficient mu, how I could confirm the value? Thanks!
Shenyz
Re: Running problem
Dear Shenyz,
Sorry for my bad explanation. What I wanted to say is that cutting the driving force just makes it more difficult to see that there is a too big undercooling there...
Cutting the driving force in principle is not necessary. It is only needed in certain cases like for stabilizing an initially unstable simulation, but then it has to be used with clear intention.
I personally often use a value which is well above any realistically expected value of the driving force for the purpose of stabilizing against any purely numerical incident. In this sense, the value of 20 J/cm3 may be a good choice under the given conditions.
A qualitative criterion for the interface mobility is a comparable size of curvature and kinetic contribution to the driving force (.driv). This has been explained here.
Bernd
Sorry for my bad explanation. What I wanted to say is that cutting the driving force just makes it more difficult to see that there is a too big undercooling there...
Cutting the driving force in principle is not necessary. It is only needed in certain cases like for stabilizing an initially unstable simulation, but then it has to be used with clear intention.
I personally often use a value which is well above any realistically expected value of the driving force for the purpose of stabilizing against any purely numerical incident. In this sense, the value of 20 J/cm3 may be a good choice under the given conditions.
A qualitative criterion for the interface mobility is a comparable size of curvature and kinetic contribution to the driving force (.driv). This has been explained here.
Bernd