• Welcome to the new forum! We upgraded our forum software with a host of new boards, capabilities and features. It is also more secure.
    Jump in and join the conversation! You can learn more about the upgrade and new features here.

Cooling shrinkage volume and OG issue


Dec 17, 2018
Reaction score
First post here on this forum.

I've been using BS2 for some times now, but just recently for a new 5hL brewery. I've managed to set up my equipment profile to get quite reliable predictions overall, except for my OG.

Take for example my last batch stats:
Est. preboil G: 15.07 P
Meas. preboil G: 15.10 P
Est. OG: 16.96 P (which I thought was too high according to previous batches and a rough estimate based on my boil-off rate)
Meas. OG: 16.35
All my volumes (pre- and post-boil, evaporation rate, trub and chiller losses, batch size) where spot on.

I suspected a boil-off calculation error so I went on to play with the Boil off tool. With the shrinkage rate set at 4%, I get the same estimated OG (16.99 P), but the post-boil volume includes this "loss," contrary to the Equipment profile's calculated Post boil volume. If I set the cooling shrinkage to 0, I get the exact measured OG I got on this batch (16.35 P) and the tool's post boil volume matches the equipment profile's one.

So, it is obvious that BS2 counts the cooling shrinkage as a water loss the same way as evaporation, but it's not. Shrinkage is just that: shrinkage. It has no effect on gravity (when temperature corrections are accurately made).

Has anyone had this problem and what are the possible solutions?

Any help will be appreciated.

PS. Using version 2.3.12


In fact, i did find a way around but it's at the expanse of my setting's accuracy. First, my equipment profile was already set up as described in this post: http://www.beersmith.com/forum/index.php/topic,8579.0.html

Now, if I go to my recipe's equipment profile, set the cooling shrinkage (4% or 22 L in my case), to 0 and add this 22 L to trub and chiller losses instead, I end up with the same post-boil and batch volumes, which are correct. But, the est. OG is still off at 16.96, and the est. pre-boil G is now off at 15.66.

To make these estimates match my readings, I have to change my BH efficiency according to the BH measured efficiency. In other words, at this point, I don't mind the est. and measured Mash efficiencies as described in the above mentioned post; anyway they don't change and are still equal with this adjustment.

On screen, it works. I will test it tomorrow. But as I said, it's a way around, certainly not how it should be.
This is an estimation in the software, confirmed by Brad in an email to me.  When the calculations are made, it uses the thermally expanded volume post mash/pre-boil and the gravity reading (at standard conditions) for the gravity points calculation.  It calculates the gravity points at the fermenter and loss to trub and chiller, both volumes which are measured at room or standard temperatures.  You can follow the volume calculations on the 'vols' tab in any recipe.  This leads to an inaccurate total of gravity points, in which the error is equal to the thermal expansion coefficient.  Since the program does not ask for nor record the actual post boil volume, relying instead on the calculated value, it is up to the user to make note and perform the boil off rate calculation outside of the software.  Personally, I feel that this is an easy measurement and calculation that would enhance the ability of the user to 'dial in' the equipment profile to match the system. 

As you have discovered there are several ways around this issue.  Since my volume measurement is taken right after the mash with the wort temperature well below boiling, I set my thermal expansion to 2% (for water at around 150F) so that my measurement of volume at this point and the software will coincide.  Using this figure and the post boil volume, I can offset the thermal expansion to some extent by hiding it in the boil off rate.  For my standard process, yielding around 11 liters (Room temperature) at the end of boil and with a measurement accuracy of around 0.2 liters, the measurement error is pretty close to the expansion rate of 2%, so that is about as accurate as I can get to begin with. 

Brad's comment to me was that the standard measurement error for most brewers would be close to that of the thermal expansion which for my case is pretty accurate.  It does not mean that that error in calculation does not exist, but more that the user needs to be aware of this shortcut when doing the calculations for the equipment profile parameters and 'bake in' the error in the profile to balance out the calculations.  This will also reflect in an inflated mash efficiency number being calculated by the program, but, since program utilizes the total or brewhouse efficiency, it is only an internal value which does not affect the outcome.

