water in the system

[max.tirone]

Hello everybody,
I had a brief email discussion with Paula (on 4th of July, thanks for the reply!) about a little problem that I am facing with water in the system, I think it may be helpful to share my issue, in case some user had the same experience earlier and found a way to deal with it, or maybe future users will find this discussion helpful.

I started playing a bit with the program (version 1.4) and I stumbled into something that I don't quite understand.
I am including all the relevant files in the zip file max-test.zip (note that to attach the zip file I had to rename it as  max-test.txt, it is not a text file).
Here is the issue, I am running a single computation at given P,T  bulk composition with a certain amount of water (0.02 wt% or 200 ppm) with the option
"ALPHAMELTS_DO_TRACE_H2O true" activated (see file alphamelts_default_env.txt), no buffer.

Now if I introduce the water as wt% in the bulk (file: magma-wt-H2O-A.melts), in the output file for the trace elements (Trace_main_tbl.wt-H2O-A.txt)
you can see that there is an extra amount of water (~19 ppm), the total is 219.164, instead of 200 ppm.
This extra amount is the water that the program put in the nominally anydrous minerals, olivine, cpx, opx, while hornblende takes all the water that I have introduced in the input file (200 ppm). Question: should the hornblende take the water in the input minus the water that goes in ol,cpx and opx?
Short note, the total mass of the system is preserved (100 gr), that is the same as defined in the input bulk composition.
Running the same test at slightly higher temperature so that some melt is formed, (input: magma-wt-H2O-B.melts, output: Trace_main_tbl.wt-H2O-B.txt),
you can see that the liquid takes all the water from the input file (200 ppm), because hornblende is gone, but there is some extra water in ol,opx,cpx, ~47 ppm
of water, basically the total water in the system is now 247 ppm.

I can try to put the water in the input file as ppm instead of wt with the instruction "Initial Trace: H2O 200" (input file: magma-ppm-H2O-A.melts) something different happen.
Note, the input bulk from the wt oxides is still 100 gr. In the output file (Trace_main_tbl.ppm-H2O-A.txt), the total amount of water is correct ~200 ppm, distributed in wet and dry minerals but the total mass of the system is not preserved, it is now 100.0174 gr. The extra mass (0.0174) comes from the water that is stored in the hornblende.
At high temperature, when melt is created (input: magma-ppm-H2O-B.melts, output: Trace_main_tbl.ppm-H2O-B.txt), the total amount of water is preserved
(~168 ppm in melt, ~32 ppm in the solid) but the total mass of the system (solid + melt) is more than 100 gr, precisely 100.0168.
The extra mass, I suspect, is the water that comes from melting the hornblende.

Summary of all of the above.
With input water defined as wt, the total mass of the system is preserved but the program creates some extra water.
With input water defined as ppm, the total water is preserved, but the total mass of the system is increased.

I see 3 possibilities:
1- I am doing something wrong or I am missing something in the setup,
2- this is the expected behavior of the program, no worries, everything is under control,
3- the result I am showing is the correct output of the program, but it should be something different.

I tend to believe we are in case 3-, but I hope I can get further confirmation. If this is the case, I can alleviate the problem when the input water is defined as wt by running the program few times (iterative solution).
First run with the desired amount of water as input (0.02 wt). Then read the output file and compute the amount of water in the nominally dry minerals.
Run the program again but with an adjusted value for the input water defined as, 0.02 minus H2O in ol,cpx,opx from the previous run. The output of the second run now gives the correct bulk mass preserved (100 gr) and the total output water in wet+dry minerals is equal to the amount of water that I initially defined for the system (0.02 wt).
The solution has to be iterated because before the first run is completed we don't know which minerals are in the equilibrium assemblage and how much water is taken by the nominally dry minerals.

Hope all this make sense...
max

[Paula]

Hi Max and everybody,

Max, apologies for some repetition. I tried running the calculations you did.

First off, note that there is a bug in run_alphamelts.command that means that the trace element output is not processed by the script is ALPHAMELTS_DO_TRACE_H2O is set but not ALPHAMELTS_DO_TRACE. I'll posted the fixed version on the GitList server. In the meantime a simple workaround is to make sure both ALPHAMELTS_DO_TRACE_H2O and ALPHAMELTS_DO_TRACE are set.

For water defined in ppm:

The program is behaving as expected (case 2). The total water is the ppm amount and is preserved. Some of this water is also counted towards the major element budget and affects system properties, including total mass. In Max's case the "major element" water is in hornblende or liquid. The iterative process by which water is moved in and out of the major element budget is described in some detail in Asimow et al. (2004), as well as in the alphaMELTS documentation.

The total mass that is printed in the trace element output files is the system mass i.e. excluding water in nominally anhydrous minerals (NAM). This mass is printed mainly to make it easier to use the column_pick.command script to combine regular alphaMELTS output and trace element output. The (true) total mass, including H2O in NAM, can be calculated from the information given but it would be more convenient if it were output automatically - so I'll add that next time round.

For water defined in grams: (Note: not actually wt %)

I was not able to reproduce what Max got but I was using version 1.6, rather than 1.4, and I don't know exactly what he typed at the menu within alphaMELTS. There are also there are a a couple of bugs (see below) that could probably generate system-dependent behaviour.

