BeerTools Pro Bug Reports Archive A

[jeff]

Jeff: What does "deadspace" mean, in regard to the 'vessel' edit page? If it means the space under a false bottom, then why doesn't it impact thickness? If it is not under a false bottom, then how does your program take that into consideration?

Deadspace is the volume that cannot be drained from the vessel. While in the vessel, the deadspace volume is used in the calculations - including thickness.

[slothrob]

The confusion on deadspace comes when you have something like a cooler mashtun with a stainless steel braid that has a volume that cannot be drained from the vessel, yet it is mixed with the grain, so it should not be excluded from the thickness calculation.

[billvelek]

The confusion on deadspace comes when you have something like a cooler mashtun with a stainless steel braid that has a volume that cannot be drained from the vessel, yet it is mixed with the grain, so it should not be excluded from the thickness calculation.

Actually, I think it is just the opposite. I use 10 feet of 1/2" stainless steel braid, which computes to a volume of roughly 13 fluid ounces. It is not deadspace, as defined by Jeff, because it DOES drain from the tun, but because it holds liquid without grain mixed with it, it will affect thickness. Let me give an exaggerated example; if I created a false button, through which my grist will not pass, and it has a volume capacity beneath the false bottom of 3 gallons, and I pitch 4 gallons into my grist, 3 gallons of that should drain through the grist into the bottom of the tun under the false bottom, leaving only 1 gallon to soak the grist. Tell me that that isn't going to affect thickness. This is why I had assumed, without a definition in the Guide, that the 'deadspace' might be the volume beneath the false bottom, which WILL affect thickness, but when I experimented, BTP did not adjust thickness because of it. Knowing now what the definition is, I can understand and agree that 'deadspace' should not factor into thickness; however, there is nothing in BTP to account for liquor that drains through the grist into a false bottom. That is what I was trying to suggest to Jeff. And slothrob, what is the difference between braid and a false bottom plate; they both separate liquor from the grist. Consequently, they BOTH should affect thickness; now, maybe it isn't enough to be bothered with, but nonetheless they will affect thickness.

Cheers.

Bill Velek

[Brant]

I think Jeff's reply confirms my message about "deadspace" having two separate definitions (not sure if my message got missed on the page roll-over, or if I was so unclear or off the wall that nobody understood what I meant! ). I agree with Bill that the liquid below my dome-shaped false bottom is not doing anything to affect the thickness. But I don't agree with the software that that volume of liquid is the same amount as cannot drain from my mash/lauter tun. All of this is probably more academic than relevant, though, since we aren't talking about much water.

[slothrob]

Clearly we're talking about two different values. Their effect on the system depends on the exact configuration of the system you're working on and, from Bill's comments, can't even be simplified to a false bottom/brain argument.

Bill's braid example shows one where significant "deadspace" is drainable but not part of the mash.

On my system, there is no substantial drainable space that is not part of the mash, but there is 20 ounces of undrainable space that is part of the mash.

