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

SQL File: why are some parameters not present in ComponentSizes

asked 2016-02-16 10:54:00 -0600

updated 2017-06-07 12:02:58 -0600

I've got a fully autosized model and I'm looking at the outputs.

For a pump, ComponentSizes has Rated Flow Rate (m3/s) and Rated Power Consumption (W) which makes a ton of sense to me.

For a fan, either one of Fan:ConstantVolume, Fan:VariableVolume or Fan:OnOff, there's only Design Size Maximum Flow Rate (m3/s). Why isn't the Rated Power not present in the ComponentSizes table? Am I missing something or some logic?

Note that this data (and more) is present in the TabularDataWithStrings for ReportName = 'Equipment Summary' (that ends up in the HTML output), but I'd rather avoid grepping values from multiple locations and I don't understand the logic behind it.

edit retag flag offensive close merge delete


I think I actually now understand why it's not in ComponentSizes.

For the Fan, the parameter that is really autosized is the flow rate. The Rated Fan Power is then calculated directly from this flow rate and from the mandatory inputs that are Fan Total Efficiency and Pressure Rise (Pa).

I'd postulate it'd still make sense to put it in the ComponentSizes

Julien Marrec gravatar imageJulien Marrec ( 2016-02-16 11:20:22 -0600 )edit

As my understanding, the component sizing means they are part of loops (air or water) and component sizing takes input from sizing:zone,sizing system or sizing:plant object. We get the rated capacity and flow from sizing component, but to get rated power(electrical) and their nominal (standard condtion) characteristics, you need more detail in each equipment object properties and it will show on equipment sizing summary. Best eample is Coil DX (often we need to understand as a packaged consists of DX coil + compressor + condenser includes fan). VRF doesn't show there

ngkhanh gravatar imagengkhanh ( 2016-02-16 18:15:59 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-02-17 10:54:19 -0600

updated 2016-02-18 01:15:44 -0600

General comment about the E+ component sizes table here. That sqlite output feature in E+ was originally contributed by a volunteer third party developer. The ComponentSizes table was introduced in the original design, but to my knowledge it has not been kept up to date as new components and features have been introduced to E+.

As time progressed the OpenStudio team (probably before we were known as OpenStudio) recognized the value of the database output for our purposes, but we considered the ComponentSizes impractical to maintain when EnergyPlus developers (especially @JasonGlazer) were already committed to maintaining the tabular data we are all accustomed to viewing in html format.

In order to leverage the existing and ongoing effort in tabular output and gain access to the entire E+ output through the database, I introduced TabularDataWithStrings which tapped into the existing code to write tables in E+. This means that anything written to html automatically shows up in sqlite. This generic approach may not be as elegant from a database design point of view, but it seems like a good tradeoff for gaining the entirety of E+ tabular output.

edit flag offensive delete link more


Yes, there are other summary tables that are better to use. For this example the "Equipment Summary" table called "Fans" has the design power rate.

Archmage gravatar imageArchmage ( 2016-02-17 11:31:22 -0600 )edit

Yep I did find it in the TabularDataWithStrings as I said in my post. I was just getting confused about why I couldn't find this info in componentsizes. The openstudio-standards has been leveraging ComponentSizes until now...

Julien Marrec gravatar imageJulien Marrec ( 2016-02-18 01:13:42 -0600 )edit

(I took the liberty of adding a bit of formatting to your post, it felt too dense)

Julien Marrec gravatar imageJulien Marrec ( 2016-02-18 01:17:08 -0600 )edit

Shouldn't we clean that up? If there is no information in ComponentSizes that cannot be found somewhere else, and given the fact that ComponentSizes is actually a TABLE (and NOT a VIEW), it's just a dead weight on the overall size of the SQL file. (I know that's not ComponentSizes that's leading to 1 to 10 GB SQL files but the hourly/timestep reports, but still)

Julien Marrec gravatar imageJulien Marrec ( 2016-02-18 03:20:08 -0600 )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

1 follower


Asked: 2016-02-16 10:54:00 -0600

Seen: 117 times

Last updated: Feb 18 '16