Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pricipitate free energy modification and related convergence errors #201

Open
zzzmx-josh opened this issue Dec 26, 2023 · 0 comments
Open

Comments

@zzzmx-josh
Copy link

Hi there.
I am seeking clarification on a matter related to the modification of simulation parameters for Mg-Gd alloy in the /applications/precipitateEvolution/parameters.prm file.

Upon comparing the simulation parameters in the mentioned file with those from the research paper by H. Liu et al. titled "A simulation study of the shape of β′ precipitates in Mg–Y and Mg–Gd alloys" (Acta Materialia 61, 453–466, 2013), I observed that the parameters related to β' do not align. Specifically, the parameters in the file are set as follows:

set Model constant B2 = 5.0, double
set Model constant B1 = -5.9746, double
set Model constant B0 = -1.5924, double

In contrast, the paper defines these parameters as:
[F_{\beta^{\prime}}(x_{\mathrm{Gd}}) = 5 x_{\mathrm{Gd}}^{2} - 0.05 x_{\mathrm{Gd}} - 3.8208]
I am curious about the rationale behind this modification. I attempted to adjust B1 and B0 to match the parameters from the paper, but encountered convergence issues after a certain number of steps, as indicated in the error message below:

time increment:40  time: 0.024
field ' c' [explicit solve]: current solution: 7.039495e+17, current residual:3.735857e+16
field 'n1' [explicit solve]: current solution: 4.735668e+29, current residual:4.294138e+28
field 'n2' [explicit solve]: current solution: 1.603496e+17, current residual:1.099306e+16
field 'n3' [explicit solve]: current solution: 2.110432e+17, current residual:1.411982e+16

An error occurred in line <1654> of file </home/mxzhu/src/dealii-9.2.0/include/deal.II/lac/la_parallel_vector.templates.h> in function
    dealii::LinearAlgebra::distributed::Vector<Number, MemorySpace>::real_type dealii::LinearAlgebra::distributed::Vector<Number, MemorySpace>::norm_sqr_local() const [with Number = double; MemorySpace = dealii::MemorySpace::Host; dealii::LinearAlgebra::distributed::Vector<Number, MemorySpace>::real_type = double]
The violated condition was: 
    dealii::numbers::is_finite(sum)
Additional information: 
    In a significant number of places, deal.II checks that some intermediate value is a finite number (as opposed to plus or minus infinity, or NaN/Not a Number). In the current function, we encountered a number that is not finite (its value is (-nan,0) and therefore violates the current assertion).

This may be due to the fact that some operation in this function created such a value, or because one of the arguments you passed to the function already had this value from some previous operation. In the latter case, this function only triggered the error but may not actually be responsible for the computation of the number that is not finite.

There are two common cases where this situation happens. First, your code (or something in deal.II) divides by zero in a place where this should not happen. Or, you are trying to solve a linear system with an unsuitable solver (such as an indefinite or non-symmetric linear system using a Conjugate Gradient solver); such attempts oftentimes yield an operation somewhere that tries to divide by zero or take the square root of a negative value.

In any case, when trying to find the source of the error, recall that the location where you are getting this error is simply the first place in the program where there is a check that a number (e.g., an element of a solution vector) is in fact finite, but that the actual error that computed the number may have happened far earlier. To find this location, you may want to add checks for finiteness in places of your program visited before the place where this error is produced. One way to check for finiteness is to use the 'AssertIsFinite' macro.

Stacktrace:
-----------
#0  /home/mxzhu/usr/lib/libdeal_II.g.so.9.2.0: dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host>::norm_sqr_local() const
#1  /home/mxzhu/usr/lib/libdeal_II.g.so.9.2.0: dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host>::norm_sqr() const
#2  /home/mxzhu/usr/lib/libdeal_II.g.so.9.2.0: dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host>::l2_norm() const
#3  ./main: void dealii::SolverCG<dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host> >::solve<MatrixFreePDE<2, 2>, dealii::IdentityMatrix>(MatrixFreePDE<2, 2> const&, dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host>&, dealii::LinearAlgebra::distributed::Vector<double, dealii::MemorySpace::Host> const&, dealii::IdentityMatrix const&)
#4  ./main: MatrixFreePDE<2, 2>::solveIncrement(bool)
#5  ./main: MatrixFreePDE<2, 2>::solve()
#6  ./main: main

It is my understanding that modifications to free energy should not lead to convergence problems. Could you provide insights into the factors influencing this issue? Additionally, it seems that these parameters can only be adjusted within the parameter.prm file—is this correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant