MICRESS Forum

Hello,

We are currently considering several potential applications of MICRESS for simulations of aluminum alloys.

The main issue we are facing is that the Thermo-Calc databases currently available to us are TCNI12 and MOBNI6, which are nickel-based database packages.
Based on several posts found on the user forum, it appears that when using these databases, significant errors or performance degradation may occur if the main element is not set to Ni.

In our case, the aluminum alloys we intend to simulate do not contain any nickel at all. In this case, what kind of support can we expect?

We understand that Thermo-Calc as a standalone tool is relatively more tolerant when performing calculations for alloy systems that are not fully consistent with the intended database scope. Therefore, one option we are considering is to perform standalone Thermo-Calc calculations to extract a limited set of required material properties (such as diffusion coefficients, phase boundary slopes, etc.) and then use these data to define a linearized phase diagram within MICRESS.

If this approach is adopted, could you please clarify which specific inputs would need to be provided manually in MICRESS—particularly those parameters that would otherwise be supplied automatically through TQ coupling and database-based settings?

best regards, Ku

Dear Ku,

Wish you a Happy New Year.

I think there is no rationale for an indirect usage of thermodynamic data in the way you propose. The main problem of using a Ni-database for Al-alloys is the selection of subsystems (binary, ternary phase diagram descriptions) for building up the corresponding database, and the optimisation of the multicomponent parameters with respect to typical Ni-based alloys. Furthermore, typical phases of Al-alloys may be missing.

The question whether, for a specific case, you can expect reasonable results when using TCNI12 for an Al alloy should strongly depend on whether the main ternary systems relevant for your application have been used in the assessment (see e.g. https://www.engineering-eye.com/THERMOC ... l_info.pdf). My understanding is, if you would e.g. try to use TCNI12 for a ternary Al-Cu-Si alloy, the results would be identical to those when using a TCAL database which has been built upon the same ternary system. However, I have to admit that I have no practical experiences with such cases.

There is also no evidence that, if the NI-database is only a crude approximation for your Al-alloy, MICRESS would behave worse under these circumstances as compared to using stand-alone Thermo-Calc. However, again, I have no specfic experiences on that, and problems with MICRESS cannot be excluded, if the "misused" Ni-database behaves wickedly. But it is also questionable whether, in the wicked case, it would be possible to translate the phase-diagram description into a meaningful linearized description.

If acquiring a TCAl database is not (or not yet) an option for you, I would try the following:

1.) The COST507 database (https://www.engineering-eye.com/THERMOC ... /cost2.pdf) is old and has not be updated, but it is free of charge. If it is working for you, I would prefer it over TCNI12.

2.) If your Al-alloy can be approximated by a ternary system, there certainly is an assessment published, and a free .tdb-file should be available for it.

3.) If you want to use TCNI12 with MICRESS for an Al-alloy, there should be no specific problem (apart from those mentioned above), even if Al is now the matrix component, and Ni not present at all. I also would expect MOBNI6 to work normally if Al is chosen as matrix element. However, you should always check if the results are reasonable at all. You should further have an eye on the automatic choice of major constituents which will be probably wrong and must be done manually (check start compositions and solubility ranges given in the MICRESS screen output upon initialisation).

Best wishes
Bernd

Thank you for your reply.
Based on the explanation you provided, I have set up a simplified ternary Al–Si–Mg system.
Although optimization and validation still need to be carried out, the basic calculations are completed without any issues.

In this project, the process conditions are being applied using the profile_from_file option.
However, despite the thermal history file has been prepared correctly, an abnormal thermal profile is actually being applied during the calculation.
The observed symptom is that temperature values way-far outreached the intended input range are being used.

Based on these observations, I suspect that the length scale in the depth (z-axis) direction is being interpreted incorrectly.
However, I'm unable to identify what is wrong with the input file.
As far as I understand, the length scale required in the input file should be given in centimeters.

I am considering a calculation over a depth of 100 microns. In the attached .dri file, the computational domain has been set sufficiently small so as not to exceed the range of the thermal history file.

Which part could be incorrect?

best regards, Ku

Dear Ku,

The solution is very simple: You apply the T-profiles from the file temp.txt only for times up to 8.15E-04 s (section "Process Conditions"), while your first output happens much later at 1.E-2 s. MICRESS will not stop after the last T-profile has been read, but extrapolate from the last 2 profiles, leading to negative temperatures.

Bernd

Dear Bernd,

I completely understood what I missed…
Thank you for your help.

Ku.

Hi, thanks to your help I have now successfully applied the process condition input using a temperature profile as intended, but there are still a few issues.

1. Although temperature profile is now being applied correctly, the solidification of the solid phase repeatedly stops at a certain point.
The temperature profile we applied is extracted from a PBF process, characterized by repeated rapid heating and cooling cycles.

