Automatic mobility control in Version 6.4 ("mob_corr")

Information and Discussions specifically about MICRESS 6.4
Post Reply
Bernd
Posts: 1502
Joined: Mon Jun 23, 2008 9:29 pm

Automatic mobility control in Version 6.4 ("mob_corr")

Post by Bernd » Sat Sep 16, 2017 3:47 pm

Dear all,

From MICRESS Version 6.4 on, the option "mob_corr" should play an important role for most MICRESS users. This option is somewhat hidden as optional parameter at the end of each phase diagram input which is invoked by the (optional) keyword "redistribution_control" in the phase interaction data input:
red_control.JPG
red_control.JPG (124.84 KiB) Viewed 79425 times
mob_corr.JPG
mob_corr.JPG (115.76 KiB) Viewed 79425 times
The option "mob_corr" has already been available before. However, it was still in an experimental stage, and there were some problems with multicomponent systems and strong off-diagonal terms of the diffusion matrix.

Now, these problems have been solved, and we can generally recommend usage of this option for diffusion-controlled phase transformation. However, this does not apply to cases where spatial resolution is not sufficient, and artificially low mobility values have to be applied to avoid numerical instabilities (e.g. poorly resolved precipitates).

With "mob_corr", still a mobility value (or T-dependent tabulated data) has to be provided in the phase interaction data section. This value can be interpreted as "physical" value, which is reduced to an "effective" mobility via the "mob_corr" option. Practically, the value should be big enough to exceed the highest expected effective mobility which will be required in any place of the domain. Using a T-dependent mobility definition ("temp_dependent") it is also possible e.g. to have "diffusion limited" interface kinetics at high temperature, and a switch to numerically motivated lower interface mobilities at lower temperatures.

"mob_corr" can be defined for each element independently. Note that the option should never be combined with "nple" or "para"/"paraTQ", because these options are typically used for elements which diffuse so slowly that they are completely overrun without redistribution, or their pile-up at the interface is much too short to be spatially resolved.

After the keyword "mobcorr", an additional factor can be specified, which weights the effect of each element on the interface mobility. E.g. specifying

...
normal mob_corr 2.0
...

will increase the effect of the given element on the interface mobility by a factor of two, and thus more strongly reduce the mobility value.

Bernd

Post Reply