Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page
Ask Your Question
6

Calibration AMY-v-TMY more than 1 year

asked 2015-02-01 12:50:47 -0500

MattStewart gravatar image

updated 2015-07-11 13:43:03 -0500

I have an existing building which I am modeling with OS V1.6. I have deployed the Calibration Reports measure and am using an EPW weather file purchased that is based on the Actual Meteorological Year (AMY for both 2013 & 2014).
It appears that Open Studio will only accept a single year of data in the .epw file.

Is there a way to get 2 years of simulation output to enable 2 years worth of calibration results in a single run. I suppose one answer is to just run the model twice using just a single year.

Error when combining: When I tried to combine 2013 & 2014 this is my error: [openstudio.EpwFile] <1> Wrap around years not supported for TMY data, /files/SPtMasterTable575532201314amy.epw' cannot be processed.

Thank you, Matt

edit retag flag offensive close merge delete

Comments

@MattStewart: have you tried running EnergyPlus with that weather file? Use one of the example file, and supply your epw to it. It'll tell us whether your file is the problem or if it's OpenStudio related. (Side note: I'm sure you know that but if you really want to do it for more that one year, make sure you have a multiple of (typically) 12 months so that you capture full cycles of conditions, otherwise if doing it for example for two summers and one winter you'd end up overweighting, in the calibration, the cooling component relative to the heating one)

Julien Marrec gravatar image Julien Marrec  ( 2015-02-02 02:35:54 -0500 )edit

(Because it does work in E+. This recent thread on the E+ Support group should be of interest)

Julien Marrec gravatar image Julien Marrec  ( 2015-02-02 11:01:14 -0500 )edit

Excellent! Thank you for sharing. Seems not many people utilize E+ or OS for doing Energy Performance on existing buildings. Otherwise calibration would be built in feature. This gives me a new dimension to explore as related to visualizing the building's actual performance as modeled using actual utility and weather data. Critical for estimating savings from applying measures. Thank you, Matt

MattStewart gravatar image MattStewart  ( 2015-02-02 12:08:40 -0500 )edit

@MattStewart, we do have the ability to load utility bills into OpenStudio and to compare against modeled results.

We don’t currently support run periods of more than 12 months. I think we do support a wrap around run period (6/1 through 5/31) but a 1/1 through 12/31 weather file might still be necessary?

David Goldwasser gravatar image David Goldwasser  ( 2015-02-02 12:44:20 -0500 )edit

There are some simulation programs that only accept weather files starting from Jan 1 through Dec 31. In those cases, to do an annual simulation that starts in the middle of the year, I just create a composite weather file that goes 1/1 to end date of the 2nd year, followed by the begin date to 12/31 of the 1st year. Sounds a little screwy, but it works fine. Doing multi-year simulations is a separate matter. What's wrong with just doing multiple runs switching the weather files ?

Joe Huang gravatar image Joe Huang  ( 2015-02-04 12:43:26 -0500 )edit

2 Answers

Sort by » oldest newest most voted
3

answered 2015-02-03 03:21:48 -0500

updated 2015-02-03 08:59:41 -0500

Openstudio currently does not support run periods of more than 12 months (credit: @David Goldwasser )

Using multiple years works fine in EnergyPlus. This recent thread on the E+ Support group should be of interest. It states that the trick is just to copy-paste values in the epw file spaning more than one year.

A few things:

  • If you really want to calibrate over more than one year, make sure you have a multiple of (typically) 12 months so that you capture full cycles of conditions. Otherwise, if doing it for example for two summers and one winter you'd end up over-weighting, in the calibration, the cooling component relative to the heating one
  • I suggest using only one year for the calibration.
  • Using two years will complicate the process, and you're more likely to have a number of factors in there that you can't explain: over two years the parameters that define a building are more likely to have changed, whether it be its envelope, something on the HVAC side that broke, or a change in occupancy/vacancy...
  • Do the calibration on one year, and once satisfied, use the second year as a test sample to validate your model.
  • This will potentially have another advantage for you right now in the sense that you'll be able to stay in OpenStudio, which does allow you to import utility bills and calculates metrics such as the Coefficient of Variation of the Root Mean Square Error, CV(RMSE).

