0

iTOUGH2 ignoring initial successful step

I'm having an issue with an inversion of a TOUGHREACT simulation using the PEST protocol.  During each iTOUGH2 iteration, the initial step reduces the objective function but is still labeled as unsuccessful.  It then tries another (larger) value for the Levenberg parameter, which still reduces the objective function, albeit not as much as the first attempt did.  However, this step is labelled successful, and the inversion proceeds.  The attached output file (tclpi.out) shows what I'm talking about.  I get roughly the same results when attempting to run this problem on two different machines, both of which run iTOUGH2 version 7.1.1.

You can also access a zip file containing all of the input files needed to run the simulation here: https://iu.box.com/s/ag32qxzwfyjubnuzihdl5q0s8dmt1blw

It's a bit of a mess, since it involved multiple restarts of a TOUGHREACT simulation.  However, you can run it by unzipping the attached file and running the command 'itough2 -pest tclpi &' in the unzipped folder.  You can then see the results I'm getting using a python script I generated by running the command 'python plotp.py'.

Are there, perhaps, other criteria that determine if an LM step is successful than whether or not it reduces the objective function?

2 replies

null
    • Mikey_Hannon
    • 5 yrs ago
    • Reported - view

    So I think I may have figured this out.  Stefan Finsterle, please correct me if I'm wrong, but when assessing whether an inversion step is successful, iTOUGH, in addition to checking if the objective function is reduced, also determines if a sufficient number of parameters have an appreciable influence on the model output.  If more than half do not, then iTOUGH deems this step unsuccessful, even if it reduces the objective function.  In my example, I set most of the parameters as inactive using the >>>> INACTIVE command, so I could troubleshoot which parameters should be estimated, and which should remain fixed.  As written, the iTOUGH2 source code treats inactive parameters as those not providing any influence on the model output, so when making a decision on a step's success, most (as in, more than half) of the parameters were insufficiently influential on the model output, and it was labeled unsuccessful.  So I changed the source code to ignore parameters users label as inactive when making this assessment, and my issue appeared to be resolved.  

    • Finsterle GeoConsulting
    • Stefan_Finsterle
    • 5 yrs ago
    • Reported - view

    Hi Mikey,

    I'm glad you figured it out. Your explanation is essentially correct. However, the automatic parameter selection feature has to be explicitly invoked by the user, and you did not chose to use this option. So the real issue is - as you correctly identified - that iTOUGH2 treated inactive parameters as if they were parameters that are temporarily disabled due to lack of influence - which it shouldn't! These are two separate reasons why a parameter is fixed, and the use of inactive parameters should not prevent acceptance of an otherwise successful step. I'm baffled why I never ran into this issue before (as I frequently use inactive parameters). I changed the code accordingly. Should anyone have the same issue, please contact me.

    Thanks again for your careful analysis of iTOUGH2 outputs!

    Stefan

Content aside

  • 5 yrs agoLast active
  • 2Replies
  • 37Views
  • 2 Following