ReonArd,
It's one thing to match output, but you started with the dimensions. Your spreadsheet is typical for rating existing equipment. You start with a design, then check the parameters. That's quite different from designing a new separator. To use your spreadsheet for design is a "poke & hope" operation. And you have no way to optimize, i.e. minimum cost. Hard code is much safer, and easier to verify when developing the software. But most engineers never go beyond spreadsheets with cell formulas. I have seen some from major engineering companies that are examples of horrible spaghetti.
You can download software from my site when you register. There are some related to drop settling. They demonstrates using libraries with a spreadsheet by comparing results with VBA, where you can see the calculations.
You should seriously consider developing coding skill to move on from Excel cell formulas.
There are a few affordable calculators that are reliable. These should be recommended in lieu of spreadsheets. Unit conversion and fluid flow and others can be found at katmarsoftware.com. The author, Harvey Wilson shows up here occasionally.
Bobby
Thank you for the links, I will certainly have a look.
Regarding the KOD drum calculation, in my past projects the objective was typically either of these:
- New design with design constraints defined by the client (usually maximum length of the drum for transport reasons or ID for manufacturing reasons). In this case I would lock one dimension and vary the other to optimize the size. If there is no such constrain, I would apply a cost function to the Length/Diameter ratio and aim to optimize the Utilization = Residence Time / Settling Time just over 100% (with design margin).
- Rating existing KOD, in which case I start with 100% Utilization and work out the maximum separation ability.
The sheet was developed to accommodate all such scenarios.
Actually, the KOD sheet as well as all the others, was originally programmed with VBA and later reworked to a simple spreadsheet for several reasons. We found that working directly with sheets allows greater flexibility, using functions instead of simple numerical values as an input, and the ability to goal seek where necessary. In this way we could respond very quickly to the differences in each project. Also with hard coded software the junior engineers had a tendency of just hitting the button and accepting the values without fully understanding the calculation mechanism.
Last but the most important reason: a few years ago my company started phasing out locally installed MS Office in favor of cloud based solutions (Office 365, LibreOffice, OnlyOffice, Zoho etc.) and remotely hosted solutions (VPN and VPS), where the VBA compilation very often failed due to incompatibility issues or could not be used at all on the hosted side. Additionally, most software we originally had was supported only on Windows or Macs, but with cloud shared sheets we can access our company repository from any type of device and operating system, be it Windows, Apple, Linux or Android.