Mash pH prediction is different between calculators

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Thought I'd find the e-mail on the website but didn't so PM that to me.

And another thing I forgot to mention is that I often advise users of the popular spread sheets to use the trick of entering a lighter or darker color for the malt in order to fool the program into thinking that a malt is more or less acidic than the program's model thinks it is.

The fact that you advocate this tells me that you are using a color model for proton demand/surfeit.


PM sent AJ. I goofed around a little bit today and changed the color based "°L overrides" to actual DI pH inputs. I haven't fully incorporated it yet but initial messing around yields the same numbers as the color hacks so that's promising.

Reading through the documentation for your spreadsheet now.
 
OK, so it sounds as if you do have the paper or at least the slides from the Frederick meeting. I won't send the paper again then.


From what you've seen so far, did you have any other general comments?
 
My thoughts on general comments kind of got out of hand (as they often do) but here they are.
Adding (or subtracting) acid to a DI mash of a malt the amount required to establish a given pH is

mEq/kg = a*(pH - pHdi) + b*(pH - pHdi)^2 +...

where pHdi is the DI pH and a, b, c ... are coefficients which describe the buffering capacity:

d(mEq/kg)/dpH = a + 2*b*(pH - pHdi) + ...

A program which estimates mash pH clearly needs values of a, b and c for each malt in order to be able to determine the way in which exchange of protons shifts its pH. a, b, c and pHdi are obtained by taking measurements on the malts.

The relationship between malt, acid and pH is tied up in

mEq/kg = a*(pH - pHdi) + b*(pH - pHdi)^2 +...

and one way or another any program which wants to estimate mash pH must use that relationship. If the program does not have a, b, c, and pHdi it must obtain estimated values for them - all of them. Some maltsters specify the pH of a Congress mash in their product data sheets but by no means all. If we bought a whole bunch of malt samples and mashed them with DI water and measured the pH we might find some correlation between pHdi and, say, color or pHdi and malt type and of course this is what Kai did and so, based on his work, we can obtain an estimate of pHdi based on nothing more than the malt color. Is it a good estimate? No, but it is better than nothing at all and thousands of guys using it in popular spreadsheets have gotten adequate, if not spectacular, results.

So now on to a, b, and c. Where do we get numbers for those? One place to start might be Kolbach's observation that the pH of knockout wort shifts by 0.084 for each mEq/L change in residual alkalinity and apply that to mash. As a kg of malt is typically given 3 L of water in a mash that says that the mash buffering must be about -36 mEq/kg•pH. Many malts do in fact have buffering capacities near their DI mash pH's of about -36 mEq/kg•pH. But others do not. Could we do better if we made the DI mash and then added some acid to see how much the pH changed? Of course and Kai did that too getting data which, for each malt, gave the amount of pH shift per mEq added acid (or data at least from which they could be obtained). This was pioneering work (at least for home brewers) and so Kai should hardly be surprised that others building on what he did would find better ways to make the measurements. The major shortcomings of his method are that he did not recognize that b and c, while perhaps small for some malts and insignificant if we stay close to pHdi (which we do with base malts but not high colored malts) are not 0 and he did not allow for the fact that one must wait for 20 - 30 minutes before taking a pH measurement. Nevertheless his measurements are better than using the same 36 mEq/kg•pH for every malt.

Now that we have pHdi and a we have the model

mEq/kg = a*(pH - pHdi) = a*pH - a*pHdi

When we mix a bunch of malts some will add acid and some will absorb acid. It is clear that all the protons absorbed have to equal all the protons given up so that if the masses of the individual malts are m1, m2, m3...

a1*pH*m1 - a1*pHdi1*m1 + a2*pH*m2 - a2*pHdi2*m2 + a3*pH*m3 - a3*pHdi1*m3 = 0

