Overall Building(s) class construction - Now, it's called the model class
The initial inception of this class was from a discussion between @theochri @gbaasch and @GarrettTherrien . Our research led to the creation of a new class that helped us run models. The notes from this meeting can be found here below. This is now a massive refactoring of the code, because this model class is really simplifying lots of different bits that are scattered over many files.
After some work on the initial commit of a model class it helps to define better what is the function of each class and how it fits within the overall framework.
Model Class
This class will pertain to everything to setup, and run the model. To have this independent of the other issues it helps us out quite a lot. For example, the current commit model class for EP works like a EPLauncher which helps the research to explore the model before anythings else. - See below in a comment for more notes on what should be integrated.
Evaluator Class
This currently contains lots of bits of code to run models. This should all be removed and brought into the model class. The evaluator class will just be a bridge between the Problem+Model, and sampling+optimization methods.
Parameter Class
This class is going to help us setup parameters, selectors and descriptors.
Other Classes
These will be roughly unchanged.
Meeting notes
GT:
- General set of thoughts (data structure of a building)
- Which buildings have what?
- What kind of schedules ( single identifier, many different fields within the idf)
- What is the idf file path
- What archetype is it?
- heating and cooling schedules (list of)
- Dictionary of building objects to work with many buildings
- Manipulation stuff
- get my cooling schedules (from the idf)
- handling of post-processing
- generate an idf from a set of input parameters
- meta-data that is beside the building
T:
- idf/ewp/ file directory
- meta/output/
- demand -> monthly of
- Opening SQL -> push outputs
- This might be possible to replace the sql with csv, by improving the idf.
- Having the class allows for making your own methods on top of the existing class.
WB: Path's and meta data Running the building -> evaluator changing the building -> selector What is the overlap? - pre-(building class) and post(evaluator/selector) steps
GB: Lots of functionality is available already through the evaluator. SQL -> coefficients, saved data. keep_outputs=True (now, stores all the data) A method to maintain schedules and change schedules. possibility having a folder, with standardized buildings
GT: Save and load a building
Moving away from eppy?
- most of limitations are with the idf
- lost of the options available are described in eppy.
- regex - to search names
Action points (@will0 @theochri) is to make a graphics that shows how the building class would interact and improve the use cases of the besos repo.