If you follow your process pretty closely and from your notes it appears you do, you will still be able to accurately model your process in terms of volumes throughout and that the error would appear in gravity prediction pre-boil which would be pretty much match the measurement capability of most brewers using a standard hydrometer.  For your measurements in Plato to the hundredth place, it would certainly show up for the measurements taken using thermally expanded volumes.  In the end however, the final gravity would work out to target. 
I agree 100% with what you're saying. I've found that at commercial volumes, the density of water has a big impact on apparent volume. I've brought up that the BeerSmith shrinkage function changes (dilutes) the expected gravity quite a while ago, but Brad publicly refuted it saying it doesn't. I believe he doesn't have a direct link, but somewhere in the vast number of calculations, it gets linked.

I used to have 3.25% as my density value (the difference between 90oC and 20oC), which made the post-boil numbers line up. The preboil gravity estimate is always off by just enough to be annoying, but I can live with it.

What I've found to be the most important thing to do is to make sure I measure at the same point in the process. I measure volume and preboil gravity at 5 minutes into the boil, to make sure it's fully mixed. I measure batch volume and gravity AFTER WP and stand, to account for all evaporation up to that point. The WP & stand can be another 10+ gallons.
Oginme, thanks for your reply.

I see from it that, although with no great consequences, this is a real issue. We both have found ways around it but, again, it still is the wrong way to calculate things and make predictions. Volumes are correct, it's what is made of one of them (shrinkage) that is wrong.

The way I see it, it's pretty simple: BS takes my estimated pre-boil G, takes out water as evaporation (OK) and cooling shrinkage (wrong), calculate an estimated OG (wrong because of accounted shrinkage "loss"), and then remove the trub and chiller losses to calculate the batch volume. What it should do is take the estimated pre-boil G, take out evaporation water, calculate OG, and calculate batch volume from cooling shrinkage and trub and chiller losses.

As you said, it's quite easy when you know your system and you keep notes on your brewing sessions to repeatably get the results you want. I myself got to make BS make predictions reliable enough for my system for most data, which I think is great considering it's a homebrew software. Reliable, except for this last one data. As you did, I found a way around, but something is wrong along the way.

I'm aware that a lot of probrewer work with BS, at least for some time at the beginning of their career. The small measurement error equivalent to this programming error can mean a lot on our scale, not only moneywise. Just think about packaging for example: on a homebrew scale, I didn't mind small errors in my OG which translated to small error in my ABV; but now I would certainly mind about mislabelling my ABV.

I will post a link to this thread in the Suggestions forum.

Anyway, thanks again for your reply. I've been reading a lot on this forum and you are are always of great help.
Brewfun, I was typing while you replied.

I'm "glad" to see I'm not the only one with this issue.


I agree that it is a real issue, which is so easily fixed as all the numbers needed are there to fix the calculation.  On large scale brewing, it can be a problem when you are relying on the in-process calculations to verify that you are hitting your targets. 

I've spent many years doing process engineering and process control engineering in the paper industry.  We typically broke down key measurements and variables by category: critical, major, minor, informational and applied time to each measurement and prediction to ensure that the critical and major data fields were rock solid and tuned for tight control bands.  Minor data fields were predicted and controlled as long as they did not clash with the critical control loops and cause instabilities in the process.  From my perspective, the pre-boil volume and gravity points are minor data to the home brewer, but are elevated to major for larger scale brewing where key decisions are made based upon those results to ensure consistency in the end product.
FYI, I've seen this same issue... though I looked at it backwards from what you did.  My main concern was never hitting preboil OG.  If i did, then my postboil OG was off by a few points.  The problem is the preboil SG is calculated at thermally "expanded" volume of the mash temp around 150degF (103%).  We don't measure SG at 150degF, we cool the sample when we measure.  So this number is artificially low due to the extra volume of wort.  If you set shrinkage to 0% you'll get a valid preboil SG, since the gravity should be measured at room temp.  You can multiply the preboil SG times volume and divide by final volume and get the OG to match up. 

I think the real issue is how BS is calculating preboil SG... my solutions have involved either setting shrinkage to 0% and accounting for 4% loss volume on final volume or back-calculating the preboil SG by reworking the volume/sg formula (Either multiply OG times post boil volume and divide by preboil room temp volume, or multiply preboil OG by .97 to get a rough estimate). 

A lot of people will simply go back after brewday and update their mash eff so that their preboil SG matches what BS predicted.  Then they're usually off by 2-3 gravity points on OG but chalk that up to user/math error.  The issue becomes more pronounced with larger batches (Imperial recipes).
I agree with MC1980 that the software is taking cooling shrinkage as water loss, but it's not. This is just a conceptual error in calculations.

