No convergence during CO2 injection into heterogeneous mineralogy
Hello,
I am very stuck on a reactive transport modeling project, and was wondering if someone would be willing and able to help me. I have initialized a homogenous (100% quartz) 2-D aquifer system with background flow and chemistry conditions, and then performed a CO2 injection into it using TOUGHREACT v3.3.2 coupled with the ECO2N equation of state ("treactv332omp_eco2n_pc.exe") and the tk1-ympR5 thermodynamic database. The results from that simulation look somewhat reasonable, as is shown by the pH-vs-t contour plot video attached.
The problem is that as soon as I try to look at the effects of different mineralogy during CO2 injection, TOUGHREACT stops being able to compute a solution (it quickly drives the timestep down to 0.01 s, and will obviously never make it to my target end time of 100 yr). This is what I did that led to this result: in a copy of the simulation that created the attached video, I simply changed the mineral content to be 10% hematite (the other 90% is still quartz) in a single grid block at (x, z) = (0.5, 0.33) km. I again initialized the system (by running a long-term simulation with no sources or sinks) with this new mineralogy and then used the "restart" capability to start the injection into this initialized system. The initialization again worked fine, but the injection period is when the problem occurs.
I have attached the input and output files from the failed injection simulation. Could someone please help me to figure out what I'm doing wrong?
Thank you very much in advance,
Mike
7 replies
-
Hey Mike,
I only see the video attachment. Would you mind including the zip folder too?
Thanks!
- Mikey -
Mikey,
Sorry about that. I didn't realize that .zip folders were not accepted until after the post had been made, and was then editing the post as you responded. I have attached the input and output files to the edited version of the original post.
Mike
-
Got it. I'm wrapping up a few work things over the next couple of days, but I should be able to get to this after that.
-
Mikey (and/or anyone else who may be able to help),
I was able to get the simulation to run, but something is still not working. I incorporated a layer of 100% hematite all the way across the domain at z = -330 m so that I can investigate the effects of the injected CO2 on release of iron from this mineral and its transport through the aquifer. This simulation also runs, but the hematite is seemingly not being recognized by the code. The output files show no difference in hematite volume fractions anywhere near the elevation where I tried to incorporate it, despite the fact that the rest of the domain is 100% quartz.
Another puzzling thing is that the injection causes large changes in the mineralogy right around the injection port, but these happen very slowly. As is shown in the two attached images, the plume of lower pH is very large at t = 100 yr, but the mineralogical changes around the wellbore are very localized (the elevated hematite volume fractions constitute only a tiny triangle at the bottom of the domain at x = 0.5 km). Shouldn't the mineralogical changes evolve along with the migration of the CO2 (and hence the lowered pH)?
Due to the large size and number of input and output files for this latest simulation, I've uploaded them to the USGS ftp site, and you can download them as the zip folder entitled "UT24rct_sim03_baseCO2_1hematiteLayer" from here: ftp://ftpext.usgs.gov/pub/er/va/reston/mplampin/.
Could someone please help me to figure out how to get TOUGHREACT to recognize the mineralogy that I'm trying to incorporate, and to get hematite to react with the CO2-rich fluid I'm injecting?
Thank you very much in advance for your help,
Mike
-
Mike,
I've started looking at this now. Am I right to assume you ran the simulation from the init03 folder first, and used the SAVE and savechem files as INCON and inchem for the simulation run with the files from the baseCO2 folder? If so, there's one small issue I noticed, but it likely doesn't solve your bigger problem.
It looks like you added the following line at the top of your chemical zones in your solute.inp from the simulation stage (post-initiation):
A2S94 0 0 1 1 1 1 0 0 0 0 0
Unfortunately, this line will be ignored, as information from the inchem file supersedes changes made in solute.inp. I made a similar mistake with a simulation I was running. Eric Sonnenthal told me he's trying to work on adding this capability, so you don't have to go through the painstaking process of making hand edits to the not-so-readable inchem file.
However, it looks like you included the correct mineralogy assignments on the nodes at -330m in the initialization simulation, so I don't think it'll answer the missing hematite mystery. I'll keep looking at that.
Thanks!
-
Mike,
I also noticed that the naming convention for the chemicals and minerals that you used in the chemical.inp files does not match that from the thermodynamic database. For example, the database lists 'Fe++' instead of 'fe+2' as you use in your input file. The simulation obviously runs, so perhaps there are measures taken in the source code to convert between conventions, but it may be worth a try to convert everything to match and see if any of your issues get resolved.
Thanks!
-
Mikey,
Thank you for looking at this. I have actually been in very frequent contact with Eric directly about this model, and he has helped me tremendously in getting it going. My issue with the hematite was actually on the post-processing side of things; I was plotting changes in volume fractions, as opposed to absolute magnitudes. I changed minflag from 0 to 2 in solute.inp, and this solved my problem.
I am now having a different issue, though. Gas phase evolution doesn't appear to be occurring as expected in a new version of my model in which I inject CO2 at a very high rate. Do you (or anyone else) have any idea why gas may not be forming? I've uploaded the newest version of the simulation to the ftp site (ftp://ftpext.usgs.gov/pub/er/va/reston/mplampin/) and deleted the old folders.
Thanks again,
Mike
