SQL File: why are some parameters not present in ComponentSizes

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.

29.7k

Julien Marrec

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

4.4k

__AmirRoth__

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

edit flag offensive 0 remove flag close merge delete

Comments

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 (2016-02-16 11:20:22 -0500) 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 (2016-02-16 18:15:59 -0500) edit

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

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.

Kyle Benne

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

29.7k

Julien Marrec

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

edit flag offensive 0 remove flag delete link

Comments

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 (2016-02-17 11:31:22 -0500) 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 (2016-02-18 01:13:42 -0500) edit

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

Julien Marrec (2016-02-18 01:17:08 -0500) 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 (2016-02-18 03:20:08 -0500) edit