Francesco Casella

> Clearly, we need to introduce unit checking in the specification with some sort of transition in mind. @henrikt-ma I'm not at all sure about this. Personally, I don't think...

> If we are not aiming at formalizing unit checking in the specification, I don't see the point of MCP-0027. If all you care about is a tool-specific way of...

> I'm curious why you consider it a "false positive" if this proposal uncovers inconsistencies like equating an inductance and a time, but a "plain wrong" true positive when flagging...

> > I can't answer the resource question, but would that really be an argument to _not_ implement better checking ⁉️ Because doing it would point out too many errors...

> Thanks for that zip file, that is useful! I count/grepped 338 instances of incompatible units. It might be that there are some real false positives in that log, though....

I guess you mean "decrease" 😃

The division by zero is actually a division by false (whatever that means): ``` 2818 (assign) buiWitETS.bui.facMulHea := 0.0 / false ``` Unfortunately, there are no operations reported in the...

@perost, I tried to replicate the issue with the following MWE, which has a similar declaration structure, albeit flat. ```modelica model MWE parameter Real x = Buildings.DHC.Loads.BaseClasses.getPeakLoad( "#Peak space heating...

> By default the frontend evaluates function calls with only literal arguments OK, that makes sense. Maybe we should reconsider this if impure functions are involved, but given the current...

@phannebohm, @kabdelhak please consider the issue with `Buildings.DHC.Loads.Heating.Examples.BuildingTimeSeriesWithETS`, i.e., `buiWitETS.bui.facMulHea` being evaluated to `0.0 / false` by the backend during evaluateParameters. Unfortunately, I was not able to replicate the issue...