Flawed upstream boundary condition in 1D IonFlow?

[ischoegl]

Problem description

There appears to be an inadequate upstream boundary condition in IonFlow. For charged species, the upstream boundary condition uses a von Neumann (zero gradient!) assumption, where the following rationale is provided:

cantera/src/oneD/IonFlow.cpp

Lines 178 to 185 in ba13c65

	for (size_t j = jmin; j <= jmax; j++) {
	if (j == 0) {
	// enforcing the flux for charged species is difficult
	// since charged species are also affected by electric
	// force, so Neumann boundary condition is used.
	for (size_t k : m_kCharge) {
	rsd[index(c_offset_Y + k, 0)] = Y(x,k,0) - Y(x,k,1);
	}

There are obvious concerns about the physicality of this boundary condition; mathematically, this appears to impose von Neumann conditions for both inlet and outlet, which is inherently ill defined. Finally, the short-cut does not accommodate a case where a user could specify a non-zero upstream concentration of a charged species (where a convective term added in Boundaries1D::eval would be quite problematic).

While upstream gradients may be sufficiently small for this ad-hoc assumption to work for a free flame (i.e. ion_free_flame.py), it appears that this assumption is inadequate for burner-stabilized flames. However, the assumption does not appear to be a root cause for poor convergence (see Additional Context).

System information

• Cantera version: 2.5
• OS: Ubuntu 18.04
• Python/MATLAB/other software versions: 3.6

Additional context

The example ion_burner_flame.py exhibits extremely poor convergence with multiple errors thrown (recovered in auto solution mode)

***********************************************************************
CanteraError thrown by OneDim::timeStep:
Took maximum number of timesteps allowed (500) without reaching steady-state solution.
***********************************************************************

As this happens during stage 1 of the solution (i.e. using IonFlow::frozenIonMethod) where m_flux of charged species is set to zero (and the code section above is bypassed), the boundary condition is not a root cause. Commenting out the lines where the BC residual is set in IonFlow::evalResidual does indeed not change the behavior.

Poor convergence is also observed for Cantera 2.4, i.e. the version where the example was initially introduced.

[bryanwweber]

@BangShiuh Can you look into this?

[BangShiuh]

@ischoegl Thank you for the report. I agree that the boundary conditions need to be fixed. I think that poor convergence might be improved by implementing scharfetter-gummel scheme (a better scheme for a drift-diffusion problem). I will work on this when I have time. If anyone is interested in this I can also provide some guidance for implementing the scheme!

[ischoegl]

@BangShiuh ... thank you for your comments. Regarding your thoughts about improved drift-diffusion solvers, I wanted to double-check about the implementation. The convergence issues occur for stage 1 of the solution, where ions are presumably immobilized and the poisson solver is disabled. Also, did you observe any convergence issues when you first put the burner flame example together?

[BangShiuh]

I believe that I didn't have the convergence issues when I made it for all stages. Stage one especially should not have convergence issues.

[ischoegl]

@BangShiuh ... thanks for your response. In the meantime, I confirmed that the convergence issue is linked to the calculation of mass fluxes. If I disable the IonFlow::frozenIonMethod, i.e.

void IonFlow::updateDiffFluxes(const double* x, size_t j0, size_t j1)
{
    if (m_stage == 1) {
        StFlow::updateDiffFluxes(x, j0, j1);
        // frozenIonMethod(x,j0,j1);
    }
    if (m_stage == 2) {
        electricFieldMethod(x,j0,j1);
    }
}

there aren't any convergence issues. I looks like poor convergence is intrinsic to the implementation, as it already showed up in Cantera 2.4.

Is there any specific reason why ions are immobilized in stage 1? It's conceivable to treat ions as regular species in stage 1, and enable the electric field in stage 2 (i.e. similar to what's done when the soret effect is enabled).

[ischoegl]

The offending dYdz condition is actually slated for removal in #700. The same change is also applied in #912.