search

JasonGlazer / createRulesetProjectDescription

Create RMD file based on open229 schema from EnergyPlus output and input files
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

Add method to merge compliance parameters #14

Open JasonGlazer opened 1 year ago

JasonGlazer commented 1 year ago

Compliance parameters are those that cannot be determined by the simulation input or output and instead need to be provided by the modeler as they are interpreting the design. These parameters should be organized so they can be merged into the RMD file that is produced by the script.

They might make sense to have as a YAML file or in a file similar to an IDF file or epJSON file so that IDF Editor or epjson Editor can be used to produce them.

An alternative is to include additional "compliance" objects in the IDD schema so that they can be directly entered by the users in the same file. If this route is taken, an additional report of compliance parameters would need to be generated.

JasonGlazer commented 8 months ago

Options for compliance parameters:

  1. Add new fields to existing input objects associated with them and create or add to tabular report that echos them out
  2. Add new fields to existing input objects associated with them and parse the epJSON files to get them
  3. Add new Compliance input objects like existing Compliance:Building and report them in tabular reports
  4. Add new Compliance input objects like existing Compliance:Building and parse the epJSON to get them (essentially ignore these inputs by EnergyPlus like HVACTemplate objects are ignored). A preprocessor would need to delete them.
  5. Add new generic tag object (https://github.com/NREL/EnergyPlus/issues/8775) to associate new key-value pairs for compliance parameters and create a tabular report that echos them out
  6. Create a JSON file that contains the compliance parameters but the layout would need to match the layout of the RMD file so that it could be merged. Use createRMD to make an empty file to make it easier for user to populate and would be different for each EnergyPlus input file. GUI developers would probably not need the created empty files.
  7. Create a YAML file that contains the compliance parameters but the layout would need to match the layout of the RMD file so that it could be merged. Use createRMD to make an empty file to make it easier for user to populate and would be different for each EnergyPlus input file. GUI developers would probably not need the created empty files.
  8. Create a JSON patch file (https://jsonpatch.com/) containing the compliance parameters and values. Use createRMD to make an empty file to make it easier for user to populate and would be different for each EnergyPlus input file.
  9. Create a separate IDD for the compliance parameters and users can create a special IDF that just contains them that can be read. Keeping both files synchronized would be difficult.

For many of these the factor of being able to use IDF Editor (or eventually the epJSON Editor) or simply add and manipulate an IDF file using current workflows is important. For GUIs they would probably also prefer to simply generate an IDF or epJSON file directly that contains everything since the GUI would also now need new entry fields for users to populate.

Options 1 to 5 are all keeping the information together in a single IDF or epJSON file and would probably be easiest for the user or GUI developer.

Options 6 to 8 may be easier to program but more difficult for users and developers. If no creation of empty compliance parameter file is done, they are definitely the easiest approach.

For now I think I will use option 8 without the empty file creation. Options 2 and 4 can always create a JSON patch file as part of the preprocessor. Option 8 is the easiest option in the short term to implement.