TOUGH3 CYCIT: failed PETSc solve can be accepted as a timestep when MOP(17)=9

Hi,

I would like to report a suspected timestep-acceptance bug in CYCIT (src/Main_Comp.f90) when a PETSc linear solve fails and MOP(17)=9 requests timestep reduction.

In my tests using TOUGH3–FLAC3D (EOS3), an unsuccessful linear solve was followed by an apparently accepted timestep, advancing simulation time and writing FOFT/GOFT records without updating the monitored temperature and pressure values. A local source-level modification corrected this behavior in my test case.

I also identified the same relevant control flow in the Main_Comp.f90 source file from TOUGH3 v1.1.

In the CYCIT routine, the return status of the linear equation solver (called through the internal LINEQ routine) is checked only after the computed correction has been accumulated into DX.

The relevant error-handling section is:

if (IGOOD .NE. 0) then
    IGOOD = 0
    if (MOP(17) .EQ. 9) exit
endif

When LINEQ fails and MOP(17)=9, this resets IGOOD to zero and exits the Newton iteration loop.

However, the subsequent timestep-acceptance condition is:

IF (IGOOD.EQ.0 .AND. ITER .LE. NOITE) THEN
    timestep_is_good = .true.
    ...
ENDIF

Consequently, a failed linear solve can satisfy the timestep-acceptance condition even though nonlinear_converged remains .false.

As a result, the simulation may bypass the intended timestep reduction and incorrectly advance the simulation time while writing FOFT/GOFT records, even though the linear solver has not converged.

With MOP(16)=2, the timestep-selection logic can additionally increase the next timestep, exacerbating the behavior.

Verification: In the original simulation, nine PETSc failures were associated with additional FOFT/GOFT records and an extended period of unchanged temperature and pressure. After modifying the timestep-acceptance logic, a diagnostic simulation completed 755 accepted timesteps, with 755 FOFT records. All 12 PETSc failures triggered timestep reduction, and the temperature and pressure fields continued evolving.

This appears to be a timestep-control issue in TOUGH3 exposed by linear-solver nonconvergence, rather than a defect in PETSc itself.

I would appreciate clarification on the following:

1. Is the IGOOD=0 / EXIT / timestep-acceptance sequence a known issue in TOUGH3 v1.1 or other versions?
2. Is an official correction available, particularly for PETSc failures with MOP(17)=9?
3. Should additional safeguards be implemented for MPI synchronization, state rollback, hysteresis variables, or other MOP(17) settings?
4. Has this issue already been addressed in newer TOUGH3 releases?

I can provide before/after diagnostic log excerpts and a source-code diff.

My current numerical reproducer is a large coupled model. I have not yet developed a small-grid standalone reproducer, as recommended in the forum guidelines.

Thank you for your feedback.