For example, values estimated by beersmith 3.08:

0% shrinkage

Pre-boil gravity: 1.045
Pre-boil Volume: 29.5 L
Original gravity: 1.053
Post-boil Volume: 25 L
Total water (mash+sparge): 36.61 L

4% shrinkage

Pre-boil gravity: 1.043
Pre-boil Volume: 30.54 L
Original gravity: 1.053
Post-boil Volume: 26.04 L
Total water (mash+sparge): 37.65 L

As you can see, what the software is doing is just adding exactly the same volume of shrinkage "loss" to the total water needed. The shrinkage percent should not modify your total water, because there is no loss! In the end, this changes your pre-boil gravity (more diluted mash). 

Oginme has tried to explain in other posts that the program uses expanded volume for mash and sparge water, which can explain the response of the water needed with shrinkage percent. However, I think this supposition is counterintuitive because most brewers measure their water volumes at room temperature. Additionally in beersmith official sources are clearly stated that cooling shrinkage was thought only for post-boil volume e.g:


"The wort volume shrinks by a small amount (around 4 %) as it cools from boiling to room temperature. This is the calculated amount of loss"

We all agree that there is an issue. However, we have different opinions respecting the origin of the wrong calculations. I see this problem in a more straightforward way than Oginme. Taking all this evidence, I think that the source of the problem is misunderstanding cooling shrinkage as water loss and compensating it by adding mash or sparge water.

Anyway, this is an old discussion, and Brad has never clarified it. 
If you look at the 'vols' tab of a recipe you can follow the water volumes from the fermenter (user specified batch size) back to the initial strike water.  The program uses the batch size (cold), removes the trub loss (cold) and then applies the Thermal expansion (cooling shrinkage) to get a post boil vol (hot).  Everything from that point up to the strike water is a hot measured volume, as the thermal expansion is never removed all the way back to the total mash water (hot).  The math for the volume calculations and the thermal expansion is right there.

The issue in the software is really the calculation of the target gravity of the pre-boil wort.  If you take your example, at 4% thermal expansion the program ends up with 26.04 liters at 1.053 gravity.  Remove the shrinkage and this becomes 26.04 - 4% * 26.04 = 26.04 - 1.04 = 25.00 liters (cold).  The gravity points at this point are 25 * 53 = 1325.  Now the program takes the pre-boil volume (hot) and divides the gravity points by that figure to give you your pre-boil gravity:  1325 / 30.54 = 43 or a gravity of 1.043.  In actuality your target gravity should be the cold volume pre-boil (29.5 liters) which would give you a target gravity of 1.045. 

This number, 1.045, is the actual target gravity you should be shooting for. 
Yes, I know that the math works for your premise, as well as mine. I am only saying that we don't know how the software was designed, without viewing the code. If you are correct and Brad designed the program to works with hot mash water, hot sparge water, and hot pre-boil wort, he should include a factor that modifies expansion at different temperatures. I am still thinking that work with hot volumes for mash and sparge water is a bit unintuitive. For me at least, it is easier to set the shrinkage at 0% and make the math with cold volumes for the whole process. I measure the post-boil volume cold, so I only have to correct the pre-boil volume manually. In this way, I don't have the problem with the wrong pre-boil gravity estimation.
Mine is more than a premise.  All the functions, calculations, and results can be determined from the software without a need to look at the code.  If you want further proof, look at the posts above.  Both brewfun and I have privately discussed this issue with Brad and we have both been given very similar answers.

So let's get to the evidence. 

First there is the vols tab, which clearly spells out the volumes from fermenter on back.  If you change the thermal expansion coefficient, the mash water changes in proportion to the value you enter.  Try putting in 10% and the program will add 10% as your shrinkage and carry that back.  Your own example of 0% vs 4% shrinkage factor demonstrates that calculation clearly.

Next, the thermal expansion is applied as a all-or-nothing parameter.  Change the thermal expansion to 2% and you will see the numbers from mash water to post boil all adjust to that value across the board.  Brad has stated to me that he feels the error in the thermal expansion at mash temperature is less than most brewers can measure accurately.  This is true on the home brew/small batch scale.  As brewfun pointed out, on a manufacturing scale it does become a significant factor.

