Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Efficiency into boil kettle calculation unstable after closing and re-opening Brewtarget #789

Closed
dschwilk opened this issue Feb 3, 2024 · 5 comments

Comments

@dschwilk
Copy link

dschwilk commented Feb 3, 2024

brewtarget-3.0.10-2_amd64.deb on Kubuntu 22.04 fresh install. Fresh sqlite database

If I edit the SG value under a BrewNote preboil tab, the "Efficiency into boil kettle" recalculates. The first time it does this, the calculation looks correct and matches the recipe tab and my external calculations. However, after a save and re-opening, this changes and the "Efficiency into boil kettle" number goes WAY up (and so does predicted postboil OG). It then stays stable at some new incorrect calculation (eg 99% when it should be 75%).

The only fix is to delete that brewnote and create another, but the problem re-emerges. I deleted my database and re-installed. This happens with built in recipes. For example, If I "brew it" on the Bt: American Pale Ale recipe, and change the preoboil sg, it calculates correctly (69.6% at sg 1.042 vol 6.75 gal). Closing brewtarget and re-opening, then changing that sg field, results in an incorrect Efficiency into boil kettle number (85.41% at sg 1.042).

@dschwilk
Copy link
Author

dschwilk commented Feb 3, 2024

Getting the same problem with brewtarget-3.0.11 latest build (using github built deb)

@matty0ung
Copy link
Contributor

Thanks for the detailed report. I've reproduced the bug locally. Will have a look at what's going on.

@matty0ung
Copy link
Contributor

It's a one-line fix. The "getter" function for "expected volume into kettle" is picking up the wrong field and returning "expected volume into fermenter", which then, obviously, throws off the other calculations. Patch incoming.

@matty0ung
Copy link
Contributor

Should be fixed by #790, but please reopen if not.

Will try to get to a 3.0.11 release soon!

@matty0ung
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants