Building Model QC / Mandatory Code Requirement checks - CHECKSIM & CHECKCODE

[GoogleCodeExporter]

Long in coming - a need to facilitate rule expressions to identify problems in 
a user's building model inputs that either prevent simulation of the building 
model or violate mandatory code requirements.
Proposed approach is to add two additional "reserved" rule expression labels - 
CHECKCODE and CHECKSIM (the first performing code checks and the second 
performing checks to ensure the model can be simulated).  These would be 
similar to the existing DEFAULT rule expressions, in that they do not define 
prescribed settings that get installed into a particular transform of the 
model.  CHECKCODE and CHECKSIM rule expressions will differ however from all 
other rule expressions, in that they are to be used exclusively for posting 
message, warnings or errors and NOT to modify building model data.

When a user first chooses to Perform Analysis, the DEFAULT rules will be 
evaluated on the input building model and then MAX/MIN range checks performed 
(w/ violations aborting analysis and reported to user).  Then the CHECKSIM 
rules will be evaluated.  If Errors are posted, the analysis will be aborted.  
Warnings or other messages will get logged accordingly and analysis will 
continue on to the CHECKCODE rules, with Errors aborting analysis and 
warnings/messages logged.

The rule evaluation mechanism is aware of the object and property being 
evaluated, so messages written into PostError(), etc. should NOT include that 
data.  The rule eval mechanism also has access to data specified in the 
REFERENCE portion of each rule block and that can be reported with the 
error/warning..., so I suggest we don't echo code or ACM sections numbers 
within error/warning messages, as that will make it more difficult to update 
rules following code/ACM section re-numbering.  Messages should be terse but 
also contain all information useful to users in identifying and fixing the 
problem.  This can be achieved by taking advantage of "printf-based" 
(C-language) string formatting features of the message posting routines, as 
described below.
Here are links to pages that explain 
  http://en.wikipedia.org/wiki/Printf_format_string
  http://www.cplusplus.com/reference/cstdio/printf/

Function calls that all support printf-based formatting:
  Format()  (simply formats and returns a string)
  PostError() / PostWarning() / PostMessageToLog()
  MessageBox()  (pops up a message box immediately upon evaluation - can be a useful debugging tool)
The return value from each of these functions is the resulting character 
string, but Post*() and MessageBox() are generally not used to modify a 
building model.

One important note - when plugging numeric data from a building model into a 
string via these routines, the data is ALWAYS a floating point value, even if 
the property being referenced is of type Integer.

Examples of PostError():
- PostError( "Unrecognized construction type '%s'", u:ConstructType )
- PostError( "Roof u-factor of %.3f exceeds code maximum %.3f",
              u:OverallUFactor, u:MaxUFactor )

----------------------------
Questions / Comments --
Any/all questions/comments are welcome, but areas I am particularly interested 
in hearing feedback on are:

a) whether you think the analysis sequence described above is the best approach.

b) whether there are additional "data setting" rule expressions that need to be 
evaluated on a model after defaulting but before sim or code checks in order to 
perform complete/valid checks on the input model.

c) suggestions on how the UI should communicate errors (and also perhaps 
warnings and/or messages) to the user resulting from these CHECK* rules.

Original issue reported on code.google.com by scriswel...@gmail.com on 17 Apr 2013 at 7:11

[GoogleCodeExporter]

Mods described in this issue implemented and (to be) checked in 4/23/13.

A couple of new INI file options, added to the [options] section and present in 
the INI file checked in to SVN:
- MaxNumErrorsReportedPerType=4    ; max number of errors reported in dialog 
during analysis (all errors still written to log file)
added to prevent too many errors to be reported in the dialog, causing dialog 
to exceed screen height.  Eventually to move to scrolling window.  All errors 
reported in project log file regardless of this setting.
- BypassInputChecks=1       ; bypasses range and required data check
added to disable input (numeric range and required data) checks 

Original comment by scriswel...@gmail.com on 24 Apr 2013 at 5:22

• Changed state: Fixed

[GoogleCodeExporter]

Hey Scott, 
After reviewing some rule updates you committed over the weekend, I noted 
something in your description above that I wanted to get clarification on:

"The rule evaluation mechanism is aware of the object and property being 
evaluated, so messages written into PostError(), etc. should NOT include that 
data."

Just to confirm, the Object:Property relevant to the CHECK rule is echoed in 
the log, but the 'Name' of the specific component in the data model in question 
is not echoed, right?  I didn't originally include Name since I thought it 
would be echoed by default, but I think I misunderstood what you indicated in 
your original post.  I'll make sure to add Name to the reported Error/Warning 
message from now on; let me know if I am wrong on the interpretation of the 
reporting.

Original comment by da...@360-analytics.com on 4 Sep 2013 at 5:38

[GoogleCodeExporter]

Apologies for lack of clarity re: inclusion of Name in messages.
I think in order to maximize readability it is best to INDEED include the 
object Name and any other data that would help the user to identify and fix the 
problem being reported.  Information such as the object name being evaluated is 
known as message is being echoed, but that data was not incorporated (in a 
clear/meaningful way) to the messages supplied back to calling applications 
(such as third party UIs).

Closing out this issue.

Original comment by scriswel...@gmail.com on 24 Sep 2013 at 5:29

• Changed state: DoneVerified