Question about to_string() function

[milad-gh]

Hi

I'm using your code in my material testing software, Normally string functionality works fine but sometimes seems it not working as I expect.

For example in this code:

auto unit = lbf;
qDebug() << units::to_string(unit).data();

outputs 4.44822161526049964N instead of "lbf"

And another question which can be relevant to the previous one, suppose this code:

auto unit = kilo * Hz;
qDebug() << units::to_string(unit).data();

outputs "1/ms" which is theatrically correct but I need to show "kHz" to my user.
is it possible to do that?

As you know in material testing there are lots of rate units, e.g. force/time, stress/time, strain/time and as multiplier factors all of them are working properly in your library but sometimes I need to present them with different strings in my software, it would be great for me to if there is a way to achieve that.

Thanks in advance.

[phlptp]

The string output is driven by a large map, which generally defaults to including mostly SI based units, and probably could use improvements. The two cases you mentioned I could see adding to the to_string(...) output as they are common enough.

However, in the mean time if there are specific outputs/inputs you want to display that are different than what exists currently.

addUserDefinedUnit("kHz", precise::kilo*precise::Hz);
addUserDefinedUnit("lbf",precise::lbf);

I will make some adjustments based on your comments in the near future, so this shouldn't be necessary but you can use this at present.

[milad-gh]

Thank you so much for your response it solved the issues,

Another issue maybe related and currently I'm struggling with is regarding Strain, As Strain is a dimensionless value I can use "precise::one" or "precise::percentage" to show it and it works fine but when it comes to Strain rate i.e. "one/s" it becomes dimensionally equivalent to Hz and my software shows it as it is frequency but I need to show it as 1/s or s^-1 which is standard strain rate unit.

The problem is that if I override the behavior with addUserDefinedUnit("1/s",precise::one/s); it will also affect showing of frequency units which should be Hz as it it.

I think although Strain is dimensionless but it needs to be distinguished from other dimensionless types,
I saw some flags like count, rad and I tried to handle it with them but I thought maybe you have a better suggestion for it.

[phlptp]

The units of strain should be
strain=precise::pu*precise::m. I am not a mechanical engineer but assuming I understand it right strain is a measure of deformation relative to the original length, which matches up nicely with the per unit definition.

Then you can use this in the string definitions of your choice, including strain rate and it will be distinct from precise::one so shouldn't be conflicting with other frequency units.

[milad-gh]

Yes strain is "deformation/original length" but it is a unitless value or 1.

I think it can't be strain=precise::pu*precise::m because then it would be dimensionally equal to Length and it will not be unitless.

And also I don't have much information about per unit system as I understood it seems that per unit system is mostly used in power electronics is that true? is it then OK to use it with strain ?

[phlptp]

When per unit values are used in power systems they are dimensionless units as well for example puMW, is actual power/power base. This simplifies a lot of calculations, but also maintains certain relationships. puV*puA=puW still hold true.

So to me strain would function similarly using perunit meters.

The other option is to define it as strain=precise::one*precise::eflag Basically wanting some way to discriminate from the regular ratio. To me the perunit route is your best bet since there is an underlying unit(m) there.

In the units library the pu flag is meant as an indicator that the unit is dimensionless. This admittedly gets a little fuzzy when mixing things like strain rate but I have had things like puMW/hr and the calculations work out fine. I would be interested in knowing how this might play out in a different field.

[milad-gh]

Thanks for the explanation; I think I get the concept.

i did make a trade off between these two approaches and I think using eflag is better for my use case because it preserves the base units which I need to analyze elsewhere in of my software.

[phlptp]

I am going to add a few tests that play around with strain and some example problems, after which I will close this issue.

[phlptp]

Strain Application Note