Complete rework of relinearisation options

Posts: 760
Joined: Mon Jun 23, 2008 9:29 pm

Complete rework of relinearisation options

Postby Bernd » Tue Oct 10, 2017 6:23 pm

Dear MICRESS users,

For the MICRESS 6.400 release, the existing relinearisation options have been strongly reworked and complemented by additional options. Updating relinearisation data is often very time-consuming, and the user needs to decide how often and at which scope such an updating is necessary - eventually he will have to decide by weighting simulation time vs. exactness and numerical stability.

In general, when using TC-coupling to thermodynamic databases, quasi-equilibrium conditions at the interface are calculated which needs access to the database and to the Thermo-Calc (TQ) calculation engine, and which is time-consuming. Afterwards, depending on the chosen updating scheme, these data are extrapolated and used for a certain time before updating is performed. While the way how the updating frequency is controlled has not changed recently (two independent inputs for all interfaces and each phase interaction, either at constant intervals ("manual"), time-dependent intervals ("from_file") or after a certain temperature change ("automatic")), the focus here is on the scope or spatial reference where the linearisation are calculated and valid for.

All in all, 5 such options are now available which can be specified following the "database" keyword in the phase diagram input data of each phase interaction, 3 of which were already part of version 6.300. Default is "local" linearisation which means that each interface cell bears its own set of linearisation data. The option "global" means that each interface between two specific grains will get its own data set, which strongly reduced the effort of updating. In order to increase "locality" and exactness, this spatial scope can be narrowed to each interconnected segment ("fragment") of the interface region for a specific grain pair.

As new option, "globalG" connects one set of linearisation data to all interfaces between two phases, so that it comes close to a "linearized phase diagram", or more precisely the "linTQ" mode with the important difference that the data are automatically calculated and updated based on the average interface compositions and temperature. Nevertheless, this mode should be regarded as a fully global description. In combination with the idea of interconnected segments, the "globalGF" mode finally defines common linearisation data for interconnected segments ("fragments") of phase interfaces which may span several grain interfaces belonging to the same phase pair.

In terms of "locality", the following order can be defined:

"local" > "globalF" > "global" > "globalGF" > "globalG"

In general, the spatial scope given by these options corresponds as well to the region where the common linearisation data is valid as well as the region where the average interface composition is retrieved for calculation of updated linearisation data.

In multi-phase regions (triple junctions), this procedure may lead to local inconsistencies between the different phase interfaces, because they use linearisation data sets which may have been averaged based on different spatial regions (as the integration area for each interface also includes dual interface regions). If necessary, this problem can be avoided using the option "database_consistent" which separates the triple point areas from the dual interface regions both in terms of the range of averaging of interface compositions as in terms of the range of validity of the linearisation data.

"database_consistent" is only available globally for all interfaces and essentially splits the relinearisation areas into smaller consistent blocks. If different option collide at the triple junctions, the one with the highest "locality" will inherit its properties to the other coexisting interfaces to keep consistency in all cases.

Posts: 760
Joined: Mon Jun 23, 2008 9:29 pm

Recommendations for usage

Postby Bernd » Tue Oct 10, 2017 7:32 pm

The more options are available to the user, the better the chance to find an optimal solution for a given application, but also the higher the difficulty to make a choice. Therefore some recommendations:

The higher the locality of the option, the higher typically is the time consumption for the updating of the linearisation data, but also the higher is the exactness. Although the "local" option is default, it may be very hard to afford the updating times in case of multi-component systems with many elements like superalloys. In such cases, the most reasonable choice should be the "globalF" option which combines maximum of "locality" with a strong reduction in computational costs with respect to "local" updating. On the other side, the options "global" and "globalG" which exhibit much less locality should be used only if conditions (concentrations, temperature) are quite homogeneous, so that the assumption to use the same linearisation data in regions which may be far apart is justified. In any case, a comparison of the simulation results using different options should be done to get a feeling about the effects on exactness.

However, apart from locality versus simulation time, there may exist other important factors to be taken into account. One of them is "thermodynamic noise" which comes from the fact that each region with separate thermodynamic description has a slightly different driving force, which is not "physical" but rather an artefact of discretisation. If this "noise" is so big that it gets comparable to or even bigger than curvature or average driving forces, this leads to unexpected and wrong behaviour. A good example for that is Ostwald ripening where curvature is the only driving force, and any disturbances by noise are problematic. In this case "globalG" appears to be the best option as conditions are very similar at all interfaces, and one single set of linearisation data is optimal with respect to noise and performance.

Another factor which should be mentioned is the case when we use "diagonal" interpolation (defined in the section of stoichiometric phases). This type of extrapolation of linearisation data on one side avoids "demixing" effects, but on the other side may create driving force differences along the interface normal when extrapolating too far These differences may lead to unexpected instabilities of the interface which can be cured by more frequent updating and more locality of the updating option (extrapolating "too far" can be either due to high updating intervals or using the same set of linearisation parameters in different regions under different conditions).

The global option "database_consistent" should be used only when really needed. Apart from the generally increased calculation time, the increased locality by separating triple junctions from dual interfaces may lead to a specific form of "thermodynamic noise" problem: If triple junctions systematically have slightly different linearisation data than the adjacent dual interface, a systematic distortion of the growth morphology can be the consequence, which could in principle even worsen the consistency problem. More experiences are needed for this option.

In future, I will add more information in this thread about the individual options with their pros and cons according to our experiences. Users are also invited to share their own experiences here.


Return to “MICRESS Version 6.4”

Who is online

Users browsing this forum: No registered users and 1 guest