Cubic inch to litre calculations

[stevieb]

Good afternoon fellow Monks,

I'm working on some prototype code that will eventually be translated to the Arduino platform that'll perform the task of monitoring a mixture tank of water and chlorine, and when it reaches a certain level (say only 1/4 full), will eventually perform a mixture of these two chemicals in the appropriate relative amounts to re-fill the tank.

I'm in the initial phase here, basically, I'm trying to get the math correct to ensure I'm seeing the tank at the proper level, both how many cubic inches are left in the tank, as well as how many litres are remaining (likewise, how many of each are missing).

Can I please, once again, have our mathematicians have a peek to see if I'm on the proper mathematical path? Calculations seem sane when using different variable values and comparing the percentages on my calculator (within a percent or two), but before I move on, I'm looking for some re-assurance.

Test sample code (if there are any questions or clarifications required, please advise):

use warnings;
use strict;

use constant {
    PII     => 3.1416,
    DIVISOR => 61.02374409, # cubic inches to litres divisor
    RADIUS  => 2.5,
    DEPTH   => 6,
};

my $cubic_inches = (RADIUS * RADIUS) * PII * DEPTH; # total cubes
my $litres = $cubic_inches / DIVISOR; # total litres

my $empty_depth_inches = 2.80; # inches from top of tank to current li
+quid level

printf("total cubic inches: %f\n", $cubic_inches);

printf("total litres: %f\n", $litres);

printf("current empty litres: %f\n", empty_litres($empty_depth_inches)
+);

printf("current litres: %f\n", current_litres($empty_depth_inches));

printf(
    "percent litres remaining: %f\n",
    current_litres($empty_depth_inches) / $litres * 100
);

printf(
    "percent litres missing: %f\n",
    empty_litres($empty_depth_inches) / $litres * 100
);

printf(
    "percent cubes remaining: %f\n",
    current_cubic_inches($empty_depth_inches) / $cubic_inches * 100
);

sub current_cubic_inches {
    my ($empty_inches) = @_;
    return (RADIUS * RADIUS) * PII * (DEPTH - $empty_inches);
}

sub empty_litres {
    my ($empty_inches) = @_;
    return $litres - (current_cubic_inches($empty_inches) / DIVISOR);
}

sub current_litres {
    my ($empty_inches) = @_;
    return $litres - empty_litres($empty_inches);
}

Output:

total cubic inches: 117.810000
total litres: 1.930560
current empty litres: 0.900928
current litres: 1.029632
percent litres remaining: 53.333333
percent litres missing: 46.666667
percent cubes remaining: 53.333333

For those interested, I'll be using an ultra-sonic distance sensor, a laser level sensor as well as an analog water-level strip to calculate the depth level (to fully ensure as accurate a reading of the depth as possible, as well as for redundancy purposes in case one of the sensors fail). The project will also entail various pumps and solenoids based off of both 12v and 120v relays for the mixing of the chemicals into the mix tank.

All data will be sent over a 433Mhz RF feed from the water purification building back to a central Raspberry Pi, where I'll process the incoming data, and display it both in numerical and graph forms using Dancer2 and a myriad of other Perl distributions and technologies.

[syphilis]

I'm looking for some re-assurance

I don't think the calculations regarding size/height/volume require much accuracy, anyway.
The critical thing is that, whatever the amount the system installs, the water/chlorine ratio has to be right.
As long as that ratio is correct, it doesn't matter that the system thought it delivered enough to restore the height to 6 inches, but in fact delivered only enough to restore the height to 5 inches.
So ... all you really need to closely monitor is the amounts of water and chlorine that are injected (and for simplicity, I'd be measuring those in ml, not cubic inches).
If they are disappearing in the right proportions; the tank level never drops below a quarter full; and the level gets restored to at least, say, two thirds full (without overflowing) then all is good.

I think your arithmetic is well within those bounds.

Cheers,
Rob

[stevieb]

Thanks for the feedback and confirmations, syphilis!

I like the idea of converting to mL. The readings from my liquid throughput sensors I'm using (one after a solenoid opening/closing a live water feed, the other beyond a pump in a chlorine tank) send back an analog signal of cubic inch/second (after deciphering, of course), so I just stuck with that by default.

[pryrt]

The math: The difference between using 12 digits (3.14159265359 / 61.0237440947 = 51.4814798763e-3) vs 5 digits (3.1416 / 61.024 = 51.481e-3) is 9ppm (parts per million), so your volume will be plenty accurate. And as syphilis said, it's the ratios that matter for the water vs chlorine.

[hippo]

Will the volume really be precise? 5 vs 12 significant figures for π pales when compared to 2 significant figures for radius and only 1 significant figure for depth.

I agree with both of you about the ratios.

[bliako]

If you are in the USA, certain parts have even legislated the PI value (re: Indiana Pi Bill). Not only one must abide to the physical laws, there is also legislation!

Now, as others said, it's the ratios that matter. But you will need to order some chlorine in litres...

[Lotus1]

That 1897 bill was never made into law.

In defense of Indiana the citizens have had the good sense to resist daylight saving time for the most part until 2006.

[stevieb]

Your feedback, as always, goes one heck of a long way, pryrt.

Thank you for your expansion on the matter. I may be requesting feedback on consolidation on some of these matters.

[vr]

Because stubborn, I'd hate to use imprecise divisor when there's perfectly exact multiplier. Because lazy to remember or look up, I usually use atan2(0,-1) for PI. It's illogical and futile with floating point maths, but perhaps, just perhaps, if volumes are summed all year round, eliminating tiny-tiny error will save me a millilitre of chlorine...