This can clearly be solved for pH (as it is linear in pH) and so we have a way of prediciting mash pH from the a's and DI pH's of the malts in the case where there is no alkalinity to be dealt with. If alkalinity is present we can simply argue that in getting to mash pH we need an amount of acid that is nearly always pretty close to 90% of the alkalinity (in mEq/L) and solve

a1*pH*m1 - a1*pHdi1*m1 + a2*pH*m2 - a2*pHdi2*m2 + a3*pH*m3 - a3*pHdi1*m3 + 0.9*V*alk= 0

in which V is the volume of the water, for pH (there is one more term for phytin/calcium protons). This is what the current generation of spreadsheets have to do. The accuracy they are capable of achieving is limited by

1)The a's and and pHdi's are not those of the malts actually being mashed but rather estimates based on color (which isn't a very good basis for estimates) or similarity to measurements made on another malt which measurements were not as good as they could be
2)The malt model is linear and malts aren't. This results in error through a couple of mechanisms but for base malts these are small as pH and pHdi are close. In colored malts the errors are larger but it is tempting to think that as the the amounts of those malts are small in proportion to the base malts those larger errors might not be significant. We can't reason this problem away in this manner though because the volume of protons contributed by those dark malts is of comparable magnitude to the volume absorbed by the base malts. Better predictions are, thus, possible when dark malts are not used or when they are small contributors to proton supply.

3)The proton deficit is not fixed at 90% of the alkalinity. While an accurate model for water proton demand is not complicated it is a function of mash pH (dependence on mash pH is not linear), water supply pH, alkalinity and the end point pH used in determining the alkalinity. Consequently better predictions are possible if the mash liquor has no alkalinity.

The linear model is subject to the limitations discussed above. We can't really fix the linear model because the problem isn't linear. But it isn't a terrible model either. Thousands have used it for years. Can we improve it? Clearly if one puts a's and pHdi's into his spreadsheet that better models the actual malts he is using he should get better results than if he uses one's that don't match well. This is why if you know that your program always under estimates pH (too much acid) when you use a particular malt you can tweak it to give a higher pH answer either by increasing pHdi or decreasing a for that malt.
pH = (mEq/kg)/a + pHdi

By getting a closer match to Crisp Maris Otter using this approach you may be worsening the match for Muntons MO etc.

To get better answers you will have to go to the full up (non linear) model. The implications of this are

1)You will have to use iterative solution techniques to get pH estimates. This is actually easy enough to do in Excel using the Solver but that terrifies people for some reason. Palmer, for example, refused to even mention it in his book.
2)You have to get values not only for pHdi and a but for b and c as well and this really puts you back into the same boat of having to find someone who is going to do measurements. If you are a large operation that buys malts by the rail car or if we could ever convince the maltsters to include some data about there malts at other pH values this is worth considering. Otherwise, probably not.
 
I'm going to take some time to read through and digest this. I have some questions and made what I think are small but important changes last night but I'll reserve those for a full response.

Thanks for the reply. I'll be looking at it throughout the day.
 
Maybe I can summarize:

A)You will never get the level of accuracy you (we) want unless the malt data is accurate and that means including variations between lots, manufacturers, culivars, crops...

B)Even if you satisfy A you will not be able to get the accuracy you want with the linear model

C)As A) is the biggest problem it is probably not worth going to the non linear model until a solution (cooperative maltsters or cooperative lab rats) is found for A).
 
Sorry to hack up that informative post but i'll just give some background to how we have been doing things:



...and of course this is what Kai did and so, based on his work, we can obtain an estimate of pHdi based on nothing more than the malt color. Is it a good estimate? No, but it is better than nothing at all and thousands of guys using it in popular spreadsheets have gotten adequate, if not spectacular, results.



One thing we have been doing is the "color hack" (manipulating malt color up or down as you suggested, in our case our L (pH) cell or "malt override" as we typically refer to it) to approximate the DI pH of the malt from the lot/batch analysis. The one limitation with that is that it fluctuates as you change the grain weight so you have to readjust to be exact. Fortunately the beers being brewed with the sheet are pretty consistent, recipe wise, and gravity and grain bill weight are not changing drastically from batch to batch.



