Implementation of inclination dependence of the GB energies through $\gamma$ in New phase-field model by Moelans in 2022

[yixishen]

Dear MOOSE community,

I am aiming to develop a phase-field (PF) model with a strong inclination-dependent anisotropic grain boundary (GB) energy and mobility. I understand that GBAnisotropy can be utilized for calculating PF parameters following the framework established by Moelans et al. in their 2008 Phys. Rev. B publication (Phys. Rev. B 78, 024113 – Published 16 July 2008). To my knowledge, the inclination dependence is incorporated via angle-dependent PF parameters such as $\kappa(\theta)$ and $\gamma(\theta)$, without necessitating additional terms in the evolution equations (specifically, the Allen-Cahn equation).

However, recent advancements by Moelans (2022) suggests that to have inclination dependent in a fully variational way, as $\kappa$($\theta$) is essentially a function of the gradient of order parameters $\eta_i$ and $\eta_j$, an extra term is introduced to the evolution equations:
$$- m \nabla \cdot \left( \sum_{j \neq i} \left( \frac{\partial \gamma_{ij}}{\partial n_i} \right) n_i^2 n_j ^2\right)$$

And my question is, does moose has any kernel that support this term? Or I may need to create my own function/application for this term?

Thanks
Yixi

[GiudGiud]

@laagesen @jiangwen84

[GiudGiud]

It could be slower in parallel if the custom code is not efficient. Do you use all 48 cores on the cluster?

[yixishen]

Yes that is correct! We have not implemented AD versions of many of the phase-field kernels because we already have full Jacobians implemented. AD versions have been found to be slower than non-AD versions which have the full Jacobians implemented. However in cases where the Jacobians are so complex they haven't been implemented, the AD version performs better.

I have some general questions.
1), If I decided to use AD version, does that mean all other kernel should also be using an AD version? For example, the second term in the evolution equation, $-Lm(\eta_i^3 - \eta_i + 2 \eta_i \sum_{j \neq i} \gamma_{ij} \eta_i^2)$, is embedded via kernel ACGrGrMulti.
2), I noticed that the ACGrGrMulti.C source code has parts for both AD and non-AD version of ACGrGrMulti. By using "
registerMooseObject("PhaseFieldApp", ADACGrGrMulti); ", the ADACGrGrMulti is also register in MOOSE. Does that mean I can just use an AD version by defining the type to ADACGrGrMulti?

[GiudGiud]

1. no you can mix and match AD and non AD objects in the input file. The only thing is that some material properties might be required to be AD to build / use AD kernels

2. yes. When both are registered it means both versions are available, selectable through the type of the object in the input file

[yixishen]

Thank you for your quick response. I have grabbed some source code for the extra term and pushed to my own GitHub. I'm still testing and debugging. May I ask what is the properl if I would like you to take a look at these codes?

Thanks
Yixi

[GiudGiud]

Hello

I don't know much about phase field. If you hit issues we will try to tag someone more knowledgeable.
The best way to share code is to make a github repository

[yixishen]

I test it with a very small model, so I only use 4 cores. In fact, the model is initiated at 200 by 200 mesh, one core is ok.On Jun 4, 2024, at 4:00 AM, Guillaume Giudicelli ***@***.***> wrote: It could be slower in parallel if the custom code is not efficient. Do you use all 48 cores on the cluster? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[GiudGiud]

Ok let's stick to one core then

Using a debugger (see debugging instructions on our website) on the cluster with one core, use the interrupt at regular intervals to find out in which line the code is spending a lot of time / getting stuck

Alternatively, use a profiler (see profiling instructions) on the Mac to find the slow section