Proj:RunPeriod* properties to support QuickSim feature

[GoogleCodeExporter]

The purpose of this issue is to outline the proposed changes to the SDD 
SIMULATION data model that will facilitate the QuickSim feature.
The QuickSim feature is a new option to allow users to simulate 4 separate run 
periods, typically one week each for each season of the year - in place of full 
8760 hour simulations.  This feature has been shown to produce results very 
close to full annual hourly simulations, but when activated will not allow 
users to produce a "submittable" compliance report.  A full annual simulation 
will still be needed to produce a valid compliance report.

Existing integer properties specifying simulation run period are all single 
integer values:  RunPeriodBeginMonth, RunPeriodBeginDay, RunPeriodEndMonth, 
RunPeriodEndDay and RunPeriodYear.

Proposed CHANGES --
Add a new integer property:  Proj:NumOfRunPeriods  (valid range 1-12)
Revise existing properties to be arrays of 12 integers:
    RunPeriodBeginMonth, RunPeriodBeginDay,
    RunPeriodEndMonth, RunPeriodEndDay
(RunPeriodYear will remain a single value)

Questions for NREL/OpenStudio:
- Any problems/incompatibilities anticipated with this approach of run periods 
defined via arrays of values?
- Any problems/incompatibilities anticipated in terms of storage and retrieval 
of hourly simulation results (for only the specified run periods)?

Original issue reported on code.google.com by scriswel...@gmail.com on 23 Oct 2014 at 5:22

[GoogleCodeExporter]

A few questions/comments:

- What is the purpose of the Proj:NumOfRunPeriods property?  Can't that be 
inferred from the length of the array(s), and therefore redundant?

- In the name of greatest flexibility, I suggest that RunPeriodYear also be an 
array of integers.  We can enforce this to be a single year in the rules, but 
there may be future applications where it will be desired to do simulations 
that cross or span multiple years.

- Is the intent of this for CBECC or OS translator to a) create a separate run 
jobs for each RunPeriod and perform these in parallel, or b) create one run job 
with four consecutive but temporally separate RunPeriods simulated in series?

I have not reviewed the QuickSim paper in detail, so I apologize if this 
question is answered there.

Original comment by da...@360-analytics.com on 23 Oct 2014 at 5:44

• Changed state: Discussion

[GoogleCodeExporter]

This is a feature that we can implement but will require some work.  David's 
questions are spot on, additionally we will need to know what results will be 
requested from each run (if they are done as parallel runs or as a single run 
over disjoint periods).

Original comment by dan.macu...@gmail.com on 23 Oct 2014 at 5:51

[GoogleCodeExporter]

Some responses to comment #1 (thanks Dave)

1) Purpose of NumOfRunPeriods is to specify precisely how many run periods are 
to be simulated.  Down the road when we support a Research mode and we provide 
more user access to these data, this property will help to ensure that OS 
doesn't interpret stale data entered in later array elements from being used in 
the simulation.
My vote would be to keep it, but it could certainly go.

2) Multiple run period years - This has raised lots of problem w/ DOE-2 due 
primarily to single-year weather data.  If multiple year run periods is 
something that OS & E+ can handle, then expanding run year to an array sounds 
good.

3) Good point - I hadn't been thinking outside the box on this one...
The principal objective here is reducing analysis runtime, so the questions are:
a) Can OS/E+ handle multiple disjoint (non-overlapping) run periods both in 
terms of simulation and hourly (& non-hourly) results storage?  and
b) Would 2 simulations (Prop & Std) each with 4 disjoint run periods (~1 week 
each plus warm-up) run faster than 8 simulations w/ single run periods - on a 2 
(or 4?) core machine?
Depending on these questions we could either support this feature via the 
proposed run period SDD mods OR compliance manager initiating multiple single 
run period simulations (which may require no SDD mods).

Original comment by scriswel...@gmail.com on 23 Oct 2014 at 6:19

[GoogleCodeExporter]

My feedback:

1) we dont want to support flags for what data in the SDD is stale or not, 
stale data should just not be in the SDD

2) I'm not sure how multiple years applies to this quicksim functionality?