Last night I modified the code to accept an input for the DI pH of only the base malts being used in the recipe. This replaced the the default of 5.75 in the background calcs. Now instead of changing with grain weight it will stay constant. I disabled the color based inputs for base malts.



...he did not allow for the fact that one must wait for 20 - 30 minutes before taking a pH measurement.



pH readings are typically taken 10 minutes after dough in, then after the completion of each rest. So 20 minutes in (10 min. dough in plus 10 min), 35 minutes in (Beta rest) and 65 minutes in (Alpha rest).



The accuracy they are capable of achieving is limited by



1)The a's and and pHdi's are not those of the malts actually being mashed but rather estimates based on color (which isn't a very good basis for estimates) or similarity to measurements made on another malt which measurements were not as good as they could be



Absent of the iterative process you describe in detail elsewhere, does having the DI pH cell in the sheet increase the accuracy over the color based method for base malts?



2)The malt model is linear and malts aren't. This results in error through a couple of mechanisms but for base malts these are small as pH and pHdi are close. In colored malts the errors are larger but it is tempting to think that as the the amounts of those malts are small in proportion to the base malts those larger errors might not be significant. We can't reason this problem away in this manner though because the volume of protons contributed by those dark malts is of comparable magnitude to the volume absorbed by the base malts. Better predictions are, thus, possible when dark malts are not used or when they are small contributors to proton supply.

Most of the beers produced using our sheet have been pale lager beer. The only roasted malt used is in Schwarzbier, with percentages <= 4% with Carafa II. Dunkel gets Sinamar.

3)The proton deficit is not fixed at 90% of the alkalinity. While an accurate model for water proton demand is not complicated it is a function of mash pH (dependence on mash pH is not linear), water supply pH, alkalinity and the end point pH used in determining the alkalinity. Consequently better predictions are possible if the mash liquor has no alkalinity.

Distilled or RO water (with a modest 3 ppm HCO3) is being used to produce these beers.

Does all the stuff listed above stand to increase the accuracy of our estimates? Obviously from reading your post there is much room for improvement by using buffering capacities, etc. I'll be doing some research here as I revise the sheet.
 
How does the 'Z Alkalinity' ('Z pH', 'Z Acidity', etc...) concept that was introduced to the mainstream in the recently released book titled 'Water, a Comprehensive Guide for Brewers' come to play in any of this? Is that the mentioned more precise "non-linear" solution to the problem of achieving high precision?
 
In the opening aria of Die Entführung aus dem Serail*, Belmonte, whose beloved has been kidnapped by the Pasha Selim (some things never change) begs heaven to

"Schenk' mir dafür nun Freuden
Und bringe mich ans Ziel."

or in English, to give him joy and bring him to his goal (Ziel), which is, of course to see and ultimately rescue Konstanze (which he ultimately does). That's what the 'Z' stands for. John wanted a special name for the target (goal) pH and we went round and round in e-mails until finally during a phone call I thought of Belmonte and 'Ziel' popped into my head. John, as you can see from the way he uses it in the book really liked this.

If you look in the book you will find the malt titration data I discussed in an earlier post and a discussion of the a, b, c model. So there is a definite relationship between what we are talking about here and the book. The model was cooked up for the book. Unfortunately, because of publishing deadlines it wasn't quite fully baked as of the time the publisher said STOP. Therefore it isn't really that well explained there IMO. That's why I did the MBAA paper which is really what you should look at for a clear explanation.

I think I may have used pHz a couple of times but find 'target pH' clear enough

*If you saw Amadeus Entführung was the first opera he did for Joseph.
 
RPI - got your e-mail
Silver - PM me yours

I'll send you each a copy of the paper.

