boost::units primer explained / conversion factors required
Okay, here's what we need to get at, for starters. And maybe an illustration or three and a little exchange will go a long way towards helping my better comprehend units. I'm starting with a set of SI calculations for oil and gas constants calculations. Eventually we will need to accommodate US units as well. But not quite yet. We need to get at a calculation involving Pressure Gradient, which ends up being metric::bar/si::meter (bars over meters) in specific units, or I suppose si::pressure/si::length might also work. Then we need to get after Fluid Density, which ends up being si::kilogram/si:meter^3 (kilograms over cubic meters) in specific units, or I suppose si::mass/si::meter^3 (I don't know what this looks like in terms of boost::units, maybe one of the volumes?), or perhaps make use of mass_density? We take all that and divide Pressure Gradient by Fluid Density to arrive at what we hope will be the the conversion factor: 0.0000981. Which we could specify that as a constant, but I like proving it through the software first (plausibly once) when we ask for it. Similar type calculations would follow for US units involving gallons, cubic inches, inches, and inches per foot, along these lines. So I need some examples will spell it out for me. The learning curve using boost::units is just too steep for me right now without it. Any tips or pointers along these lines would be much appreciated. Thank you, Michael
On 7/21/2011 3:16 PM, Michael Powell wrote:
Okay, here's what we need to get at, for starters. And maybe an illustration or three and a little exchange will go a long way towards helping my better comprehend units.
I'm starting with a set of SI calculations for oil and gas constants calculations. Eventually we will need to accommodate US units as well. But not quite yet.
We need to get at a calculation involving Pressure Gradient, which ends up being metric::bar/si::meter (bars over meters) in specific units, or I suppose si::pressure/si::length might also work.
Then we need to get after Fluid Density, which ends up being si::kilogram/si:meter^3 (kilograms over cubic meters) in specific units, or I suppose si::mass/si::meter^3 (I don't know what this looks like in terms of boost::units, maybe one of the volumes?), or perhaps make use of mass_density?
Yes, it's mass_density.
We take all that and divide Pressure Gradient by Fluid Density to arrive at what we hope will be the the conversion factor: 0.0000981. Which we could specify that as a constant, but I like proving it through the software first (plausibly once) when we ask for it.
So, by your description: ML^-3 * (ML^-1T^-2 * L^-1)^-1 = L^-1T^-2. This latter part is the dimension your factor is in. using namespace boost::units; typedef derived_dimension<length_base_dimension, -1, time_base_dimension, -2>::type funky_factor_dimension typedef unit<funky_factor_dimension, si::system> funky_factor; quantity<funky_factor> factor(quantity<si::pressure> p, quantity<si::length> l, quantity<si::mass_density> d) { return (p / l) / d; } Alternatively: template < typename System > quantity<unit<funky_factor_dimension, System>> factor( quantity<unit<pressure_dimension,System>> p , quantity<unit<length_dimension,System>> l , quantity<unit<mass_density_dimension,System>> d ) { return (p / l) / d; }
Similar type calculations would follow for US units involving gallons, cubic inches, inches, and inches per foot, along these lines.
As long as you use a coherent system, the template version above should work (assuming I got all the types correct).
Hmm, let's see. I think it's more like this, (ML^-1T^-2 * L^-1) * ML^-3 * (ML^-1T^-2 * L^-1)^-1 = L^-1T^-2, Pressure Gradient divided by Fluid (or Mass) Density. I think I follow; doing my home work, one bar being a kilopascal (kPa), or (10e3 * NL^-2), or (10e3 * MLT^-2), so we have (10e3 * MLT^-2 * L^-1). Okay, then yes we divide by mass density of ML^-3, or multiply by (ML^-3)^-1 if you prefer. So we have (10e3 * MLT^-2 * L^-1) * (ML^-3)^-1. Hope my rusty dimensional analysis skills are showing... :-) Okay, so we can do some reductions I think, (10e3 * L^3 * T^-2). Am I reading this correctly? Is this the rate at which a volume transfers? Something along these lines. Really not up on my dimensional analysis like I should be; but I WILL be. However it reduced, please verify I am reducing correctly, I don't think the units are supposed to make sense; we're arriving at an intermediate conversion factor I believe. At least that's how it is explained to me. On Thu, Jul 21, 2011 at 5:23 PM, Noah Roberts <roberts.noah@gmail.com>wrote:
On 7/21/2011 3:16 PM, Michael Powell wrote:
Okay, here's what we need to get at, for starters. And maybe an illustration or three and a little exchange will go a long way towards helping my better comprehend units.
I'm starting with a set of SI calculations for oil and gas constants calculations. Eventually we will need to accommodate US units as well. But not quite yet.
We need to get at a calculation involving Pressure Gradient, which ends up being metric::bar/si::meter (bars over meters) in specific units, or I suppose si::pressure/si::length might also work.
Then we need to get after Fluid Density, which ends up being si::kilogram/si:meter^3 (kilograms over cubic meters) in specific units, or I suppose si::mass/si::meter^3 (I don't know what this looks like in terms of boost::units, maybe one of the volumes?), or perhaps make use of mass_density?
Yes, it's mass_density.
We take all that and divide Pressure Gradient by Fluid Density to arrive at what we hope will be the the conversion factor: 0.0000981. Which we could specify that as a constant, but I like proving it through the software first (plausibly once) when we ask for it.
So, by your description:
ML^-3 * (ML^-1T^-2 * L^-1)^-1 = L^-1T^-2.
This latter part is the dimension your factor is in.
using namespace boost::units;
typedef derived_dimension<length_base_**dimension, -1, time_base_dimension, -2>::type funky_factor_dimension
typedef unit<funky_factor_dimension, si::system> funky_factor;
quantity<funky_factor> factor(quantity<si::pressure> p, quantity<si::length> l, quantity<si::mass_density> d) { return (p / l) / d; }
Alternatively:
template < typename System > quantity<unit<funky_factor_**dimension, System>> factor( quantity<unit<pressure_**dimension,System>> p , quantity<unit<length_**dimension,System>> l , quantity<unit<mass_density_**dimension,System>> d ) { return (p / l) / d;
}
Similar type calculations would follow for US units involving gallons, cubic inches, inches, and inches per foot, along these lines.
As long as you use a coherent system, the template version above should work (assuming I got all the types correct).
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
With this approach, we're getting a compilation error. Not sure what we're doing wrong. #include <boost/units/systems/si.hpp> using namespace boost::units; using boost::units::si::mass; using boost::units::si::pressure; using boost::units::si::length; using boost::units::si::mass_density; using boost::units::si::pascals; using boost::units::si::meter; using boost::units::si::kilograms_per_cubic_meter; typedef derived_dimension<length_base_dimension, 1, time_base_dimension, -2>::type si_hsp_conversion_constant_factor; typedef unit<si_hsp_conversion_constant_factor, si::system> si_hsp_conversion_constant_units; /* 1 bar = 100 kPa (kilopascal) = 10^5 Pa */ quantity<si::pressure> p = 10e5 * pascals; quantity<si::length> l = 1.0 * meter; quantity<si::mass_density> d = 1.0 * kilograms_per_cubic_meter; quantity<si_hsp_conversion_constant_factor> result = (p / l) / d; Error 1 error C2440: 'initializing' : cannot convert from 'boost::units::quantity<Unit,Y>' to 'boost::units::quantity<Unit,Y>' c:\Source\SafetyValve2011\CS.Calculations\calcs\hsp.cpp 100 CS.Calculations On Thu, Jul 21, 2011 at 8:10 PM, Michael Powell <mwpowellnm@gmail.com>wrote:
Hmm, let's see. I think it's more like this, (ML^-1T^-2 * L^-1) * ML^-3 * (ML^-1T^-2 * L^-1)^-1 = L^-1T^-2, Pressure Gradient divided by Fluid (or Mass) Density.
I think I follow; doing my home work, one bar being a kilopascal (kPa), or (10e3 * NL^-2), or (10e3 * MLT^-2), so we have (10e3 * MLT^-2 * L^-1).
Okay, then yes we divide by mass density of ML^-3, or multiply by (ML^-3)^-1 if you prefer.
So we have (10e3 * MLT^-2 * L^-1) * (ML^-3)^-1.
Hope my rusty dimensional analysis skills are showing... :-)
Okay, so we can do some reductions I think, (10e3 * L^3 * T^-2). Am I reading this correctly? Is this the rate at which a volume transfers? Something along these lines. Really not up on my dimensional analysis like I should be; but I WILL be.
However it reduced, please verify I am reducing correctly, I don't think the units are supposed to make sense; we're arriving at an intermediate conversion factor I believe. At least that's how it is explained to me.
On Thu, Jul 21, 2011 at 5:23 PM, Noah Roberts <roberts.noah@gmail.com>wrote:
On 7/21/2011 3:16 PM, Michael Powell wrote:
Okay, here's what we need to get at, for starters. And maybe an illustration or three and a little exchange will go a long way towards helping my better comprehend units.
I'm starting with a set of SI calculations for oil and gas constants calculations. Eventually we will need to accommodate US units as well. But not quite yet.
We need to get at a calculation involving Pressure Gradient, which ends up being metric::bar/si::meter (bars over meters) in specific units, or I suppose si::pressure/si::length might also work.
Then we need to get after Fluid Density, which ends up being si::kilogram/si:meter^3 (kilograms over cubic meters) in specific units, or I suppose si::mass/si::meter^3 (I don't know what this looks like in terms of boost::units, maybe one of the volumes?), or perhaps make use of mass_density?
Yes, it's mass_density.
We take all that and divide Pressure Gradient by Fluid Density to arrive at what we hope will be the the conversion factor: 0.0000981. Which we could specify that as a constant, but I like proving it through the software first (plausibly once) when we ask for it.
So, by your description:
ML^-3 * (ML^-1T^-2 * L^-1)^-1 = L^-1T^-2.
This latter part is the dimension your factor is in.
using namespace boost::units;
typedef derived_dimension<length_base_**dimension, -1, time_base_dimension, -2>::type funky_factor_dimension
typedef unit<funky_factor_dimension, si::system> funky_factor;
quantity<funky_factor> factor(quantity<si::pressure> p, quantity<si::length> l, quantity<si::mass_density> d) { return (p / l) / d; }
Alternatively:
template < typename System > quantity<unit<funky_factor_**dimension, System>> factor( quantity<unit<pressure_**dimension,System>> p , quantity<unit<length_**dimension,System>> l , quantity<unit<mass_density_**dimension,System>> d ) { return (p / l) / d;
}
Similar type calculations would follow for US units involving gallons, cubic inches, inches, and inches per foot, along these lines.
As long as you use a coherent system, the template version above should work (assuming I got all the types correct).
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
On 7/22/2011 9:43 AM, Michael Powell wrote:
With this approach, we're getting a compilation error. Not sure what we're doing wrong.
#include <boost/units/systems/si.hpp> using namespace boost::units; using boost::units::si::mass; using boost::units::si::pressure; using boost::units::si::length; using boost::units::si::mass_density; using boost::units::si::pascals; using boost::units::si::meter; using boost::units::si::kilograms_per_cubic_meter;
typedef derived_dimension<length_base_dimension, 1, time_base_dimension, -2>::type si_hsp_conversion_constant_factor;
In my calculations I said length was to -1.
Error 1 error C2440: 'initializing' : cannot convert from 'boost::units::quantity<Unit,Y>' to 'boost::units::quantity<Unit,Y>' c:\Source\SafetyValve2011\CS.Calculations\calcs\hsp.cpp 100 CS.Calculations
You've got a dimension mismatch. You should have a large block of template looking vomit in your errors. If you format those you can see what kind of conversion is being attempted and then you'll see the true dimensions of your equation.
On 7/22/2011 9:43 AM, Michael Powell wrote:
With this approach, we're getting a compilation error. Not sure what we're doing wrong.
#include <boost/units/systems/si.hpp> using namespace boost::units; using boost::units::si::mass; using boost::units::si::pressure; using boost::units::si::length; using boost::units::si::mass_density; using boost::units::si::pascals; using boost::units::si::meter; using boost::units::si::kilograms_per_cubic_meter;
typedef derived_dimension<length_base_dimension, 1, time_base_dimension, -2>::type si_hsp_conversion_constant_factor;
Are you doing "HSP" as in hydrostatic pressure (head)? If so, it's a unit of length. If not, but this factor is related to head, which it looks like it could be the head/distance, then you're missing an important element to your formula: acceleration due to gravity. This value would indeed be dimensionless because head is length. Engineers leave this value out in some of the formulas they use. The reason they can do this is that they actually use units such that a 1 in units mass is equal to 1 in units weight (a force). For example, 1 lbm = 1 lbf. Thus they feed mass into the equation (from the fluid) but use it as if it were force. This indeed works because the definition of lbf is such that it includes g in it and the g cancels out. When working in SI though this is not possible. In SI you really need to include the g constant: 9.80665 m/s^2. Your formula might then be "press / (den * g) / len"? That would be the rate of head loss per unit length, a dimensionless quantity.
On 7/21/2011 7:10 PM, Michael Powell wrote:
Okay, so we can do some reductions I think, (10e3 * L^3 * T^-2). Am I reading this correctly? Is this the rate at which a volume transfers? Something along these lines. Really not up on my dimensional analysis like I should be; but I WILL be.
Too early on a Friday to do this. The great thing about this library is that if you get it wrong, it'll let you know.
However it reduced, please verify I am reducing correctly, I don't think the units are supposed to make sense; we're arriving at an intermediate conversion factor I believe. At least that's how it is explained to me.
You'll still need units attached to the type. You'll have to convince your customer or engineers that it's necessary. It took a lot of doing in my project but we got our engineering department to decide upon a system and stick with it. We picked SI. You'll run into a lot of "factors" in the equations they give you. You'll have to work with them to find the correct "units" to use. For example, Kv and Cv are the common flow coefficients. Engineers do not think of them as units but in reality they are. Until we realized this we were treating them as dimensionless quantities and bypassing the units to make them so. This caused a lot of issues for us though and eventually we had to go back to the drawing board. Now, engineers often simply don't understand the rigor that is required in programming and it may take a lot of effort, learning and research on your own part but doing these types right is really necessary. In this case we eventually found that flow_coefficient is a dimension (a really funky one - Q/sqrt(dP)) and that the unstandardized unit in SI had to be made up (we called it Kv_si). The engineers then derived conversion factors to the Kv and Cv "units" that we then use to convert user input and display. In short, while engineers will often say, "This value has no unit," they're very often wrong. What they mean is that they *assume* it does not. These types are often intimately related to the formula set they are using and are not universal; use of Cv is in US units and formulas, while Kv is a metric "coefficient". It can take much work to make them so. Sometimes they are right. K, the resistance coefficient, is indeed a dimensionless quantity. One starting point in convincing/instructing your engineers might be to discuss Kv/Cv vs. K.
participants (2)
-
Michael Powell -
Noah Roberts