Even after valid thermal cycles have passed and the temperature in domain cools below the equilibrium solidus temperature of our alloy system (890 K), the solid phase does not continue to grow properly and stop

More specifically, after solidification starts at around 890 K, the growth rate gradually decreases as the temperature drops to about 600 K and eventually stops completely. Even as the temperature further decreases down to 400 K, no additional solidification occurs.

We have confirmed a sharp decrease in the interface mobility, but we have not been able to identify the reason
Also we have tried modifying the max and interface energy value in the solid–liquid interface options, but not works. 2. As described above, once solid growth stops and the system has cooled by several hundred kelvin, error codes start to appear.
The following are some excerpts from the output:

complete relinearisation!
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
trying hard phases 0 3 level: 4 zp= 315985 error= 14
trying harder! Error = 14
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
trying even harder! Error 14

--> Force automatic start values
Thermo-Calc error 1611 MICRESS error 14 Thermo-Calc
# Error number 14 in Interface 0/ 25
# time: 3.750000000000009E-003 s
# Serious error in linearisation!

According to the error code descriptions, this corresponds to “too many iterations” in Thermo-Calc and to “Equilibrium 1 (SolveCGetLinTQ)” in MICRESS.
However, I am not sure whether this error is directly related to the issue I am currently experiencing, nor how it should be resolved. If it is important, I would appreciate a more detailed explanation.

Next, the error message # Serious error in linearisation! seems somewhat ambiguous.
If a fatal error has occurred but the calculation nevertheless continues, it is unclear to me how this error has been handled internally, and what kind of issues might be expected in the results obtained under this situation.
Could you please also explain this point?

In addition, after introducing liquid nucleation using add_to_grain, a very large number of nucleation events is reported.
As a result, the log and scr files become extremely long, making it difficult to read some information and error messages for certain time steps (and the file sizes also become very large, so they cannot be attached).
Is there any way to mitigate this issue? (This is of course not a critical problem.)


3. we are using the add_to_grain option for liquid nucleation.
The melting behavior seems to be represented as intended, but repetitive pattern appears during melting. This looks like a kind of numerical artifact.

Would introducing nucleation noise or changing the nucleation model from seed undercooling to a seed density model help resolve this issue?
For now, we do not consider this to be a very critical problem.

best regards, Ku

Dear Ku,

can you please also send me the .GES5-file which you have used in your simulation? Otherwise, I cannot try to reproduce your problems...

Bernd

Sorry for the delayed response.

I have attached the GES file.

Thank you.

Ku

Dear Ku,

It seems that the main issue (the stopping of the front despite of cooling) is caused by the combination of three problems:

1.) The diffusion coefficients in the LIQUID are much too low. This leads to a too low interface mobility obtained by mob_corr, so that the interface temperature drops strongly. This, in turn, reduces the LIQUID diffusivity further, eventually ending in a complete lockdown. Or, explained from another viewpoint: If diffusivity of the LIQUID is low, extremely fine microstructures would form, which are not well-resolved in the MICRESS grid. To avoid incorrect trapping effects and a too high interface velocity due to "overrunning" of solute pile-up, the 'mob_corr' mechanism then has to reduce the numerical interface mobility. The resulting unrealistic low temperatures reduce diffusion more, and would make microstructures even finer, ...
I guess, the unrealistic diffusion coefficients from database are caused by the use of a mobility database for high-temperature materials, where typical liquid temperatures are much higher, and the parameter fitting for diffusion coefficients has probably been optimized to this temperature ranges. I would not use these data, but rather set liquid diffusivity to 1.E-5 cm2/s by hand. Solid diffusion is not relevant in your case, but I also would mistrust the database here. You can review the diffusion coefficient as obtained from the database in the .diff-output. If you use other values from literature, please bear in mind that this changes required grid resolution (see below).

2.) Grid resolution is too low. Even if the diffusion coefficients of the LIQUID phase are set to 1.E-5 cm2/s, the microstructure is still not properly resolved, and the front temperature is incorrectly low. If you want to obtain reasonable results, you should reduce the grid spacing Δx to at least 0.01 µm. In principle, you can assume resolution to be sufficient, when further reduction of Δx does not lead to significant changes in those parts of the results which are relevant for you. It will, however, be difficult to ensure that for the fastest cooling stages.

3.) You cut the driving force to +/- 100 J/cm3 ('max 100.) for all phase interactions. This is reasonable if your grid resolution is fine, otherwise it contributes to the "lockdown" of the front which you have observed by cutting the driving force and further slowing down the front movement.

I have some more suggestions:
a) You have included 2 fcc-phases (FCC_L12 and FCC_L12#2) in your simulation, and use the second one as "fcc". Is there any reason behind? Due to the use of not suited databases, you should not assume the automatic creation of these 2 composition sets during creation of the .GES5-file has been reasonable. Although it seems to work as it is, I would advise to include only FCC_L12 as fcc-phase and manually define the major constituents when creating the .GES5-file, as shown e.g. in M247.TCM (within GES_Files in Applications directory of MICRESS examples).

b) You have defined nucleation of liquid in the temperature range above 700K. I would increase this limit to 920K to avoid continuous liquid nucleation even during the cooling stages.

