tom_hampton said:
Knowitall-
You ARE correct, but you are bordering on rude. It is not necessary for you to use the language that you are (idiotic, "cult members", etc) in order to try and make your point. Disagreement, dissent, and difference of opinion is not grounds for your approach....even if the person is simply wrong. If you can't make your point without using language like the above...then simply don't post.
This issue has been brought up multiple times, with the same responses from the usual suspects. I was courteous enough in my initial post when I more thoroughly defined the issue, and yet received the same response- I don't know how to use the software, don't know my equipment, don't understand what efficiency means, am playing tricks on the software, etc.
It is obvious that the responders are either not thoroughly reading my posts (and others'), or are not understanding what the issue is.
Sadly, even though you say I am correct, it is apparent you also don't understand the issue at hand, and have not read the posts thoroughly that explain completely the issue with the trub/chiller losses field.
Again, BeerSmith completely, utterly, and undeniably, does not handle the trub/chiller losses field correctly. When only the 'trub/chiller losses' field is modified, BeerSmith increases the mash water volume. If the intended use case is to then immediately go and scale the batch size and ingredients by the same volume increase, there is no reason for the side effect of additional mash water being added to the recipe when only trub loss is added. By the way, the extra mash water that gets added by changing trub losses doesn't go away if you subsequently scale the batch the same amount as the trub losses, it is added to new scaled batch water.
If 'trub/chiller losses' are only going to be used for brewhouse eff calcs, it shouldn't impact the recipe amounts, it should only reduce the batch size, which is defined by 'as measured to the fermenter'. This is even in the pop up for the field.
Something to address is what BeerSmith is calling 'batch size', which it defines as 'to the fermenter', and whether it is using it that way in calculations, or is using kettle volume. Something does not jive. Regardless, BeerSmith should not add water to the mash volume when trub losses are increased, and not do anything else. And especially not fudge all the indicators like IBU, color, SG, kettle volume, etc to make it appear that everything is OK.
BeerSmith appears to pull off this trick by upping efficiencies, at least the mash efficiency definitely increases, sometimes above 100%. As much I would love to increase my mash efficiency, especially above 100%, by simply buying a $20 piece of software, this is not something BeerSmith can possibly do for my system, yet it insists on doing it when I add trub/chiller losses in the proper field.
tom_hampton said:
There are two mixed topics in this thread: Hops losses, and efficiency. They are best treated separately.
There are two topics in this thread only because of the responders who continually blame a lack of understanding about 'efficiency' for why the posters feel there is an error in BeerSmith. The original problem needs to be fixed, that BeerSmith increases mash water volume and kettle volume, but does not increase the ingredient amounts. Yet, miraculously, all of the indicators remain the same.
Efficiency calculations are completely irrelevant and off topic.
tom_hampton said:
Beersmith is pretty rudimentary in its usage of efficiency. It is important to understand two things:
[list type=decimal]
[*]Brewhouse efficiency is a user controlled input. It is treated as gospel.
[*]Mash efficiency is NOT USED by beersmith. It is simply a calculation that is based on brewhouse efficiency and system losses.
[/list]
I have seen, and can recreate, BeerSmith increasing Mash Efficiency when trub losses are increased. Whether this is BeerSmith 'using' the value, or not, I cannot say without seeing the code. However, it could be how it is able to maintain/display the same SG, color, IBUs, etc. even though additional water is added to the mash, the post boil volume increases, and yet no grain bill increases are made.
Even if it doesn't use mash eff for anything, that is not the point of this thread. Again, any talk of efficiencies is off topic. The mash efficiency anomaly has only been brought up since its value changes as a side effect of entering different trub losses.
The point of this thread is the main side effect caused by entering a trub loss which results in an increase in mash water volume with no other (real) compensatory changes. Even worse, BeerSmith fudges all of the top level indicators, IBU, color, SG, post boil volume, etc., to make it appear the recipe is correct.
There is no logical reason for this. The only use could be for someone wanting to find out what mash eff is required if they add a bunch of system losses, but not have to add any extra ingredients. This has little practical application, since most brewers have limited ability to increase mash efficiency.
tom_hampton said:
Efficiency
--------------
It would be more accurate to enter MASH efficiency + losses, and then calculate brewhouse efficiency. Mash efficiency + grain weight makes wort with a certain SG. Trub losses, etc. then degrade mash efficiency to brewhouse eff. This would allow you to adjust trub-loss for things like hop losses without having it cause weird things to happen to mash efficiency.
Trub losses have absolutely no impact on mash efficiency. Trub losses are used as one of the inputs to brewhouse efficiency. I don't even care about efficiencies, and they shouldn't even be part of this thread. The topic of this thread is that compensation for trub losses should either decrease the batch size (to the fermenter, as it is defined), or increase the kettle volume and add additional ingredients to maintain everything- volume to fermenter, color, SG, IBU, etc. BeerSmith does not do this correctly when trub losses are entered in the appropriate field.
tom_hampton said:
That said....its not that big of a deal in the real world...for average recipes. In reality if you define a real equipment profile, with real losses, and associated brewhouse efficiency beersmith will be close...not right, but close. Sure you can fake out beersmith and discover several degenerate cases. But, a single iteration through making a beer and adjusting the eff/loss numbers based on actual data will converge on reality. If you are going to talk about Laplace and Gauss...then I'm guessing you understand convergence and how to prove that an iterative feedback system converges.
How about if I first use BeerSmith with a good idea of my various parameters, and enter them the first time, with a 2 gallon trub/chiller/hop loss, should I not be able to input those and expect to have the trub losses calculated correctly by scaling the recipe, or at least have the batch size reduced? Or, at very least, not be lied to by having the SG, IBU, color, etc. remain the same, but the 'fine print' says that my mash efficiency and other calc values have been increased to maintain the correct SG, IBU, color, etc. due to the added water volume?
RE:Laplace et al- I just made up that ridiculous sentence to counter the nonsense about transitive vs. whatever he called the other mythical state of solids in the wort. They were both pure gibberish. I am aware how to apply their various techniques, although the hop absorption compensation problem is not difficult, and doesn't require any of those methods. At first glance it is just some basic calculus, but I haven't put any thought into it yet, so I don't have any approaches that are candidates.
tom_hampton said:
I'm not saying its not wrong....I'm just saying its not really as bad as you claim. In most real cases the effect is less than a 5% error. Even in those cases where it is larger than that, simply making the beer once, and correcting the recipe for reality will narrow the error to well less than 5%...and more than likely better than your own consistency from batch to batch.
The error is whatever the percentage of trub loss/ batch size is, because it is being calculated wrong.
This makes sharing recipes very difficult, because someone's compensation for the erroneous trub loss number could impact your brew when you scale it for less trub loss.
The trub/chiller loss field needs to either be removed; not cause any side effects like increasing mash volume; scale the recipe completely, not just increase the mash volume; or reduce the batch size (to the fermenter like the popup says). It is currently a booby trap.
tom_hampton said:
Hop Losses
-----------------
Again, you are essentially correct. The problem with what you say is that the magnitude of the effect is not as large as you make it out to be. Hops absorb roughly 4x their dry-weight in wort during the boil. So, 4 dry ounces of hops would absorb 16 ounces of wort...a pint. So, your typical IPA recipe loses an un-accounted for "pint". Very few people can accurately measure their kettle volumes to the QUART. So, a pint or so of additional loss is "noise". That's 1/2 liter out of 23L....~2%
The measurements I have heard and experienced for leaf hops are usually between 8-16 oz/ hop oz. For my 13.5 Gal batch, that would be between .5 - 1 gal of loss, just for the hops. I don't care about the loss, and would even accept more. What I don't want, is for BeerSmith to dilute my wort by ~20% when it tells me to add mash water equivalent to my trub loss, but doesn't increase the ingredients to maintain the SG.
tom_hampton said:
The above is adequate for beers with less than 100 IBUs. For "Pliny" type beers (200-300+ IBUs) it is not. These beers have the better part of 3/4 lbs of hops in 5 gallons of wort. This results in about 3 lbs of wort loss...maybe a little more depending on siphon/dip-tupe-screen configurations. That's roughly an extra half-gallon of wort. In these cases, the easiest way to compensate is to increase the batch size by ~1/2 gallon (or more to be safe). Or you can adjust the trub loss, its equivalent.
It is not equivalent, and this is what every poster coming to this thread after experiencing it has discovered, and what every naysayer that responds keeps trying to explain away with efficiency, or some other nonsense.
tom_hampton said:
Once you've done this you simply go back and adjust the Hops and Grains to compensate for the increased boil volume.
This is the crux of the issue. The recipe/batch size has to be scaled by the same amount as the trub loss. The issue is that if only trub loss is changed, BeerSmith immediately adds mash water, and then increases mash efficiency to maintain SG and other tricks to keep the IBU, color, etc the same. There is no indication that this has been done, or that anything else has to be done, other than mash efficiency magically changing. The added mash volumes are there as long as the trub loss is there. Scaling the recipe using the scaling tool just adds more to them.
It gets worse every time I try test cases. If I apply equipment to a recipe that has trub losses, the trub losses trigger the mash volume increase, then when the recipe is scaled, as you suggest doing, it adds the additional volume for the scaled recipe. This is no different than adding trub losses to the same recipe. BeerSmith is not handling trub losses correctly. It is very apparent.
If the only thing 'trub/chiller losses' is important for is for calculating brew house efficiency, increasing the value alone shouldn't cause an increase in the prescribed mash volume. If the user has to perform the additional step of scaling the batch up by the same amount has to be done anyway, the mash volume, grain bill, hops, etc., will be done correctly there anyway (although BeerSmith doesn't do this correctly if trub losses are non-zero). The worst thing it could do is simply increase the mash water, and also maintain the same SG, IBUs, color, etc., without adding ingredients.
tom_hampton said:
Sure, this increases the hops absorption, but only by 5-10% of the total absorption...or roughly 1 fl oz. For my Pliny recipe, I simply increase the batch size by a full gallon, and adjust grain/hops to suit. Then I brew the beer, adjust and repeat. I end up with a little extra wort (maybe a quart or 2).
Apparently there is no need to adjust the grain bill to account for losses, you just let BeerSmith magically increase your mash and other efficiencies (above 100% even) so that the extra mash water volume
it tells you to add doesn't change the SG, color, IBU, etc.
I assume you are scaling the batch volume, without using the trub/chiller loss field, to account for losses; and then doing the math outside of BeerSmith to get your volume to the fermenter, minus losses. That about the only way it works correctly, unless you want to manual adjust individual ingredients to compensate for the added water volume.
tom_hampton said:
It works. Could it be done better? Sure...as described above. But, ITS NOT THAT BIG OF A DEAL.
It doesn't work. Changing only the trub/chiller loss field simply causes additional water to be added to the mash. The worst part is that it hides the iimpact to the SG, color, ibu, etc. by increasing the mash efficiency and other things to compensate.
tom_hampton said:
If your this worried about this, then you should also consider that mash efficiency (and as a consequence Brewhouse eff.) are a function of target OG. I find that its about (3-5)% eff loss / 10 gravity points. This is a bigger effect than the one discussed above.
I am aware of the swings in SG due to mash efficiency. For that very reason, I don't want things further compounded by BeerSmith diluting my wort by the amount of trub/chiller loss I input.
I figured out how to work around the issue in 5 minutes, once I noticed what was happening. It is easy enough to leave trub/chiller losses at 0, and scale the batch size manually (using the scaling tool) to account for kettle losses.
The whole point of this sub-forum is for bugs, which is why I posted. This is most definitely a bug, regardless of the workarounds available. It is currently a pitfall waiting to catch unwitting users unawares. The trub/chiller loss field should either be removed, or used correctly to calculate the recipe compensations.
I realize I have repeated myself many, many times. I did this in the hopes that one of them would get read. This is a very simple problem to recreate, understand, and fix- once you believe, of course.