The malt acidty and buffering would come from single point titration or Andrew's voltmeter. Assuming one of us knows how to use it correctly.
You list a multipoint titration here. I will do at least a single point titration I have the citric acid and plastic syringes to measure in cc or ml.
Yes I agree supporting ezRecipe is one thing but supporting Solver is up to Microsoft as far as I'm concerned.
Because I'm not skilled at such things. The whole intent of the project was to make the science accessible to those who are. I have prepared a spreadsheet using them mostly as a demo platform and find it extremely useful and easy to use relative to previous spreadsheets I have done but am well aware that someone who does this for a living could doubtless do it much better.
Because everybody has got Excel. If you can't figure out how to port the meat functions to any other programming language you are a worse programmer than I. The exceptions here would be the functions that gather up the data from the spreadsheet i.e. get what the user enters to the bits that do the actual computation. That is, of course, going to depend on the UI and that in turn will depend on the environment.
It was never intended to be elegant - just functional. My original intent was that it would be hidden in and Excel Add-In (or whatever they are called). The user would not be exposed to the actual code behind Qcarb any more than he is exposed to the code for VLOOKUP.
Visual Basic is an OOP language.
As is manifestly clear in this thread and others water chemistry is not something that is comprehensible to the average home brewer (nor to most commercial brewers either).
Given the last comment, one of the goals here was to make functions that would, for example, return the charge on a liter of water or the charge on a killogram of malt available to the user without explaining how they are computed or why. The job of pH estimation then becomes that of setting things up so that the net sum gain in charge over a mash is 0. Given that only perhaps two or three people here understand that it appears that this approach is not going to lead to success.
Though the "manual" is not complete the chemistry is in the Appendix.
Impossible. For some reason this particular area of chemistry is very hard to understand.
Alkalinity is a very simple concept when considered in the context of a water supply. It is only when you generalize the concept to solve any problem involving the mixing of buffers that you lose 99% of readers.
No worries. The endeavour to this point is certainly a torso undertaken by a FORTRAN programming engineer more interested in algorithms than pretty code. As before, I encourage anyone with real programming skills to run with it.
I did create an Excel Addin in the format of a COM object. It's loaded the same way we reference and include the Solver Addin. The trouble is not everyone is skilled enough in Excel to know how to install and use the Addin. It's a shame because the Addin code is binary making it very efficient while also making it nearly impossible to crack. Unfortunately, the Addin will not run in anything other than a Windows environment.
If you are trying to say that empically derived results based on careful measurements are better than predictions based on a faulty math model then that is true. The key word here is "careful". That means that the measurements, on the one hand, must be accurate and on the other that they span the entire set of conditions over which we are interested.Sorry guys, I'm just in this thread to clean up some nastiness, but I'd like to comment on the statements above. In the past, I've been in the embarrassing position of defending a mathematical solution to some real-world measurements, when ultimately the empirically-derived table lookup was just better. I now know that in the real world there are confounding variables that the math doesn't appreciate, but the measured data certainly does
The thing that you consistently miss here is that you can use pH by itself to calculate the charge on water and only water with it's pK of 14. The pH scale is based on this pK. pH does not give the charge on malt or bicarbonate ion or chloride ion unless the pK's for those substances are included in the calculation. The fact that however you use it may sometimes give a reasonable answer is proabably as much coincidence as anything else. I can come up with an algorithm that predicts that, given the amount of snow on the ground here the weather in Alice Springs, NT is fine. It works but has no scientific or other basis.
You have misinterpreted what I said. I am offering no excuses or apologies: just telling you why it is the way it is. If you think you can do it better (and you probably can) then do it.
The project communicates the "algorithms" quite clearly. The most important ones are simple evaluations of formulas which clearly discernable from the code. The second are implementations of well know root finders (bisection, Newton's method) with which any programmer should be familiar. The third are algorithms that gather up the data from the user interface which in this case happens to be based on Excel and which clearly need to be modified to work with whatever platform you choose to implement on.
Yes, it is trivial to port type I and type II functions described above. There is no way I can clarify for you what you need to do to gather input data from whatever platform you may decide to implement because I have no idea what choice you will make nor would I be able to even if I knew.
Nothing wrong with Excel for the current purpose. Not saying there might not be a better environment but if you choose one you'll have to modify user interfaced. If you can't port the type I and type II stuff I question as to whether you would be able to do that.
Anyone should be able to. The code makes it very clear what formulas are being evaluated. Everybody who took high school math knows Newton's method and any programmer should know root bisection.
Look at Qacid. Then look at the steps for computing Q in the Sticky at the top of the page. Do you see any similarities?
If you want Excel independent (whatever that means) functions you are going to have to write them yourself. I could, I suppose, rewrite all the functions in something like Pseudo-ALGOL but what would be the point? It wouldn't take any more effort to port from VB to any other language than it does from Pseudo ALGOL.
But why would I? These tools are there for you to do whatever you want with. Yes, in the demo spreadsheet I often "improve" things, add functionality etc. but these improvements make things more to my liking. I do use the tools in at least one other environment where I want to process data in ways where a spread sheet would be clumsy.
You are either not following me, not reading what I have written or have no concept of how scientific programming is done. I have mentioned several times that if you will simply look at the code for Qacid, which is probably the most basic tool in the drawer, you will, or should be able to, comprehend the 'algortithm' for computing charge on the anions of a polyprotic acid. If you cannot you can look at the sticky here or read the manual on the yola site. If after doing those things you are still unable to understand how Q is computed then I am afraid you are not going to be able to benefit from these tools. So be it. I can't play the violin. Others here have been able to use them with some success. Your talents may lie in other areas of endeavour.
Yes, yes, I know that and I keep repeating that I know that and you keep stating that over and over again. A child can look at the Excel Qacid function or the IGOR Qacid function and recast it in any form he wants because it is glaringly obvious from it what one must do to compute Q from pH and the pK's.
Given the universe of things that Solver will do and the conditions under which it will do them then this statement is true. But surely you cannot mean this in the context of finding the pH of a mash. Because of the near linearity and the limited range of possible answers one can use trivial methods like root bisection or Newtons's method. The only part that is annoying is the part in which you must gather the information about the amount of each malt, the alkalinity of the water, the source pH, the amount of acids/bases added from wherever you have had your user put them. That can be tedious but it's hardly difficult. If that's what you mean by non trivial then I agree but once you have a function that returns ∆Q finding its root (what Solver does) is indeed trivial.
Yes, that is what I mean AJ. If Solver is a key component of your voltmeter and I think it is then trying to code its functionality is well beyond myself and most likely any other developer frequenting this forum.
No, I was talking about replacing the Solver Addin functionality. Are you saying your voltmeter works without using the Solver Addin?
Yes. Got rid of the Solver way last summer.
As I indicated above the mechanism of reaction is well understood and is the same for all acids and bases. The reaction for mevalonic acid is not different from that of lactic acid. By not considering lactic acid we are not falling victim to ignorance of the chemistry. If we are guilty of anything it is laziness. We don't want to be bothered with tallying up all the 'microreactions' and justify our laziness because we know that mevalonic acid is not a player in brewing water chemistry. Now were it. And let's say that it actually is. It would get picked up in the malt measurements just as the other acids are.