It's, of course, the same stuff and the slides were done later than the paper and so have a bit more up to date perspective but you should look at both.
 
RPI - got your e-mail
Silver - PM me yours

I'll send you each a copy of the paper.

It's, of course, the same stuff and the slides were done later than the paper and so have a bit more up to date perspective but you should look at both.


I'm writing the spreadsheet revision using DI pH for base Malts and the color method for specialty Malts. I'm hoping to then add some more depth after reading the paper.View attachment ImageUploadedByHome Brew1484277483.505019.jpg
 
Scotty, will you be making the spreadsheet revision based upon DI mash pH's available to the public? If so, I would like to stand first in line for a trial copy.
 
Scotty, will you be making the spreadsheet revision based upon DI mash pH's available to the public? If so, I would like to stand first in line for a trial copy.


I'm working on it now. It's fully populated but needs the calcs reviewed, error logic installed and proofing.

I took the water portion of the main brewing spreadsheet out and made it a standalone. I'll post it on our website as well as link it to the AHA and here when I'm done.
 
I've pointed out earlier that uncertainites in DI pH and buffering both contribute to error in mash pH predicition. Assuming that buffering is constant (linear model) near the DI mash pH we compute the amount of acid needed (as supplied by the brewer or other malts) to reach a target pHz is m = a*(pHz - pHdi) where m is the mEq/kg, pHz is the target pH and pHdi the DI mash pH. Write this m - a*D to make it simpler D = (pHz -pHdi). Let pHdi is the true DI mash pH but assume that the value we have is in error because, for example, it is derived from a color correlation or other similar data and that we use the value pHi + d where d is the error. Adding error d to pHdi changes D by -d so we would have D - d instead of D in the formula. Also assume that a is in error by some fraction f. Then we would use a*(1 + f) instead of just a to calculate m as m = a*(1 + f)*(D - d). Multiplying this out we have for the estimate of the required acid

m = a*D -a*d +a*f*D - a*f*d

Since a*D is the right answer we have an error of

e = -a*d +a*f*D - a*f*d

So what does this mean? To tell we need to put in some typical numbers. Buffering for base malts seems to run between about 30 and 50 so lets use 40 for a and assume that we can have errors of ±10 mEq/kg relative to that so that f = ±10/40 = ±0.25 . Assume further that a typical DI mash pH would be 5.7 and that we want to get to 5.4 so D = 0.3 and assume further that our color model gives an error of d = ±0.1 pH.

e = -a*d +a*f*D - a*f*d = 40*(±0.1 ±.25*0.3 ±0.25*0.1)

The ± signs may be confusing to those not familiar with this kind of analysis. They are there because we don't know what the errors are. A program that uses a fixed value of a = 40 for color will use 40 whether the actual malt has a = 30 (f = -10/40) or a = 50 (a = + 10/40). In cases like these we use the square root of the sum of the squares and refer to the rms error. In this example erms = sqrt (.01 + .005625 + .000625) = 0.127. Note that this is pretty close to the square root of 0.01. In other words the first term, a*d dominates. Given that d is the error in DI mash pH is the major contributor to error in calculating malt proton deficits or surfeits. Given that the buffering of the whole mash is also in the 30 - 50 range we can divide a*d by a to get a guess as to what the mash pH estimation error might be. This is simply d. Thus we conclude that an error in knowledge of DI mash pH of d will result in a mash pH estimate of about the same size and the obvious conclusion to be drawn from that is that if one knows the actual DI mash pH for a malt he will do much better using that actual data rather than an estimate based on some proxy. So using real mash pH data, if you have it, is a very good idea.

Now we do need to note that the first term in the error expression does dominate but not completely so. Twenty percent of the rms error comes from the other two terms.
 
