Add StandardVolumeFlow quantity

[rohahn]

Add the Standard Volume Flow quantity which represents the molar flow rate of a gas corrected to "standardized" conditions of temperature and pressure thus representing a fixed number of moles of gas regardless of composition and actual flow conditions.
This is a simple implementation which only adds the quantity with some common units but no complex conversion between different conditions.

Fixes #724

[angularsen]

Looks good to me, thanks!

I think it was a good idea to attack this simpler use case first, then think about how to convert to other conditions separately as discussed in #724 .

[angularsen]

@rohahn This is almost done, what you're missing is adding the test cases.

Step 4 in the wiki: https://github.com/angularsen/UnitsNet/wiki/Adding-a-New-Unit#4-fix-generated-test-stubs-to-resolve-compile-errors-tests

You'll see the AppVeyor build failed due to the missing test cases:
https://ci.appveyor.com/project/angularsen/unitsnet/builds/36867747

[angularsen]

Add missing test cases.

[bitbonk]

Should it really be called StandardVolumeFlow?

I am no expert in this but when it comes to mass flow controller devices who usually measure using the unit sccm, they actually measure the mass of the gas that is currently being let through, that is, the mass flow rate.

From wikipedia:

SCCM is a measure of mass flow rate.

[rohahn]

If you search in Wolfram Alpha, it says Standard Volume Flow. So it seems there is not only a dispute about the meaning of standard but already about the name of the quantity. I first thought about adding the units to the MassFlow quantity, but discarded the idea, since I can not convert to the other units of the quantity. StandardMassFlow seemed wrong.

[bitbonk]

From the perspective of a mass flow controller device I would have called it MassFlowRate.

[rohahn]

Add missing test cases.

I already implemented the unit tests but forgot to add the generated files to git. I'll amend the commit and rebase it on your latest master.

[codecov]

Codecov Report

Merging #870 (2de9422) into master (4993a2a) will decrease coverage by 0.40%.
The diff coverage is 81.33%.

@@            Coverage Diff             @@
##           master     #870      +/-   ##
==========================================
- Coverage   83.09%   82.69%   -0.41%     
==========================================
  Files         287      291       +4     
  Lines       42987    44010    +1023     
==========================================
+ Hits        35720    36393     +673     
- Misses       7267     7617     +350     

Impacted Files	Coverage Δ
UnitsNet/GeneratedCode/UnitAbbreviationsCache.g.cs	100.00% <ø> (ø)
UnitsNet/GeneratedCode/Quantity.g.cs	51.96% <50.00%> (-29.45%)	⬇️
...t/GeneratedCode/Quantities/StandardVolumeFlow.g.cs	80.12% <80.06%> (ø)
...atedCode/NumberToStandardVolumeFlowExtensions.g.cs	100.00% <100.00%> (ø)
UnitsNet/GeneratedCode/UnitConverter.g.cs	100.00% <100.00%> (ø)
UnitsNet/CustomCode/Quantity.cs	81.08% <0.00%> (-3.13%)	⬇️
UnitsNet/QuantityTypeConverter.cs	98.38% <0.00%> (-0.03%)	⬇️
...Serialization.JsonNet/UnitsNetBaseJsonConverter.cs	100.00% <0.00%> (ø)
... and 110 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4993a2a...2de9422. Read the comment docs.

[rohahn]

I am not sure how to increase the coverage in the generated code.

[angularsen]

Don't worry about it, generated code has less coverage than custom code. That's all.

[angularsen]

https://en.wikipedia.org/wiki/Standard_cubic_centimetres_per_minute

SCCM is a measure of mass flow rate, and in spite of its name it must not be confused with a measure of volumetric flow rate. One SCCM indicates the mass flow rate of one cubic centimeter per minute of a fluid, typically a gas, at a density defined at some standard temperature, and pressure.
To convert one SCCM to the measure of mass flow rate in the SI system, kg/s, one relies in the fundamental relationship between mass flow rate and volumetric flow rate (see volumetric flow rate),

Okay, so it's a mass flow rate then.

https://www.first-sensor.com/cms/upload/appnotes/AN_Massflow_E_11153.pdf

A volumetric flow at standard conditions translates to a specific mass flow rate.
For example, 200 cm3 /min of dry air at standard conditions of temperature and pressure (200 sccm) calculates to a mass flow of 0.258 g/min as will be shown below.

