Error evaluating rules - schedule assignments from RuleLibrary()

[GoogleCodeExporter]

Issue related to -- Rule Evaluation and Transform Initialization
Initially reported by Noah and confirmed by David.

The following rule was not correctly assigning schedules in the BASELINESIZING 
transform:
RULE Proj:Bldg:Story:Space:OccSchRef
  ...
  DEFAULT
    ...
  PROPOSED
    IF (LocalStatus(FuncSchGrp) < 2)
    THEN UNDEFINED
    ELSE RuleLibrary(Schedule,
            (SpaceFunctionGroups:OccSchRef("FuncGroup",u:FuncSchGrp)))
    ENDIF
  BASELINESIZING
    p:OccSchRef
  ...

The fact that this rule was not properly installing the schedule assignment has 
been fixed.  The rule evaluation log now includes the following message when 
the BASELINESIZING rule is evaluated:
...  'Wing2_Side1_Class1_Spc' Spc:OccSchRef -> SchoolOccupancy ...
      - Error: Unable to find object 'SchoolOccupancy' (DBID=17015001,...

The root of problem is this - when the BASELINESIZING rule is evaluated, the 
intent is to cause the assignment of a schedule imported into the PROPOSED 
model from the ruleset library (called 'SchoolOccupancy') - but this object 
does not exist in the BASELINESIZING model (without importing it again from the 
ruleset library).  This is (in part) because the starting point for each 
individual building transform is the USER model.  Once done analyzing the 
PROPOSED model (during processing), we make a copy of the USER model and begin 
evaluating the BASELINESIZING rules to convert it to a valid baseline sizing 
building description.  Setting data through referencing prior model values for 
decimal, string and enumeration properties is no problem, and copying 
references to objects is not a problem either, as long as an object by that 
name already exists in the later (baseline sizing) model. 

I think we should consider a change to how we initialize each transform.  I 
think (once we eliminate the proposed sizing model) that the PROPOSED model 
should begin as a copy of the USER model (as it does now), but that each 
subsequent model should start out as a copy of the final PROPOSED model.  Once 
the PROPOSED model has been finalized it includes lots of modifications needed 
in later transforms (such as schedules imported from the library) and I don't 
believe that any later transforms would benefit by any user inputs overridden 
when producing the PROPOSED model.  This change would prevent the above rule 
from needing to be modified - along with any other rule that imports objects 
from the library during analysis.  There is not much concern right now about 
rule evaluation speed for the various transformations (other than DEFAULT), but 
I think it would still be good to minimize redundant rule logic and evaluation 
cycles where it makes sense to do so - and this change would help reduce the 
weight of the ruleset.

If we opt to keep the existing transform initialization scheme (always starting 
with the USER model), then the fix for this rule would simply be to replicate 
the same rule logic in the BASELINESIZING and BASELINE transforms as that 
contained in the PROPOSED transform.

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

[GoogleCodeExporter]

This makes sense.

However I am confused why schedules assigned in the pz transform, and then 
referenced in subsequent transforms, seem to work fine.  I think the 
IntLtgSchRef is still an example that includes defining the schedule in the pz 
transform, and the p & bz schedules are being set.  Previously, when the other 
internal load schedules were set in the pz transform, I am nearly certain I 
reviewed the assignment in the ibd-detail files and OS models and confirmed 
they were there, but that was a few weeks ago and may have only relied on the 
rule logging.

Regarding the solutions, I think a copy of the p transform for subsequent 
transforms is a reasonable solution, since all of the neutral model data should 
be defined by this point in the analysis.

Original comment by da...@360-analytics.com on 11 Apr 2013 at 3:45

[GoogleCodeExporter]

Touched base with Jason and Roger on this topic this morning.
Everyone seems to be in agreement that enabling the BASELINESIZING and BASELINE 
transforms to be initialized with the final PROPOSED model was a good approach, 
so that will be added to my near-term to-do list.

A related change will be to revise the syntax of the TRANSFORMATIONS 
definitions in the main ruleset file to reference the model that documents what 
previous model is to be the source of the initial transform.  So what we have 
now as:
  PROPOSED p                 
        EXCLUDE u:Project:Holiday
  BASELINESIZING bz
        EXCLUDE u:Project:Holiday
        EXCLUDE u:Project:AirSystem
        EXCLUDE u:Project:FluidSystem
will become:
  PROPOSED p  from USER
        EXCLUDE u:Project:Holiday
  BASELINESIZING bz  from PROPOSED
        EXCLUDE u:Project:AirSystem
        EXCLUDE u:Project:FluidSystem

Original comment by scriswel...@gmail.com on 12 Apr 2013 at 6:54

• Changed state: Resolved

[GoogleCodeExporter]

Fixed in CBECC committed on/prior to 4/17 following change described above.

Original comment by scriswel...@gmail.com on 19 Apr 2013 at 3:55

• Changed state: Fixed

[GoogleCodeExporter]

Confirmed fixed in version 1b (454) - 9/25/13
Mods include use of "from ..." to determine which model is the starting point 
for each transform and also mods to parse and define the EXCLUDE statements 
(which were previously hard-coded).
Closing out issue.

Original comment by scriswel...@gmail.com on 26 Sep 2013 at 3:37

• Changed state: DoneVerified