Including uncertainty and classification information in the sensor table

[kersting]

In IEC-61400-12-1 and 2 it is necessary to calculate uncertainties for all sensors. Currently we only hold uncertainty information for the calibration but not uncertainties related to the anemometer classification or just the normal temperature, pressure, and RH uncertainties. I propose the addition of the following fields in the sensor table.

classification uncertainty uncertainty_units uncertainty_k_factor

[abohara]

Hi @kersting (cc @stephenholleran )

Re: uncertainty - Where would those values come from ? I assume usually it is some internal assumption on what those uncertainty might be (on top of the calibration uncertainty).

Re: classification - This makes sense.

[kersting]

@abohara all that information comes from sensor manufacture. There are no assumptions.

• Temperature, pressure, and relative humidity have their uncertainties in the specification sheet. Those are necessary for power performance test.
• Anemometers on the other hand, have a class that will later be converted in the anemometer response uncertainty.

[stephenholleran]

From @kersting in https://github.com/IEA-Task-43/digital_wra_data_standard/issues/89#issuecomment-875009411

@stephenholleran Here is an example for the NRG T60. You can see the accuracy row on the bottom (same as uncertainty). To convert that to uncertainty in energy there is some math that it is necessary but the bottom line is that this is the input for that IEC calculation.

[stephenholleran]

@kersting I think I see two things here.

1. Fair enough that a sensor has an uncertainty/accuracy. My question is then how can we incorporate this given we already have uncertainties under calibration. Would having another uncertainty in the sensor table be confusing? Would it be reasonable to say that the NRG T60 sensor has been calibrated and the uncertainty would end up in the calibration_uncertainty table? Probably technically not but should/could we do it this way? Below is a screenshot of the 3 tables.

2. What would the classification look like? For example an anemometer and this temperature sensor?

[kersting]

@stephenholleran Your proposal of using the current calibration tables would work except that I'm not sure what to do with the reference_bin field. Probably we'd leave it blank. We'd need to add some instructions. Most of the fields for anemometer calibration don't apply to temperature, pressure, and RH uncertainty.

For the classification, it would be anemometer classification, so it would be in the sensor table.

[stephenholleran]

@kersting sorry, digging this up again.

If we stick with what we have already and use the uncertainty under calibration_uncertainty, the reference_bin can already be left blank or null.

If we have a field for uncertainty in the calibration table how could we distinguish this from the calibration_uncertainty table?

I would like to use what we have if we can as I think it would be less confusing for a user and for code parsing it. But if the IEC is requiring thermometer uncertainty then we need to account for it somehow. In the graphic you shared it also has the transfer function which is the slope and offset that should go into the calibration table so there will be entries in there anyway.

Regarding classification: do you have examples of what the different classifications for anemometers and thermometers are?

cc @abohara

[kersting]

@stephenholleran temperature sensors are not calibrated as anemometers in general but the sensor manufactures go through a process of estimating the accuracy of the sensors and provide a range of accuracy. This is where the IEC standard falls short because it does not make it clear that calibration uncertainty means the uncertainty reported by the manufacture. I'm sure someone could perform a calibration in their temperature sensor but nobody does. That is the case because the magnitude of the uncertainty reported by the manufacture (and also "suggested" in the standard) is so much lower than an anemometer when converted to energy that would not make sense a lab calibration of a specific sensor. From my perspective we can keep the variable calibration_uncertainty for the temperature sensor without any problems. The other curve ball is that a temperature sensor usually comes with a radiation shield that has its own uncertainty. The temperature shield is not connected to the logger but encapsulates the temperature sensor. That instrument usually has the highest uncertainty when it comes to temperature and we should both include that in the data model and capture its uncertainty given that it is part of the IEC standard. Perhaps that is a new issue.

As far as the classification goes, I have never seen classification for thermometers. Perhaps because of the order of magnitude of the deviations the industry has not spent time with that. For anemometers on the other hand, there is a lot of literature. The classification has changed from 12-1 to 12-2. Most of the classification literature is still referenced to 12-1 though. You can find the work that is the pillar of anemometer classification here https://www.researchgate.net/publication/245166207_ACCUWIND-Classification_of_Five_Cup_Anemometers_According_to_IEC61400-12-1