I've pointed out earlier that uncertainites in DI pH and buffering both contribute to error in mash pH predicition. Assuming that buffering is constant (linear model) near the DI mash pH we compute the amount of acid needed (as supplied by the brewer or other malts) to reach a target pHz is m = a*(pHz - pHdi) where m is the mEq/kg, pHz is the target pH and pHdi the DI mash pH. Write this m - a*D to make it simpler D = (pHz -pHdi). Let pHdi is the true DI mash pH but assume that the value we have is in error because, for example, it is derived from a color correlation or other similar data and that we use the value pHi + d where d is the error. Adding error d to pHz changes D by -d so we would have D - d instead of D in the formula. Also assume that a is in error by some fraction f. Then we would use a*(1 + f) instead of just a to calculate m as m = a*(1 + f)*(D - d). Multiplying this out we have for the estimate of the required acid

m = a*D -a*d +a*f*D - a*f*d

Since a*D is the right answer we have an error of

e = -a*d +a*f*D - a*f*d

So what does this mean? To tell we need to put in some typical numbers. Buffering for base malts seems to run between about 30 and 50 so lets use 40 for a and assume that we can have errors of ±10 mEq/kg relative to that so that f = ±10/40 = ±0.25 . Assume further that a typical DI mash pH would be 5.7 and that we want to get to 5.4 so D = 0.3 and assume further that our color model gives an error of d = ±0.1 pH.

e = -a*d +a*f*D - a*f*d = 40*(±0.1 ±.25*0.3 ±0.25*0.1)

The ± signs may be confusing to those not familiar with this kind of analysis. They are there because we don't know what the errors are. A program that uses a fixed value of a = 40 for color will use 40 whether the actual malt has a = 30 (f = -10/40) or a = 50 (a = + 10/40). In cases like these we use the square root of the sum of the squares and refer to the rms error. In this example erms = sqrt (.01 + .005625 + .000625) = 0.127. Note that this is pretty close to the square root of 0.01. In other words the first term, a*d dominates. Given that d is the error in DI mash pH is the major contributor to error in calculating malt proton deficits or surfeits. Given that the buffering of the whole mash is also in the 30 - 50 range we can divide a*d by a to get a guess as to what the mash pH estimation error might be. This is simply d. Thus we conclude that an error in knowledge of DI mash pH of d will result in a mash pH estimate of about the same size and the obvious conclusion to be drawn from that is that if one knows the actual DI mash pH for a malt he will do much better using that actual data rather than an estimate based on some proxy. So using real mash pH data, if you have it, is a very good idea.

Now we do need to note that the first term in the error expression does dominate but not completely so. Twenty percent of the rms error comes from the other two terms.


Thank you for the insight AJ. Great stuff.
 
I've been playing around with various programs which try to predict your mash pH, and so far it seems as if the sources give varying pH feedback as follows:

1) Bru'n Water generally gives the lowest predicted pH's
2) Kaiser is close, but generally a tad higher pH predictions
3) Brewer's Friend generally comes in a tad higher than these two in pH
4) EZ Water Calculator almost always comes in noticeably higher then all of the above

I didn't see it mentioned anywhere in the thread, but when you measure, are you always comparing that the temperature that the tool says the pH is for? For example, EZ Water Calc estimates at ROOM temp. If you take the reading at MASH temp you'll automatically be about 0.2 lower than what they estimate.

pH changes with temperature. Don't confuse the inclusion of automatic temperature compensation in the pH meter to mean that the target range will always be the same regardless of temperature, as that's incorrect. The pH target range will always depend on the temperature of the sample.

So whenever a pH value is given, it always has to also include a temperature for it to be of any value. When people say "your mash should be between 5.2-5.4 pH" they mean at mash temp (approx 145-165). If the sample's at room temp then the range is actually 5.4-5.6.

Without temperature information, comparing pH values with other brewers becomes a futile exercise. Brewers tend to measure at both but often do not provide temp information.

Kal
 
I should have the new standalone calculator out this week, along with a users manual and corresponding blog post at ********************.

I'm just working out some kinks and checking the calculations for accuracy.
 
