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 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::type funky_factor_dimension

typedef unit funky_factor;

quantity factor(quantitysi::pressure p, quantitysi::length l, quantitysi::mass_density d) { return (p / l) / d; }

Alternatively:

template < typename System > quantity> factor( quantity> p , quantity> l , quantity> 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-**usershttp://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 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::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' to 'boost::units::quantity' 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/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.