c) Phase 3 (Mg2Si) is barely nucleating because nucleation is not checked often enough. When it is checked after long time then, undercoolling is so high that TQ-errors occur (see below). This seems to vanish when nucleating more often (e.g. all 1.E-6 s).

d) You are using a "global" relinearisation scheme with a 10 µm distance criterion. This distance is so large, that regions with different temperatures are included into a one single averaging region. I propose using "global 1." instead. You can visualize the averaging regions (scopes) using the .refR-output.

And with respect to your questions:
a) When melting occurs at the very beginning of your simulation, regular melting structures appear because of the homogeneous initial microstructure, and because "bulk" nucleation currently is checked in regular distances. This looks a bit strange, but should not have an important influence on the simulation results. As you suggested, you could heal that by using a seed-density model for nucleation. In the next MICRESS release we will use a different algorithm for chosing nucleation positions in bulk-nucleation (Halton-sequence). Then the problem of the regular pattern will disappear.

b) The problem of very long .scr- and .log-files unfortunately has no simple solution. However, using my proposal for a reduced temperature interval for liquid nucleation (see above) should already make them a bit shorter..

c) "serious error in linearisation" means that, even after trying different approaches, no linearisation data could be obtained at this time step. In order not to stop the simulation, old linearisation data are used instead. This potentially can lead to wrong results, especially if this error appears repeatedly for the same interfaces or interface regions. You can recognize that in the .TabLin-output, where older linearisation data still bear their old linearisation temperature (2nd column), reminding indirectly at which stage their data have been calculated successfully for the last time.

Best wishes
Bernd

Thank you for your confirmation.

After manually setting the liquid diffusivity, the calculations seem to run smoothly. (Of course, the re-linearization distance was also reduced. The grid resolution has not been changed yet, but further calculations are planned to examine the independent effects of the liquid diffusivity and the resolution.)

In this case, I determined the activation energy values by referring to those given in the .diff file. Would it be problematic to use the activation energy from the .diff output at a state where solidification has already stalled? (As mentioned later, activation energy values were no significant difference compared to calculations in which solidification does not stop.)

When the process condition is set to constant, even in calculations where a linear cooling rate and a temperature gradient are prescribed, the solute diffusion coefficients in the liquid remain at similarly low levels (on the order of ##.E-6 to E-7). Nevertheless, no problems occur during solidification, and the activation energy values are also of comparable magnitude with stoped one.

Of course, in this case it should be taken into account that the calculation uses a relatively slow cooling rate and a low temperature gradient, since these were taken from a representative time step of the repeated thermal history provided via profiles_from_file. In that calculation, solidification was completed before reaching the temperature range in which solidification stalling occurs.


In addition,

Diffusion coefficients in LIQUID (Seg_2):
Time: 0.0000 s
Temperature: 910.489999999998 K
Composition MG: 9.0933E-07 wt%
Composition SI: 6.7950E-07 wt%

is there an error in the composition lines printed in the .diff file? The actual initial liquid composition should be on the order of ~0.909%, but in the exponent appears to be incorrect.

Regarding your suggestion a) the reason why two FCC composition sets were activated simultaneously was that we were not confident which one would be the stable matrix phase.

From Thermo-Calc equilibrium and Scheil calculations, the matrix phases obtained were FCC_L12 and FCC_L12#2, and the compositions of each phase were also consistent with the equilibrium compositions of the alloy system.

Initially, we activated both composition sets simultaneously and intended to let MICRESS automatically determine the stable phase during the simulation (more precisely, we planned to regard the phase that solidifies first as the stable one).

Based on our previous experience, when preparing this file we used the equilibrium option for the initial composition input and specified only the composition of phase_0 (liquid), while filling the entire initial microstructural domain with the primary solid phase.

In this case, however, the composition of the input primary solid phase was determined in an abnormal values, and during repeated melting–solidification cycles we observed artifacts in the composition throughout the solid–liquid region.
Afterwards, we decided to explicitly set the equilibrium compositions for all phases, and abandoned the previously mentioned procedure of automatically selecting the stable phase.

Finally, regarding the composition set definitions in the M247.TCM file you provided: if confusion between composition sets occurs, can this be resolved simply by explicitly specifying the compositions of all phases during the initial composition setup? If so (or even if not), would it be more appropriate to consider defining the composition sets properly at the database level as the better solution?

Thank you again for your always thoughtful and detailed replies.

Best regards,
Ku.