I should have the new standalone calculator out this week, along with a users manual and corresponding blog post at ********************.

I'm just working out some kinks and checking the calculations for accuracy.

This is getting exciting!
 
Maybe I can summarize:

A)You will never get the level of accuracy you (we) want unless the malt data is accurate and that means including variations between lots, manufacturers, culivars, crops...

B)Even if you satisfy A you will not be able to get the accuracy you want with the linear model

C)As A) is the biggest problem it is probably not worth going to the non linear model until a solution (cooperative maltsters or cooperative lab rats) is found for A).


AJ,

I'll be trying to incorporate some of the linear model aspects into the spreadsheet now that form and function is getting close. I'm just going to do some background calc work tomorrow trying to see the numbers I get.

You are heavily referenced in the sheet.
 
@ajdelange, could you also send me a copy of the paper?

Thks,

Fabiano da Mata

RPI - got your e-mail
Silver - PM me yours

I'll send you each a copy of the paper.

It's, of course, the same stuff and the slides were done later than the paper and so have a bit more up to date perspective but you should look at both.
 
@ajdelange, Send me too. :)

I had assumed that you were familliar with the MBAA TQ paper I referenced in an earlier post. I'll send you a copy. An electrical engineer (with only Chem 101 and 102 in his past) ginned this up so you should have no trouble with it.
 
Nice layout, but using LibreOffice under Linux I don't get any drop downs functionality. The spreadsheet you released about a week and a half ago has drop downs that work fine for me.
 
Nice layout, but using LibreOffice under Linux I don't get any drop downs functionality. The spreadsheet you released about a week and a half ago has drop downs that work fine for me.


I think I know what's going on there. I'll fix it tomorrow. Older versions of excel and open source office applications can't do data validation linked to other sheets.

So no dropdowns of water profiles or grains?
 


I've had some good feedback and comments at the AHA forum and some good catches from those guys on content. I'll be revising tomorrow so if you can hold off, I'll fix that stuff and post a new revision in the morning.
 
@RPIScotty, 2 suggestions:

1) create a place where you could upload versions, instead post every time you have new version.

2) Some users are more confortable with international unit system. Verify possibility to create a way of user select unit system.

Thanks,

Fabiano da Mata

I've had some good feedback and comments at the AHA forum and some good catches from those guys on content. I'll be revising tomorrow so if you can hold off, I'll fix that stuff and post a new revision in the morning.
 
@RPIScotty, 2 suggestions:

1) create a place where you could upload versions, instead post every time you have new version.

2) Some users are more confortable with international unit system. Verify possibility to create a way of user select unit system.

Thanks,

Fabiano da Mata


The link goes to our website. That won't change from version to version.

I'll take a look at a gallons/liters dropdown
 
Nice layout, but using LibreOffice under Linux I don't get any drop downs functionality. The spreadsheet you released about a week and a half ago has drop downs that work fine for me.

I updated the sheet and this issue should be fixed.
 
The drop downs are there now, but for the most part they are not pulling in their respective and requisite data.
 
The drop downs are there now, but for the most part they are not pulling in their respective and requisite data.


The grain data or the water data?

This was written specifically for Excel so it may be an open source software issue.
 
Pilsner pulled in data (for L, but not DI pH), but other malts I tried will not. Water data is not being pulled in either.

Oddly enough, your earlier edition (house edition) worked.
 
I definitely prefer Brew N Water. I have nothing of substance to go off of why except that Martin (who made Brew n Water) lives here in town and he certainly understands the liquid limestone that we pour from our taps.
 
Dilution water (as for RO) is populating properly, but the user selected water profile in the cell above it is not populating.
 
Dilution water (as for RO) is populating properly, but the user selected water profile in the cell above it is not populating.


New sheet was uploaded. You have to manually enter your custom profile in the water profiles tab under Source Water Profiles.
 
Back
Top