mob_corr

new developments, future functionalities, hints for further applications of MICRESS
Post Reply
CharMIC
Posts: 181
Joined: Mon Aug 21, 2017 5:01 pm
anti_bot: 333

mob_corr

Post by CharMIC » Mon Jun 25, 2018 2:28 pm

Hej Bernd,

Could you explain bit more about this backward and forward redistribution behavior for the elements.

BR
Chamara
Attachments
mob_corr.JPG
mob_corr.JPG (28.98 KiB) Viewed 965 times

Bernd
Posts: 1038
Joined: Mon Jun 23, 2008 9:29 pm

Re: mob_corr

Post by Bernd » Mon Jun 25, 2018 4:38 pm

Dear Chamara,

The "backward" optional input has only relevance in conjunction with the unsymmetrical models "nple" and "para"/"paraTQ". For those models, the redistribution behaviour depends on the movement direction of the interface (NPLE, paraequilibrium/nple). Thus, it is possible e.g. to use nple for the forward and para for the backward direction.

Bernd

CharMIC
Posts: 181
Joined: Mon Aug 21, 2017 5:01 pm
anti_bot: 333

Re: mob_corr

Post by CharMIC » Sun Jul 22, 2018 9:57 pm

Hej Bernd,

Could you please explain the different between atc and normal mob_corr

BR
Chamara

Bernd
Posts: 1038
Joined: Mon Jun 23, 2008 9:29 pm

Re: mob_corr

Post by Bernd » Mon Jul 23, 2018 9:00 am

Dear Chamara,

I am not sure in which respect you wish more details. Do you more information how the nple model works? In any case, using different redistribution models depending on moving direction of the interface is very specific, and I even don't know a concrete application case...

Bernd

CharMIC
Posts: 181
Joined: Mon Aug 21, 2017 5:01 pm
anti_bot: 333

Re: mob_corr

Post by CharMIC » Mon Jul 23, 2018 3:43 pm

Hej Bernd,

Let me ask a specific question then.

Could you explain why atc mob_corr has been used in "T015_Gamma_Alpha_FeC_Acicular" example. Cant we use normal mob_corr

BR
chamara

Bernd
Posts: 1038
Joined: Mon Jun 23, 2008 9:29 pm

Re: mob_corr

Post by Bernd » Mon Jul 23, 2018 8:40 pm

Hej Chamara,

The "normal mob_corr" option should be sufficient if the key issue is to assure correct interface kinetics. However, the artifacts from a not-thin interface - if not corrected - not only lead to wrong kinetics but also to a incorrect solute distribution inside the interface region. The consequence can be an artificial trapping of solute, which has the side effect that there might be a slightly wrong redistribution, especially in case of non-stationary growth, which can be more efficiently corrected using the "atc mob_corr" option. In this case, an explicit anti-trapping current is applied to achieve the correct solute distribution profile through the interface (at least in the 1d approximation).

While this trapping effect might be of interest especially in case of quantitative benchmarks, for the technical applications the question is more important whether the "atc" option could perhaps increases or decreases stability. Up to now, we did not make a systematic evaluation on that. I, personally, don't use "atc" at present, because in complex multicomponent simulations it definitively would increase complexity, because it could be very difficult to identify additional problems which theoretically could be triggered by this option. To the contrary, Janin (who designed the "T015_Gamma_Alpha_FeC_Acicular" example) typically uses "ATC", and perhaps I am wrong, and "ATC" increases stability...

Anyway, we up to now never had negative experiences with the option. Everybody is invited to try it out him/her-self (and comment in this forum!).

Post Reply