Convergence failure at production well

Hi everyone,

I am trying to heat up water and NAPL (atmospheric pressure) with a production well for vapor extraction at cell #341 (atmospheric pressurre and productivity index 1e-10 m3 ). The simulation stops after reaching 0.5 hours. It seems the issue is related with cell #341. But I can't figure out why. Can anyone please help? Thanks a lot!


3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Can you re-run the simulation with MOP(5)=3?  This will print out EOS information that may shed some light on your issues. 

  • Hi Mikey,


    Thank you for your reply. Is this part the EOS info print-out? It seems weird cuz temp and SG got negative somehow. Would you mind taking a look?


    Thank you!


    • Antonio Wu , I'm sorry for taking so long to respond to you.  The printout it's giving is from the intermediate Newton-Raphson (NR) attempts to move the simulation forward during the current time step.  Many of these calculations, particularly those on the verge of a phase transition, will result in nonphysical outputs.  However, these are not the values that TOUGH will ultimately use when updating to the next time step.  Instead, it will abandon the attempt at this particular time step when this occurs, then try a smaller time step.  Eventually (as is what happened in your case), the time steps will continue decreasing until they're too small for the simulation to continue, and it will give up.  The stop criterion you've encountered (if this is the same simulation as the one in your previous post) is when convergence failure occurs after two time steps that were performed successfully with a single NR calculation.  Many times, it stops for good reason.  However, if you think that something particular (i.e., a sharp change in conditions) in your simulation occurs at that time that you feel merits really small time steps that may or may not fail during intermediate calculations, there is a setting in the MOMOP block in TOUGH3 or iTOUGH2 (MOP2(1)) that stipulates a minimum number of NR calculations to occur before a time step completes.  Set this value to something greater than 1 (if you're going with this idea, I suggest 2), and it will prevent the simulation for stopping for this reason.  However, I suspect in your case (as in with most others) this is only delaying the inevitable, and you'll soon find the simulation terminating for some other reason.

      To get to the root of your problem (if I can), I'll need to see more of your inputs and outputs.

Like Follow
  • 1 yr agoLast active
  • 3Replies
  • 58Views
  • 2 Following