Feature request: support for minimum iterations in stop criteria

[Arsennnic]

I would like to suggest a feature enhancement for the stop criteria: adding support for min_iters, i.e., a minimum number of iterations.
Many other linear algebra libraries have already implemented this feature. For example, PETSc provides the KSPSetMinimumIterations function, and Hypre offers a series of HYPRE_*SetMinIter functions.

I would like to configure the Ginkgo solver with the following JSON file,

{
    "type": "solver::Cg",
    "preconditioner": {
        "type": "preconditioner::Jacobi"
    },
    "criteria": [
        {
            "type": "ResidualNorm",
            "baseline": "absolute",
            "reduction_factor": 1e-5
        },
        {
            "type": "Iteration",
            "max_iters": 20,
            "min_iters": 2 // Sets the minimum number of iterations, regardless all other stop criteria
        }
    ]
}

I tried modifying the code of gko::stop::Iteration and defined an additional parameter min_iters.

bool Iteration::check_impl(uint8 stoppingId, bool setFinalized,
                           array<stopping_status>* stop_status,
                           bool* one_changed, const Updater& updater)
{
    if (updater.num_iterations_ >= parameters_.min_iters) {
        bool result = updater.num_iterations_ >= parameters_.max_iters;
        if (result) {
            this->set_all_statuses(stoppingId, setFinalized, stop_status);
            *one_changed = true;
        }
        return result;
    }
    else {
        return false;
    }
}

However, I found that multiple criteria are combined through an OR operation using gko::stop::Combined. This means that if other stopping criteria are satisfied (i.e., check_impl returns true), the iteration process will stop regardless, so modification on gko::stop::Iteration is ineffective unless an AND operation provided.

Would you be willing to add support for this feature?
Alternatively, what would be the minimal code change required to implement it by myself?

[upsj]

What is the use case for a minimum iteration count? What should happen if the initial guess is already good enough, i.e. the initial residual is essentially 0?

This could also not be supported by all solvers, e.g. GMRES can run into a lucky breakdown scenario where the Krylov subspace already contains the solution (either exactly or up to rounding error), leading to the Hessenberg matrix becoming singular.

[Arsennnic]

Imagine the following scenario.

When writing a fluid simulation program, it is common to use the solution from the previous time step as the initial guess for the linearized system at the new time step. If the time step is small, the initial guess​ may already satisfy the residual, causing the physical field to remain unchanged during the new time step. If we introduce a minimum iteration count (assuming the solver supports it), the physical field will change and better satisfy the linear system.