<html>

<font size=3>At 01:21 PM 3/11/2003 -0800, you wrote:<br>

<blockquote type=cite class=cite cite>Regarding the first comment from

Dave Robison, I've<br>

received the weather data in WYEC2 format from<br>

Environment Canada, including solar, wind, etc.<br>

However, the last time I had to do this was for a 1999<br>

weather year, and I understand that recent automation<br>

of the weather stations may make this data harder<br>

(impossible?) to come by. But without this data, how<br>

are you making the calibration?</blockquote><br>

</font>EZSim generates irradiation, humidity from ave temp. All on a

monthly basis, of course, where the correlation is good. It wouldn't be

possible on an hourly basis.<br><br>

<blockquote type=cite class=cite cite><font size=3>And although I've only

calibrated a few of these, not<br>

hundreds, I'm not sure I'd agree that the model<br>

doesn't need to be detailed and it's a low cost<br>

simulation. If you don't put a fair bit of work into<br>

making sure the simulation of systems is reasonably<br>

similar to the operation of them, then you're not<br>

calibrating, you're just matching the bills. And while<br>

your model might line up nicely with the bills, if<br>

your end-uses or hourly profiles are off its not going<br>

to be so useful for running further simulations on.<br>

</font></blockquote><br>

A moot point. If you have only 12 monthly points to match against, and

you do match well, then higher time resolution simulation is unnecessary

overkill. Why model to a level not supported by the metering data? <br>

If it lines up nicely, as you say, then it is good for simulations at the

monthly level. <br>

Calibration is matching the bills, but I think you are saying that you

want to be sure that you have correctly nailed the end uses as well.

Quite so. That comes from matching across a range of seasons. If you

match throughout the year, you have captured end uses pretty well. And

that's based on observations of many pre/post models where we have

billing data in both cases.<br><br>

<x-sigsep><p></x-sigsep>

<font size=3>====================<br>

David Robison<br>

Stellar Processes<br>

1033 SW Yamhill Suite 405<br>

Portland, OR 97205<br>

(503) 827-8336<br>

<a href="http://www.ezsim.com/" eudora="autourl">www.ezsim.com</a></font></html>