Allow default value for rollup analysis

This seems like a recipe for a lot of data confusion. Like if it's event-triggered with no data, you would still want a default value written? Wouldn't that effectively be just replacing the error value like Calc Failed with a #? All users would think of it as the sam, and if the value is valid, how would you know? It seems like the underlying idea would be to be able to better account for error handling? Not sure what form that would take, but something that would likely happen before a data write.

Some sort of error handling is definitely needed for this scenario. Currently it's hard to separate rollup analysis errors when attributes can't be found from legitimate rollup analysis errors. At a minimum, there should be a way to ignore/hide this error, but it would be better if rollup analysis was able to use a default value or just gracefully skip over attributes that don't exist.

In response to Hahnming Lee, "This seems like a recipe for a lot of da..." The use-case is having a Rollup Analysis defined on an Element Template, but some element instances may be childless and it messes with other rollups.  E.g. a rollup analysis may be wanting to do a count on an element from among it's child elements, and that first rolled up value feeds into its parent's rollup.  If the first element has no child elements, its count should be 0 instead of throwing errors that are propagated up to the parent element's rollup.

In response to Rick Davin, "The use-case is having a Rollup Analysis..." Exactly. This can also cause problems when the AF hierarchy changes over time. If at one time a parent had child elements, then the rollup analysis on the parent element could have value X. Then, if the AF hierarchy is changed so that the parent element no longer has child elements, the rollup analysis will fail, and the attribute value on that parent element will be stuck at value X forever. If the attribute values on the parent elements are used as inputs to rollups further up the hierarchy, this can really corrupt your data.   I have this exact situation currently as my AF hierarchy changes every week, and I have to run custom scripts to detect rollup analysis in a failed state but with an output that has "good" quality. I have to get a list of the PI tags for those outputs and reset their values using piconfig.

We have the exact problem mentioned by Rick Davin, we try to do a rollup of a summary counting the number of children elements, but when there's no element it gives us Calc Error instead of 0. In this regard, I think this should be considered a bug because if I'm counting and there's no child, the answer should be 0 instead of Calc Failed. I understand that probably for Average or other calculations an error is more appropriated, but for Count it does not make sense.

Hi guys, I totally adhere with the fact that a default value is required, or at least when criteria is not satisfied for a Count it doesn't go to an error (eg with no child items). This is a real lack on AF capabilities, just like the fact that we can't add a criteria to a rollup such as Type='xxxx'. Any SQL query is able to handle this.

We have a similar situation but with Average rollups that propagate up the hierarchy: Many of the original rollups have no matching child elements and so report 'Calc Failed' when really a 'No Data' digital state would be more appropriate This behaviour should then also propagate up to the parent rollups: children with 'No Data' values should be excluded by the Average calculation and if that means it finds no valid values to roll-up then the result should again be 'No Data'.