TOUGH3; Running time is too long
Dears,
I am trying to run a simulation using 2D model for CO2 injection in stratified reservoir. I have 650 grid cells in the radial direction and 79 grid cells in the z-direction as illustrated below.
MESHMAKER1----*----2----*----3----*----4----*----5----*----6----*----7----*----8
RZ2D
RADII
1
0.
EQUID
1 .3
LOGAR
500 1.E3
LOGAR
100 1.E4
LOGAR
50 1.E5
LAYER----1----*----2----*----3----*----4----*----5----*----6----*----7----*----8
79
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5. 5.
5. 5. 5. 5. 5. 5. 5.
ENDFI----1----*----2----*----3----*----4----*----5----*----6----*----7----*----8
The increment factor is 1.05 as illustrated below.
***** FIND APPROPRIATE FACTOR FOR INCREASING RADIAL DISTANCES *****
AFTER 32 ITERATIONS FOUND INCREMENT FACTOR RAT =0.10536571E+01
However, I find very long running time (more than 24 hours). The maximum time step is 8 seconds !. I wonder why the simulation takes such a long time and how to decrease the running time.
11 replies
-
Dear Refaat,
I do not see anything obviously wrong with your input file. When I try to run TOUGH3/eco2n on a Windows 10 machine, using an Ubuntu window, I get entirely different behavior than you describe. The code runs fine for 148 steps, to ~1 day of simulation time, with time-step length gradually growing to ~1000 seconds, then suddenly a gas phase evolves and precipitation starts at every element. Many variables are NaN. The code takes 10 1-iteration converging steps and stops. There is no salt in the problem, so there should be nothing to precipitate. I have never seen such behavior!
Usually, I would recommend that you add one or more of the GENER elements to the FOFT block, so you can see what is happening near the well, and that you add some earlier times to the TIMES block to look at overall behavior. But in this case, I actually do not think there is anything physically wrong with the problem - I think it is a problem with the numerics. In TOUGH2, I would have suspected that an array dimension was too small, but that should not happen in TOUGH3, since memory is allocated dynamically.
I am currently running the problem on a different machine and I am trying it with ECO2N_V2. Another thing to try would be to use a different solver or different parameters in the SOLVR block. If anyone else wants to try the problem, and/or has seen this kind of behavior before, please chime in! Thanks, Christine
-
I think the reason the two of you have different outputs is probably due to the change i made in TOUGH3 code. I will look into it and let you know.
thanks
Yingqi
-
Refaat. Could you explain what you mean by "instability of the numerical results"?
I do not have specific suggestions for solver options. See the TOUGH3 manual for MOP(21) and the SOLVR block for some possibilities.
As far as using fewer grid blocks, you probably only need a fine grid where the CO2 will be. If you use your coarse-grid results to see how far the CO2 plume extends radially, then that will tell you how far out the grid should be reasonably fine (logar spacing with a factor of 1.05 should be good). Beyond that distance, grid spacing can double each column and still represent the pressure adequately. You should give the final column a huge volume (~1.E30 m3) to represent a constant pressure boundary.
-
BTW, although I have not been able to run the problem successfully due to the change in TOUGH3 (could have introduced a bug), I noticed you do not have a large volume at the boundary, which means you have a closed system. Is it what you wanted?
Yingqi
-
To fix the bug (actually it was not introduced by me) in file Utility.f90, search for subroutine TADJUST.
around line 330 right before:
! --- SORT VECTOR ADDTIMES
add: IF (MTIME.GT.1) THEN ! (the sorting and redundant remove is only needed for there is more than one time)
Right before IF(.NOT.ALLOCATED(TEMPTIS)) ALLOCATE(TEMPTIS(ITI)) (around line 360), add:
ENDIF
If you do not want to re-build TOUGH3, you can resolve the problem by removing TIMES block temparily.
Yingqi
-
Yingqi, I also noticed this problem (on Linux, but not on Windows) - the code wouldn't even start to run and gave me an error message about bad dimensions. Another work-around is to put two or more times in the TIMES block.
-
Dear Refaat,
When I run your problem on a Linux machine, I think I am getting results like yours - a small time step of about 10 s that does not grow. When this happens, it is important to look at the output file and see why the time step is small. You have MOP(5)=3 which is good - it enables you to see phase changes. When a CO2 injection problem is running well, you can watch the phase-change messages to see how your CO2 plume is growing through your mesh.
That happens for a while in this problem, then I get oscillating phase changes - the same element repeatedly goes from liquid phase to two phase and back again. When this happens more than a few times, the code is probably stuck. I usually kill the run and restart it, asking for a full output at the time when the code gets stuck. Then I check that all the pressures and gas saturations are reasonable. Typically the element where the code gets stuck is at the leading edge of the CO2 plume.
Sometimes, merely restarting the problem from the stuck point will allow the code to get unstuck and continue. If this does not work, I sometimes change P or Sg slightly in the SAVE file at the stuck element, before copying it to INCON for a restart. This sometimes helps get the code unstuck. If this does not work, it may help to modify the parameters of the relative permeability and capillary pressure slightly and rerun the problem from the beginning.
If none of these things help, I think you should try a coarser mesh. Hopefully there is some grid spacing in between your present stuck problem and your old oscillating P problem, where the code runs well. I looked more closely at your MeshMaker input and output, and the factor of 1.05 you get for grid coarsening is for the far outer radial region. It is much smaller (1.006) for the inner 1000 m. If you think 1000 m is the farthest out the CO2 plume will extend, then I think 1.02 to 1.05 would be a good grid coarsening factor for the first 1000 m. After that, you just need to calculate the pressure response correctly and a coarsening factor of 1.3 to 1.5 would probably be fine. You can try different parameters for MeshMaker input to get something like this. I tried 200 elements for 0 to 1e3 m , 15 elements for 1e3 to 1e4 m, and 5 elements for 1e4 to 1e5 m, which gave me coarsening factors of 1.02, 1.37, and 176, respectively. Then you should check in the MeshMaker output that the grid spacing around 1000 m is acceptable to you. For this case, it is about 10 m.
The oscillating phase change problem occurs for me from time to time in TOUGH simulations, and if any one else has strategies for overcoming it, I would like to hear about them. Christine
-
I have been changing WNR in PARAM.3 to something less than 1 (between 0.95 - 0.99). This induces over-relaxation and will sometimes prevent phase shifts between Newton Raphson iterations from occurring as frequently. There's another setting in MOMOP: MOP2(13). This will reduce the value of WNR by a percentage (equal to the number provided) automatically after an oscillating time step and then add it back after a successful time step with enough NR sub-steps. That option has been hit or miss for me.