Also:

  • If you are feeling adventurous, I suggest looking into using an optimization tool such as GenOpt to minimize the CV(RMSE) by varying parameters you define (anything hard to quantify such as Air Changes per Hour, etc). The second link below should help.

Previous questions on Unmet Hours that should be of interest:

For example, I have briefly used ExcalibBEM - a GUI for the optimization tool GenOpt - and it really poked my interest for calibrating existing buildings and I definitely intend to dig further.

edit flag offensive delete link more

Comments

There are a few situations for multiple or broken years files:

  • With monthly utility bills you only get 12 observations per year. Then, two years with 24 observation allows for a better calibration (assuming, defining parameters don't drift).
  • Often you need the most recent data -> broken year files
  • The calibration period need to have a good distribution of weather conditions. Which the last full year not necessary have. Especially for calibrating peak heating/cooling, which in case of peak components in the energy pricing are defining your cost savings in retrofit projects
Lukas gravatar image Lukas  ( 2017-07-18 02:14:33 -0500 )edit
4

answered 2015-02-02 10:54:40 -0500

So, EnergyPlus can handle multiple year weather files. To test, I took two existing weather files, and simply pasted the data from one to the end of the other. This essentially made a 2 year weather file. The first year was from somewhere very cold, and the second Miami. Anyway, I then took an example file and in the run period object, I told it to repeat the run period 2 times. It ran for 2 years. After running it, I reported the outdoor dry bulb:

image description

So EnergyPlus is fine. There may be solid reasons why OpenStudio did not allow this previously, I will only comment on the E+ side.

edit flag offensive delete link more

Comments

2

@Edwin The E+ sql output does not include the year which was one of the main reasons we did not support multiple year runs in the first round

https://github.com/NREL/OpenStudio/is...

macumber gravatar image macumber  ( 2015-02-03 10:47:08 -0500 )edit

That's very interesting. Have you reported this "issue" to the E+ helpdesk?

Julien Marrec gravatar image Julien Marrec  ( 2015-02-03 13:07:45 -0500 )edit
1

For that run, E+ just reported 2015 in the timestamps throughout both years. It wouldn't be a huge amount of work to add that as a new feature, we'd probably want to add a new field to the RunPeriod object to allow the user to specify the "starting year" much like how the user can already specify the "starting day of week". Then the year would get incremented on the next repeat of the run period. I'll put this in my notes for future feature enhancements as it has a pretty high value to cost ratio.

Edwin gravatar image Edwin  ( 2015-02-03 16:07:28 -0500 )edit

Sorry, I was wrong there. It appeared as 2015, but that was the spreadsheet program picking up the date format and deciding 2015, not E+. In the raw csv data it doesn't have the 2015 listed anywhere; nor in the eso output. I think EnergyPlus is year-agnostic and thus it would be more effort to actually add this to the outputs and thus change the output schemas. Still something to consider though.

Edwin gravatar image Edwin  ( 2015-02-03 16:33:03 -0500 )edit

RunPeriod has 'Start Year' and RunPeriod:CustomRange has 'Begin Year' and 'End Year', I don't think those show up in the sql file though. In my humble opinion, every simulation should have a real year as most software libraries that deal with time do not have facilities to deal with fake dates. OpenStudio looks at the properties of the year you want (e.g. starts on a Monday, has a leap year) then searches for the real year that matches your needs. If you pick a real year then you can't set the start day or if it is a leap year.

macumber gravatar image macumber  ( 2015-02-03 16:55:20 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

 

Question Tools

2 followers

Stats

Asked: 2015-02-01 12:50:47 -0500

Seen: 436 times

Last updated: Feb 03 '15