Wait, so it's a volumetric flow rate, at standard conditions, that can be translated to mass flow rate?

https://en.wikipedia.org/wiki/Volumetric_flow_rate

Another unit used is standard cubic centimetres per minute (SCCM).

The volumetric wiki seems onboard with sscm.

https://sensing.honeywell.com/mass-flow-vs-volumetric-flow-and-unit-conversion-tn-008043-2-en-final-06nov12.pdf

Microbridge products are specified in “standard” volumetric flow (Qs) such as standard cubic centimeters per minute (SCCM) [..] which can be translated into true mass flow as indicated above
The microbridge sensor is a mass flow device rather than a volumetric one. At a constant mass flow, the microbridge device will give the same output even if there are temperatureor pressure changes.

And this third one agrees. The measurement is volumetric at standard conditions that can be translated into mass flow, given the density of the material.

I think the equation is pretty much this (source):

MassFlowRate = MaterialDensity * StandardVolumetricFlowRate

Even the wikis seem to contradict each other and I suspect the unit is in practice used interchangeably, but still think StandardVolumeFlow is the better compromise than MassFlow, which we already have in Units.NET with units like kg/s or g/min.

I'm a layman in this domain though, so I need you two guys to help agree on what we should go for here @bitbonk @rohahn 👍

[bitbonk]

LGTM

[rohahn]

We agreed on StandardVolumeFlow. Unfortunately the equation also depends on pressure and temperature for which multiple standards exist. I assume we could either configure these values with static properties of the StandardVolumeFlow class or pass them to custom constructors.

[angularsen]

I thought standard volume flow meant the parameters for temperature and pressure was well-defined, are you saying we need to support different standards of temp/pressure in order to use this quantity?

If so, then we did solve a similar need with ReferencePressure that may be useful to look at.

[rohahn]

Unfortunately it seems there are a lot of different standards. They could not even agree on the term standard, there is also the term normal.

https://instrumentationandcontrol.net/difference-between-actual-standard-and-normal-flows.html#standards
What a mess!

At the moment we don't need to calculate with these values, we just need the unit "sccm" in our generic UI. But of course it would be nice to have a full implementation.

[angularsen]

One option to support these other standards is to use different abbreviations, like RealCubicCentimeterPerMinute "sccm (real)" Or similar. See Volume gallon units as an example of conventions used in the library : ImperialGallon "gal (imp.)" UsGallon "gal (U.S.)"

[rohahn]

I have not seen a notation that includes temperature and pressure yet. For our use case we just need the established unit names like "sccm". I am also not sure if it is necessary to work with different standards within one application.

[rohahn]

@angularsen What is the current state on this PR? Do you need additional changes?

[angularsen]

Ok, looks good to me! Let's start easy with this one, and tackle other standards later if the need arises.

[angularsen]

Nuget is on the way
Release UnitsNet/4.83.0 · angularsen/UnitsNet

[rohahn]

Great! Thanks for your support.

[letherman255]

Hi guys,

I might be a bit late for this comment, but I work in a gas mass flowmeter and controller company and I just wanted to confirm and perhaps add a few things.

First of all, I'm glad to see that you classified the final unit as a specific volumetric flow rather then a mass flow. This is often misleading and companies generally use inaccurate terms for simplicity reasons. In short, there are three categories :

• Volumetric flow [Volume / time]
• Standard Volumetric flow [Volume / time] at a specific reference temperature and pressure which is falsely referred in the industry as "mass flow".
• Mass flow [Mass / time ] which is often referred in the industry as "true mass flow"

As you can see, the naming between mass flow and standard volumetric flow is misleading.

As for the actual flow standards, I can confirm that there are quite a few but in practice, the standard temperature is the the parameter that changes the most, I've actually never seen any other standard pressure then 1013 hPa, let alone humidity as most applications rely on dry gasses (there are few devices out there that can handle phase changes, you would only use mass flow in such applications).

