Using literals for measurement units

[vhirtham]

I recently stumbled about user defined literals:

http://en.cppreference.com/w/cpp/language/user_literal

We can use them to define physical measurement units, so you can write something like

std::cout << 12._MPa << std::endl;

which returns "1.2e+07".

To be clear: They don't provide any kind of type safety. So you can pass a Newton as a parameter into a function that is supposed to take a time unit. The only benefit would be a better readability for the "user" and maybe the avoidance of typos. Personal neural network failures like mixing values in mm with values in m would also be a little bit more obvious than raw numbers. The implementation is quiet simple:

constexpr long double operator""_N(long double input)
{
    return 1.0 * input;
};

constexpr long double operator""_m(long double input)
{
    return 1. * input;
};

constexpr long double operator""_MPa(long double input)
{
    return 1._N / (1._m * 1._m) * 1.e6 * input;
};

As long as you use them consistently, you should only run into unit related issues, if your law uses an own unit measurement system internally. We can collect all of the literals in a single header "nutoLiterals.h". Nobody would be forced to use them because they are just replacing scaling factors.

So what do you think?

[joergfunger]

If you output something, this is then in the scaled SI-units, i.e. you put in the strength in MPa, and in your visualization file in paraview, the result is scaled be 1e-6? I see the beauty for the inputs, but I'm not sure, if this automatic conversion is clear for a user.

[vhirtham]

You are right. It is only for the inputs and if you use SI units as base your results are always in SI too. I don't think it is a real problem, since this feature would be totally optional to the user. If he uses it, he hopefully read a well documented tutorial which tells him about this issue before. To be sure, we can also name the header something like SIScalingLiterals.h or SIFactorLiterals.h so that it is more obvious that you are just dealing with factors. Additionally use a extra namespace to make it absolutely clear.

In my opinion this feature could help you in several ways.

• You somehow get a clue, what somebody wants to pass to his integrand. 10_MPa is way more clear than 10.000.000.
• If you use it consistently, you wont run into unit related issues in your main file
• It helps narrowing down errors while writing an integrand. If your results are off by some factor, you can at least be sure, that it is probably not related to a stupid scaling mistake hidden somewhere in your main file. Even if, it is easier to find (see first bullet point)

[Psirus]

If we want help with units, then why not just use Boost units?

• it would be typesafe
• almost every unit you can think of is already there
• includes all prefixes (kilo, mega...)
• different unit systems if you're so inclined
• various physical constants (molar gas constant for example that we define ourselves atm)

[vhirtham]

Just had a short look at it, but aren't those own types which requires to provide corresponding interfaces? The thing about the literals is, that its just a scaling factor, so no adjustments are needed and you are not forced to use them.

[TTitscher]

So our libnuto still runs on simple doubles and the user may (or may not) define some units. I personally, as a user, deviate from SI units and calculate in millimetres in all my applications/tests. And, thus, pressure is in MPa. So E = 20000 (MPa), instead of E = 20000 * 1e6(Pa). Maybe, for someone that calculates bigger structures, meters will be the preference. Or an imperial guy uses pound force or poundal per square inch. But there are always parts of the lib that may not be useful for others, like PhysicalConstants.h or IGA or voronoi visualization or history data or whatever. So if that is helpful for you, put it in.