OpenStudio:model
Loading...
Searching...
No Matches
Todo List
page OpenStudio Model

The OpenStudio development team is currently in the process of fully implementing these coding standards.

Streamline the Idf and Workspace-level ExtensibleGroup interface and port any applicable changes over to Model.

Implement autosize/autocalculate getters and setters.

Return OptionalString() for unset choice fields (rather than empty strings)?

Return OptionalString() for unset string fields (rather than empty strings)?

Class openstudio::model::ClimateZones
Provide methods for setting the ClimateZones for a model based on the data in Site and/or WeatherFile, and for checking whether the ClimateZones object is consistent with the geospatial location(s) called out in Site and/or WeatherFile.
Class openstudio::model::ComponentCostAdjustments
The IDD object "OS:ComponentCost:Adjustments" should be marked as unique
Member openstudio::model::Facility::economicsCapitalCost () const

: only ComponentCost_LineItem of line item type "Construction" are currently handled

: this should not require life cycle parameters to calculate

Member openstudio::model::LayeredConstruction::layersAreValid (const std::vector< Material > &materials)
Verify that this is a comprehensive and accurate list.
Member openstudio::model::Model::getModelObject (const Handle &handle) const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getModelObject<Zone>(handle) the user must include both Zone.hpp and Zone_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getModelObjectByName (const std::string &name) const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getModelObjectsByName<Zone>("Zone1") the user must include both Zone.hpp and Zone_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getModelObjects (bool sorted=false) const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getModelObjects<Zone>(), the user must include both Zone.hpp and Zone_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getModelObjects (const std::vector< openstudio::Handle > &handles) const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getModelObjects<Zone>(handles) the user must include both Zone.hpp and Zone_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getModelObjectsByName (const std::string &name, bool exactMatch=true) const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getModelObjectsByName<Zone>("Zone1") the user must include both Zone.hpp and Zone_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getOptionalUniqueModelObject () const
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getOptionalUniqueModelObject<Facility>() the user must include both Facility.hpp and Facility_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Member openstudio::model::Model::getUniqueModelObject ()
Use of this template method requires knowledge of the size of the implementation object. Therefore, to use model.getUniqueModelObject<Facility>() the user must include both Facility.hpp and Facility_Impl.hpp. It may be better to instantiate each version of this template method to avoid exposing the implementation objects, this is an open question.
Class openstudio::model::ParentObject
It is an open question if the functionality of ParentObject should be merged with ModelObject and ParentObject deprecated.
Class openstudio::model::PlanarSurface
There is too much functionality in this class that is not common to all derived classes. These members need to be factored out of PlanarSurface.