However, if you want just the summary of the classification according to 61400-12-1 just go directly to page 68. This is an important part of the uncertainty calculation because the classification sometimes can be one of the biggest contributors. Any power performance test will use this and everything is indicating that will show up as well on 61400-15.

[stephenholleran]

In todays call it was discussed that maybe this should be a tool to calculate the classification.

We had a long discussion about how anemometers are classified with all the different type of yaw and inclined flow measurements required and how it is reliant on the type of terrain (A for flat, B for complex, C, D and S). Once an anemometer model goes through a classification process it is pretty much set in stone and so could be a reasonably stable look up table. The problem is that it is dependent on a terrain type calculation so the suggestion was made that this could be a tool that uses the data model as the data model already has the location needed for the terrain calculation and the anemometer model type. The attention then turned to; should we have an enum for anemometer models to allow the calculation of the classification? We ran out of time to conclude.

[kersting]

@stephenholleran I agree that moving towards a tool that is independent of the data model is the way to go. However, we still need to store the information about the classification in the data model. Given that a sensor can have multiple classifications (both from different standards and from different terrain complexities), we should have one property that associates the standard to the classification and then for the classification have multiple options.

[stephenholleran]

Resulting from our call https://github.com/IEA-Task-43/digital_wra_data_standard/issues/77#issuecomment-990046659

Actions:

• [ ] @heikowestermann to look into what info we want to store and how it can be structure.
• [x] @stephenholleran to add 'classification' to the schema.

[stephenholleran]

@heikowestermann @abohara @kersting @sdsmdp We had a good discussion today regarding this topic. https://github.com/IEA-Task-43/digital_wra_data_standard/issues/77#issuecomment-990046659

An enum is good but where do we store it; in the schema or some other json/db/csv? Because it is data it makes sense to have it outside the schema. There are only about 5 or 6 anemometers though. By having it separate from the schema would allow anemometer manufacturers to add in a new anemometer classification or update (with reviews). Avoids needing to release a new version of the schema each time it is updated. The schema would need an enum list of anemometer models (uuid/ids) which would then match the stored classification information. We would still need a place to put in the classification values into the implemented data model. Therefore we would need to add a 'classification' property to store the value e.g. 0.9A. 3.2B or 2.7S. Could use regex to validate. We went with the name 'classification' as it is not wrong however 'class index' or 'class number' might just refer to the number part. HW to look into what info regarding the classification and how to structure it. SH will add classification to the schema.

I have added a property classification to the sensor object. See below:

"classification": {
   "type": "string",
   "title": "Classification",
   "description": "The classification of a particular anemometer for this location. This combines the class index (number) with the terrain class (A, B, C, D or S) e.g. 1.2A. The format of this is validated by a regex which has the form of ^[0-9][.][0-9][ABCDS]$ i.e. digit.digit followed by a character.",
   "examples": [
      "0.9A",
      "3.2B",
      "2.7S"
    ],
   "pattern": "^[0-9][.][0-9][ABCDS]$"
}

This can hold the result of an automated tool to read the classification options for this anemometer, calculate the terrain class and then determine the classification for this anemometer at this location. It could also be typed in by the user.

I have put a regex on it so we can validate the pattern to prevent users typing it in incorrectly.

I haven't created a pull request yet as I would like to get some feedback first.

With regards to where the anemometer classification data should be stored HW is looking into it. By splitting that data from the schema allows us to release a version 1 before Christmas with just this classification as the classification data store could take a good bit of discussion.

Thanks.

[stephenholleran]

P.S. Do we need 2 decimal places?

[heikowestermann]

We have both in the wild (1 and 2 digits). To be flexible, I would suggest to allow arbitrary digits: [0-9][.][0-9]+[ABCDS]

[stephenholleran]

Instead of allowing lots of decimals we can limit to just 2. And allow 2 digits to the left of the decimal too. This ([0-9]{1,2})[.]([0-9]{1,2})[ABCDS] allows 10.95B, 1.2A, 10.3C, 2.45D but restricts 123.123X.

[stephenholleran]

Actions:

• [ ] @heikowestermann to look into what info we want to store and how it can be structure.
• [x] @stephenholleran to add 'classification' to the schema.

After this investigate the possibility of a tool to work out the classification.