3) OpenStudio can only handle one RunPeriod per model, this is an intentional 
restriction relative to what E+ can do.  We could add additional run periods 
after translation to IDF but this would be a new pattern.  The way OpenStudio 
did this functionality in the past was to run multiple jobs in parallel (we did 
this on a monthly basis so you ended up with full annual results), you do pay 
time to do duplicate warm up calculations but in our tests it made up the 
difference.  However this was model dependent and varies based on number of 
cores.  

Scott, if it is possible to prototype this and do some proof of concept testing 
without any SDD or OpenStudio modifications then maybe that is the best place 
to start?

Original comment by dan.macu...@gmail.com on 23 Oct 2014 at 6:51

[GoogleCodeExporter]

Sorry to muddle this effort with the thought of running multi-year simulations; 
it does not apply to QuickSim, rather just thought it might have ramifications 
on the data model updates.  It isn't a priority and ultimately it depends on 
the simulation approach, which still needs to be confirmed first.

Regarding the multiple parallel simulations, Dan, are your referring the OS 
ruby script "approach"?  Linda L. commented recently on EnergyPlus_Support that 
that didn't seem to have a significant speed advantage, particularly on Windows 
machines. Does NREL have past or current performance benchmark data that can be 
shared?

The E+ documentation indicates that you can specify more than one RunPeriod in 
a model, but I've never tried it. 

A quick skim of the QuickSim (!!) paper suggests they took the parallel 
simulation approach; has anyone talked to one of the authors about what they 
tried? 

Original comment by da...@360-analytics.com on 23 Oct 2014 at 9:16

[GoogleCodeExporter]

Before we get any further into the details - I would like clarification from 
Dan on the multiple run periods.
Is it not possible, or perhaps too large an effort to enable OpenStudio to 
perform single simulations w/ multiple run periods?

I got most of the way through writing this comment suggesting ways we could 
incorporate this logic in the compliance manager before encountering another 
concern - and that is the SDD to IDF translation.  This translation is not 
super quick and performing it four separate times in series will chew up much 
of the performance benefit of the shorter simulation run periods.
The translation of SDD to OSM is currently a serial process - not managed by 
the run manager - and we check/tweak the OSMs a bit in comp mgr source prior to 
saving the OSMs to be simulated (ensuring each surface's polygon vertices are 
in the order E+ expects).  Once we have the OSMs, we use the run manager to 
simulate the models in parallel. 
If we can't do the SDD -> OSM processing in parallel and if we don't modify 
OpenStudio to simulate multiple run periods, then it will be important at least 
to minimize the SDD to OSM translations.
Sorry ... thinking this through as I write ... perhaps we could do the SDD to 
OSM translation once, then save the OSMs to four separate files, each w/ a 
single, unique run period.  This could be done by manually adjusting the run 
period for each OSM before saving it.  Then simulate all four at once via run 
manager...

Original comment by scriswel...@gmail.com on 23 Oct 2014 at 9:44

[GoogleCodeExporter]

It would be a large effort to get OpenStudio to support multiple run periods 
within a single simulation, we made the decision to support a single run period 
per simulation to simplify the API and have made other API decisions based on 
the assumption of a single run period per simulation.

I think your last idea seems valid and at least a good thing to try before we 
get any fancier.  The other thing to try would be our existing parallel 
EnergyPlus simulation.  We do not exercise it in any of our applications but it 
is there and the unit test has been maintained:

https://github.com/NREL/OpenStudio/blob/develop/openstudiocore/src/runmanager/li
b/Test/ParallelEnergyPlusJob_GTest.cpp#L128

This job currently simulates an entire year broken into monthly run periods, 
the idea could be extended to simulate only four weeks later.

Original comment by dan.macu...@gmail.com on 24 Oct 2014 at 4:58

[GoogleCodeExporter]

Original comment by dan.macu...@gmail.com on 5 Nov 2014 at 10:49

[GoogleCodeExporter]

QuickSim converted to QuickAnalysis in final ver 3a release using week numbers 
resulting from analysis done by Roger/NORESCO.
Also activated for S901G analysis (using original week numbers from PNNL paper).
All changes made to compliance engine, which can now tweak the run periods of 
each run before writing final IDFs for simulation.

Original comment by scriswel...@gmail.com on 17 Nov 2014 at 5:12

• Changed state: DoneVerified