My original INFILE (isotropic permeability cases, INFILE_Base and INFILE_PMX in the attachment) works perfect for me under TOUGH3-EOS7.

For the modification (INFILE_AnIsoPerm in the attachment), I only change MOP2(20) =1 , and set Kxx = Kyy = Kzz in colume 81-110 with values exactly same with my original INFILE (INFILE_Base and INFILE_PMX in the attachment).

I expect I should have same output results. However, the execution of my modification (OUTPUT_AnIsoPerm in the attachment) have some numerical problem – cannot converge.

The following web-link (dropbox) contains the INFILE_BASE and some of its final output (*.CSV) if you are interested about it. It took about 14 hours to run it in my machine. The dropbox directory also contain the input and output files of the INFILE_AnIsoPerm case that diverge at the very beginning.

Your test problems are similar to the ones I tried. I have not figured out what is wrong, but I have some suspicions. I am going to check with Yoojin Jung, who did the coding. If possible, try running just a few time steps of your AnisoPerm case with just one processor. For my case with mop2(20)=1 and permeability modifiers in columns 81-110 of the ELEME block, TOUGH3 worked on one processor but failed when using multiple processors, and I am interested in what happens for you.

As far as I know, if you want to run in parallel with element-by-element anisotropic permeability, TOUGH3 is the only code that attempts to do that.

I got a similar error message when trying to use MOP2(20)=1 and putting permeability modifiers in columns 81-110 for a big problem (134,000 elements). I switched to MOP2(20)=0 and putting a permeability modifier in columns 41-50 and the code did not produce an error message, but I am not confident that the results are correct. When I created a small test problem (18 elements), I could use MOP2(20)=1 without an error message, but again I do not think the results are correct. Yoojin is busy this week, but she said will look at the code next week. If you can wait that long, I think she is the best person to try to figure out what is happening. As a work around, I created a model with 22 different materials to represent a heterogeneous permeability distribution, so I would not have to use element-by-element heterogeneity. That seems to be running correctly.

I am not sure why your problem (3) is giving such big residuals. But some of the values in the PARAM block are surprising to me. Could you try it again changing NOITE from 4 to 8 (or blank as 8 is the default), changing RE1 from 1.E-4 to 1.E-5, and changing the initial time step from 100. to 0.01 sec? If it still fails with these changes, that makes me more sure that the problem is due to using element-by-element permeabilities.

For now, I want to wait until Yoojin can respond to think about Cases 2 and 3. For case 1, you said it ran okay. From what I can tell, you have mop2(20)=0 so the code should take the permeability modifier from columns 41-50 in the ELEME block. This permeability is given as 1.e-6, which is much bigger than the permeability in the ROCKS block, so the pressure response should be much different than the base case. If it is not too much trouble, could you check that the pressure responses are actually different for case 1 and the base case? In one of my test problems with mop2(20)=0, I found by looking at the pressure response that the permeability modifier was not actually applied, even though when I asked for a printout of the permeability it looked like it had been applied. I am curious if you get this same behavior.

In addition, Cheng-Kuo. I am sure you have done the right thing but I think it is good to clarity here just in case: for each case you run, please first remove MESHA and MESHB. Otherwise TOUGH3 will take the permeability you stored in those files from before and may not take the new information from your ELEM block.