The first bug is if you do sub-solidus starting guess with "trace" water defined in grams and no fO₂ buffer. It turns out that the norm routine that is used for subsolidus guesses does not calculate the solid mass. If you do have an fO₂ buffer initially you may hit a different bug if a hydrous phases other than liquid or vapour is present at the starting conditions. I'm assuming there was no fO₂ buffer in this case and was able to work around the first bug by using the superliquidus starting guess instead.

At 750^oC the initial calculation failed for me but at 950^oC (the temperature of the water in ppm calculation) it was successful. The program behaved as expected with all water in grams being converted to ppm before the first pHMELTS calculation (case 2). Unprocessed trace output, for comparison with Max's, is below:

Title: 1-D 3-PHASE FLOW

Pressure 7272.73 Temperature 1223.15 H2O
Partition 99.997270 0.0207002
Bulk 99.997270 200
Liquid 0.000000 ---
Solid 99.997270 199.998
olivine_0 55.217550 15.5725
orthopyroxene_0 25.967694 34.9586
clinopyroxene_0 13.709816 69.9172
hornblende_0 0.810838 21295.7
feldspar_0 1.180619 4.83084
spinel_0 3.110753 0

Note that now there is slightly less than 100 grams mass as most, but not all, of the water was moved back into the major element budget (into hornblende). The deficit is the water that went into NAM.

Hope that makes sense. I am travelling at the moment so will not be able to post a public fix to the starting solution bugs for a little while but can provide a beta to anyone who needs it for Mac or Linux.

Cheers,
Paula

[max.tirone]

Hi Paula,
thanks again for looking at the water problem, very much appreciated.

Your run at 950C was enlightening. Now I see at least the location of the problem that bothered me. I get the same result as you did, total mass is conserved and total water is conserved, at this temperature everything looks perfect!

However at 750C, you mentioned a problem finding the equilibrium solution, same trouble here, in fact by fooling around with the program I found that by running the calculation twice, the first attempt failed to converge, but the second was a success.
Here is the catch, the output of the second run seems to have a problem even when it converges to a solution because it creates an extra amount of water (case with input water in wt).
The following is an example that can be tested and verified.

I have included in the attached zip file max-test2.zip (the zip file is renamed as max-test2.txt) the batchfile (batchfile.txt) that repeats exactly the same calculation you did at 950C but twice, using the input file magma-wt-H2O-A.melts also included in the zip file.
When you look at the trace file (Trace_main_tbl.wt-H2O-A.950.txt), the output of the first calculation exactly mirrors the result you posted in the forum (perfect),
but the second part of the output, which should be just the same thing, is not, and you can see the extra water, 249.316 ppm instead of 200 and a new phase (leucite ss).
This is the source of all my troubles. I am so glad we found it!

Out of curiosity, running the same thing 3 times, the third output looks the same as the second one (extra water still 249.316).
(By the way, activating ALPHAMELTS_DO_TRACE together with ALPHAMELTS_DO_TRACE_H2O does not seem to make a difference, output of the second run still with extra water 249.316 + leucite)

Final note, above the solidus, same input file (magma-wt-H2O-A.melts) but at 1050C, running twice with the same batchfile, the second output shows again more water, there is no extra phase at equilibrium, just a bit more melt.
Extracted data from trace_main_tbl.txt (output files not included):
First Liquid          0.477293 35242.7
Second Liquid      0.567405 35248.2

This is the story up to now, I haven't tested (yet) the new version of the program (1.6),

looking forward to hear from you about the fate of this evil bug...
max

[Paula]

Sorry for the delay in replying. I looked at Max's batchfile.txt and the problem is that he is reading in the melts_file a second time. It's really the same bug as the others I was describing - that things aren't, or rather weren't, happening in quite the correct order (for historical reasons). In addition there was a flag that was not getting reset when the melts_file file was read in. So when the file was in a second time alphaMELTS did not transfer the gram water into the ppm budget. You can see that in Max's examples because the Bulk H2O in Trace_main_tbl.txt is 0. The other values (such as the Solid H2O being 219 ppm in the original calculation) are artefacts.

Anyway the same fix works for all the problems. Now reading in the 750 ^oC .melts file and doing superliquidus start fails both times. However, reading in the 750 ^oC .melts file and doing subsolidus start works - so it doesn't matter. I am sending a copy of 1.6.1 to Max to try out and expect the public version to be available some time next week - together with a much updated beta version of alphaMELTS 2! If anyone needs a beta of 1.6.1 before then, please feel free to contact me.

Paula

[max.tirone]

Hello Paula,

YES, this works!
repeating the same calculation always gives the same result, perfect.
But it gets even better, because my initial problem was running a batchfille like this one here below at 750C

           1
magma.melts
           3
           0
           olivine
           spinel
           clinopyroxene
           x
           1
magma.melts
           3
           0
           olivine
           spinel
           clinopyroxene
           x
           0

as you can see it is just the same set of instructions repeated twice. The outcome was that the first run was a failure (rank deficiency....), the second run, for whatever reason, was successful but with extra water.
Now with your new version of the program (1.6.1), the first run is a success, the second run is a success and no extra water, a dream comes true.
I will do more extensive tests in the next few days with a program of mine which generates many compositions, and if there is extra water in the output, it sends a warning, but I am quite confident that with the new version (1.6.1) there will be no more warnings/troubles.

Great Job!
Thanks,
max