The point I'm trying to make is that Standard volumetric flow only makes sense if you are able to define a standard temperature and pressure, there are plenty of applications that involve using multiple standard conditions. Unfortunately converting between flow standards is not as simple as it seems. The issue is the chosen gas model, the simplest one is the ideal gas model : PV=nR*T
(https://en.wikipedia.org/wiki/Ideal_gas_law), if you use this model, the conversion is pretty simple

Qstandard = Qvolumetric * (Actual pressure.Pascals / Actual temperature.Kelvins) *
                   (Standard Temperature.Kelvins / Standard Pressure.Pascals)

This model does not take into account the actual volume of the modecules and the forces that the molecules apply on one another, it thus looses its accuracy at higher pressures and temperatures (roughly above 5 bars).

A better model does exists, the Van der Vaals equation whish solves this issue (https://en.wikipedia.org/wiki/Van_der_Waals_equation) but it requires solving a 3rd degree polynomial which is doable but harder to implement (I've got a python script for this if needed).

Overall , suggest the following improvements :

• Add support for specifying the standard temperature and pressure
• Add the ability to specify a gas model. perhaps having the ideal gas law builtin and let the user provide his own if needed as the ideal gas law would be enough in most applications (this would also include mass to volumetric flow calculations)
• Add the ability to convert between standards flows using the specified model

[angularsen]

@letherman255 Thanks a lot for great details, I was able to follow the reasoning.
Your suggestions make sense to me at least. Would you be interested in attempting one or more pull requests?

I'm happy to assist with conventions and how to best fit it into the library, but it's always best to have it implemented by someone who will be using the new functionality and know the domain well.

[letherman255]

@angularsen I would gladly give it a try, I'll need those features in my own applications anyways. I've just began using the library myself though, so I will need a bit of time to familiarize myself with it first before I can come up with a decent solution.

[letherman255]

@angularsen I started diving into the code and I think I have a few ideas.

It seems to me that having an actual quantity for a standard flow is not the right way to go. A standard flow IS a volumetric flow (just a value conversion in relation to specific conditions), not an actual unit as the base units are exactly the same. Every volumetric flow unit can be used as a standard flow unit. Creating a new quantity for standard flow requires copying the entire volumetric flow quantity and call it standard flow, this would probably lead to a lack of consistency between volumetric flow and standard flow : Some units would be available in one quantity but not in the other which is already the case.

I found that the pressure wrapper is a very similar issue as you wouldn't want to create 3 different quantities for Absolute, Gauge and Vacuum since the conversion simply relies on subtracting a reference pressure. In the case of a standard flow, the conversion is a bit trickier, requiring a more elaborate gas model, but the reasoning stays the same.

At first glance, I would do the following:

• Replace the current standard flow by a wrapper similar to the Pressure wrapper. That would probably be a breaking change though, which we could mitigate to some extent a bit by keeping the same naming. The feature was implemented 6 months ago so it may not yet be widely used.
• Figure out some way of altering the abbreviation of the unit to tell apart the volumetric and standard flows. The S or N prefix are commonly used but they are not tied to a particular Localization (I live in the EU and I see them used intermittently, I thing that S is more common in the US)
• Create a gas model interface allowing the user to create their own gas model and inject it in the wrapper. This model could (and perhaps should) also be used in the mass to volumetric conversion. I would then start by implementing the ideal gas model and set it as default.

The last step could be done later, I would first focus on getting the first two right.

Would these changes fit in the library ? @rohahn what is your opinion on this matter ?

[angularsen]

@letherman255 Great, sounds like a good approach to me. Some comments.

• We can mark StandardVolumeFlow as obsolete in the json and name the new wrapper StandardFlow or StandardVolumeFlowWrapper or similar, just to avoid breaking change for now. Breaking changes require a major version bump and a bunch of other items are desired to be part of that in v5: Wishlist for breaking changes #180 .
• The wrapper could implement a unit abbreviation prefix of the VolumeFlow units, that it simply prepends based on culture.
• Injecting a gas model sounds good.

[rohahn]

@letherman255 a full implementation of the standard volume flow would be really nice.
At the moment we don't have to convert or calculate the volume flow values in our framework, since we mainly use them in a generic UI and recipe editor. But our customers might want to convert the units in the future. What we definitely need at the moment, is an unit with the abbreviation "sccm", since our customer expects this.

[letherman255]

@rohahn thanks for the feedback.

I've implemented the conversion with the ideal gas model for now. It will not be as convenient to use as the ReferencePressure given the number of flow standards aka, the standard temperature and pressure will likely either have to be specified every time or I'll have to add dedicated members:

VolumeFlow StandardFlow(Temperature standardTemperature, Pressure standardPressure)

I'll create a pull request once I'm done.