In my Tun, there is less than 6" of 1/2" braid (70 mL, maybe? Only 2 or 3 ounces, at the most), causing minimal change in thickness of the mash (1.20 qts/# becomes 1.19 qts/# with this entered as deadspace). Non-drainable volume (what I had been calling Deadspace in my system) is liquid below the lowest point of the pick-up tube, but is part of the mash as it is largely outside of the braid.

Then there are the cases of false bottoms and false bottom systems with pickup tubes that go into the space below the false bottom.

The way I've decided to deal with this, now that I understand the logic that BTP is using, is to enter the volume excluded from the mash as Deadspace and the undrainable volume left in the tun as Residual Volume in the Separation step. I know this isn't as Jeff described it, but it seems to make the most logical sense for the calculations.

[djavet]

Dominique... What exactly are you trying to do?

1. Take a 19L recipe, and do a partial boil on a 10L Kettle?
2. Take a 19L recipe, and turn it into a 10L recipe?
3. Take a 19L recipe, and separate out the boil for use in a 10L Kettle in 2 steps?

It's the first option.
I wish make 19l. with a 10l kettle.
This feature ist really good thinked in Beersmith.

I dont find the way to solve my hop ratio in BTP like Beersmith.
A new feature?

Thx for your help.

Regards, Dom

[bzwrxbz]

Dominique... What exactly are you trying to do?

1. Take a 19L recipe, and do a partial boil on a 10L Kettle?
2. Take a 19L recipe, and turn it into a 10L recipe?
3. Take a 19L recipe, and separate out the boil for use in a 10L Kettle in 2 steps?

It's the first option.
I wish make 19l. with a 10l kettle.
This feature ist really good thinked in Beersmith.

I dont find the way to solve my hop ratio in BTP like Beersmith.
A new feature?

Thx for your help.

Regards, Dom

YES! I see what you are saying now!

Here is how I replicated the problem.

1. Check all three boxes (next to "Kettle Volume", next to "Efficiency", next to "Final Volume")
2. Set the drop down next to "Final Volume" to "Lock"
3. Lower the Kettle Volume.

Now, the hop amounts stay the same, but the IBU stays the same as well while I lower the Kettle Volume. It was my belief that this can not be true. The IBU calculation is a function of the "Kettle Volume" (and its Specific Gravity) and the "Final Volume".

Utilization goes down as the gravity of the wort increases. I should see the Bitterness value taking a dive as I lower the Kettle Volume.

This seems to be a major bug, or my assumptions about hop utilization are incorrect?

cheers!

[bzwrxbz]

For example... i am working with RecipeX.btp

I change the Kettle Volume.

I do not save the file... and I open RecipeX.btp again. The saved RecipeX.btp "Kettle Volume" value does not appear, but the one I modified before I reopened does appear.

The same goes for ingredients as far as I can tell.

Rel18.

cheers!

[slothrob]

I've had the same problem with opening a saved file over the same, but alterred file. I've done this to backtrack after I made a mistake (sort of a global undo) and to try to compare a changed recipe to the original.

If the changed file is still open, and I open the original file the file appears with the current changes.

If the file is closed, not saving changes, then the original is opened, the original unchanged file opens as expected.

[djavet]

This seems to be a major bug, or my assumptions about hop utilization are incorrect?

Glad to see you arrive at the same conclusion.

Hope this will be correct soon.
Regards, Dom

[Brant]

If the changed file is still open, and I open the original file the file appears with the current changes.

bzwrxbz and slothrob, I think what is happening is that the already-loaded RecipeX window is given focus (brought to the foreground) when you File / Open RecipeX.btp. Try opening a second RecipeY.btp window on top of the RecipeX.btp window, and use its File / Open to open RecipeX.btp. It will give the modified RecipeX.btp window focus.

I'm not sure how it should work, but I think it could be argued that if you already have a particular file open, and you File / Open the same file again, it should not wipe out the changes that you have been making. For example, what if you accidentally clicked the wrong filename to open, when you were trying to open a different file to use as a reference while helping you create your new recipe? Imagine the disgust if someone had spent a lot of time on a recipe, just to have it blown away by a File / Open command? Another alternative might be to open a separate window with the RecipeX.btp recipe. But I don't like the thought of having two windows whose File / Save command are tied to the same file, because that would make it very easy for users to screw up and lose data.

If the current behavior is unacceptable, then perhaps an "are you sure?" confirmation box would be in order, before overwriting the unsaved data on the screen. I think I've seen some applications that do something like that.

[slothrob]

It's fine for me the way it is, I just needed to learn how it worked so that I worked that way as well.

[billvelek]

Snip ... For example, what if you accidentally clicked the wrong filename to open, when you were trying to open a different file to use as a reference while helping you create your new recipe? Imagine the disgust if someone had spent a lot of time on a recipe, just to have it blown away by a File / Open command?

Excellent point.

Bill Velek

[jeff]

I'm not sure how it should work, but I think it could be argued that if you already have a particular file open, and you File / Open the same file again, it should not wipe out the changes that you have been making.

This is exactly how it was designed to work, and for exactly the reason you state. However, if the user desires to reload the last saved version of the file, it should be done with a File menu item called "Revert" or "Revert To Last Saved Version". I can easily add a menu item that does this in a future update. Problem solved?

[billvelek]

If I understand that your proposed "Revert" will only bring back the last SAVED file, then that won't help a user who has made some extensive changes but before saving them he "accidentally" reopens the same file and wipes out all that work. This is similar to where I found myself re a recent post that I was making in the last couple of days and "accidentally" clicked the "X" within my browser's tab when all I intended to do was to click on the tab itself in order to switch to it; I deleted a nearly-completed very lengthy post in this forum, wasting a bunch of my time and thoroughly pissing me off. I fixed the browser by disabling the "X"s in my tabs.

I also don't understand why BTP ... "was designed to work" ... that way; if the idea is that BTP is presuming that I want to start all over again with a recipe and that I actually want to abandon any 'unsaved' changes, why is that necessary? First, I could just close the session without saving the changes, and then start a new session and reopen the recipe all over again; very simple to do, and BTP could make it even simpler if you eventually implement one of my suggestions -- to include a short list of the most recently opened BTP files somewhere on the menu as part of the open command. Second, do you actually think that this would be the intent of users often enough that you would design the program to automatically default to that behavior and not give users a choice? Personally, I would think that it would be more common for a user to want to be able to see the original recipe to see what changes had been made so far (and which, of course, would not be saved yet).

Anyway, I would AT LEAST expect a cautionary notice like "Abandon all changes?" to flag me. Better yet would be to have the program open the same recipe -- second session -- as a 'read only' copy that could be used for comparisons. I'm sure there are other approaches, too, but I personally would not be satisfied with a program that could so easily and irretrievably allow the loss of data and hard work by sheer accident, nor would a fix like "Revert" satisfy me if it doesn't retrieve UN-saved changes.

Cheers.

Bill Velek