So we can deduce from the math demonstration, the calculated values it displays, and the behavior of the software exactly what the calculations entail.  I have been through it many times doing the calculations by hand to understand the functioning of the software and how to best make it perform for me.  It is one of the better facets of BeerSmith is that (most) of the parameters needed to customize the software are available for the user to adjust.

While you (and I) measure our water volumes cold, not every brewer does so.  I know plenty of brewers using this software who add more than what they need for water in their HLT and heat that up.  Excess water is usually used for cleaning and flushing lines.  For them, the thermally expanded values are more important.  This is why Brad put in the user ability to adjust the thermal expansion coefficient, to allow brewers to adjust it to suit their process needs. 

If you look back at the 'suggestions' topic, you will find my wish list for the next update, which includes the scaling of water volumes to temperature and the correct calculation of pre-boil gravity based upon a calculated cold water volume.  We are not in disagreement here. 
First there is the vols tab, which clearly spells out the volumes from fermenter on back.  If you change the thermal expansion coefficient, the mash water changes in proportion to the value you enter.  Try putting in 10% and the program will add 10% as your shrinkage and carry that back.  Your own example of 0% vs 4% shrinkage factor demonstrates that calculation clearly.

This doesn't prove the origin of the problem or how the program was designed. What I'm trying to explain is that the program may be was designed to function with cold sparge and mash water volumes, and the wrong calculation arises from compensating the shrinkage "loss" as initial water volumes. This error is very common and even is taught in several homebrewing courses. Many people believe that the shrinkage is a loss and they have to compensate with more strike water.  All calculations you did, would also fit with my explanation. Cooling shrinkage function exactly in the same way that boil off volume in beersmith (as net water loss). If you increase any of these parameters you will obtain increments in the mash or sparge water, and reduction of pre-boil gravity without changes in mash efficiency.

Additionally, there is no explanation in any official source that the program works with expanded water volumes from the start.

Brad has clarified two times that the software does not account for expansion in mash nor strike water:


Additionally, in all tutorials, shrinkage is explained as a water loss, without mentioning anything about expanded strike water:


Altogether, we have no evidence that the program was designed to work with expanded mash and sparge volumes, you are just assuming it because it fit the numbers. All this stuff can be originated by considering the shrinkage as water loss (which also fits the numbers). However, in any case, the resulting wrong estimated parameters are the same.
I think you are misinterpreting a change in volume as a result of temperature as a loss of water.  There is no loss of water, it is a natural and demonstrable change in the specific gravity of water as a function of temperature.  I can open a recipe, set the shrinkage to 4% and get an infusion of 18.71 liters.  Then in the same recipe, I can go back to the equipment profile and set the shrinkage to 0% and end up with a infusion of 18.25 liters.  The net difference is 4%.  Likewise, in the 'vols' tab it gives me the same difference in numbers for total water needed:  18.71 for 4% shrinkage and 18.25 for 0% shrinkage.  Given this difference, one can only logically come to the conclusion that the strike volume and the total volume needed are based upon a hot, thermally expanded volume. 

You should work through the numbers yourself.  If you want to view the thermal expansion as a 'water loss' you are most welcome to do that.  Since I was doing calculations with pencil and paper long before I started using this software, I am well aware of the calculations which take place.  I have applied them to this program and other available programs to check out their functionality and am very comfortable in my understanding of how the program is attaining the numbers it produces.  If you have your doubts, then by all means keep plugging away. 
I know that change in volume as a result of temperature is not a water loss, but the program could be considering it as a loss. What I am discussing is only the origin of the problem. We have two options:

1) You said that Brad designed the program to work with hot mash and sparge volumes (we have no evidence of that). This could explain how these volumes respond with the shrinkage factor. In this case, the pre-boil gravity estimation is wrong because it is not calculated at cold temp.

2) I am saying that maybe Brad designed the program to work with cold volumes at mash, and he misunderstood the post-boil shrinkage as net water loss, compensating it by adding mash or sparge water. I am supposing that this could be the bug.

In both cases, the result is the same. I never said that I view the thermal expansion as a 'water loss". What I am explaining is that maybe the software was programmed to view post-boil shrinkage as a loss. It is not an unusual mistake if you search on the web.
Considering that the same Brad admitted that he did not include expansion in the mash volumes, I think the second option is the most probable.