search

NTNU-IndEcol / BuildME

6 stars 1 forks source link

IDF converter for BuildME #52

Open shnkn opened 2 years ago

shnkn commented 2 years ago

Hello @nheeren,

After our discussion with @kamilitsa, I attempted to write some functions to automate the IDF conversion process for BuildME. At first, we were not really sure whether it is viable to write a code to convert objects as the naming and structure can be very different between IDF files. However, surprisingly there are some patterns that can be controlled with functions.

In total, there are three functions that should be used one and after. The tool needs to be fed with 3 input files: image -Standard IDF, uses 2006 values -Efficient IDF, uses 2012 values -ZEB IDF, uses 2018 values

The functions take these IDFs, places "replaceme" string, update materials/constructions accordingly, create non-standard IDF, and finally, merge them into one single archetype file that is compatible with BuildME.

I tested the code with all of the new archetypes, and it works! I did not spot any bugs for now. I tried to make the code as generic as specific, however, there are some places that can be improved (i.e., generic pathnames). Maybe @anistad or @kamilitsa can help me to improve those parts. Similar to IdealLoads Converter, there could be many simulation parameter combinations defined by users, it is not possible to address them here, but it can easily be adapted to every IDF file.

Such a tool development was pretty crucial for me because converting the Middle Eastern ones manually took too much time.

Here I am sharing the files except for the documentation which I did not have the time to write. Code: https://github.com/nheeren/BuildME/blob/master/BuildME/Idf_converter.py Files: Converted_IDFs.zip

Some more tasks, based on today's discussion:

shnkn commented 2 years ago

The script is applied to the archetypes and uploaded here: https://github.com/nheeren/BuildME/tree/master/data/archetype/new_archetypes/ConvertedBuildMEFiles I will update this folder after I run the script for "OfficeLarge.idf".

Where can I find the energy standards for the material-specific archetypes (i.e., SFH-masonry?)

shnkn commented 2 years ago

Hello @nheeren,

I was planning to improve the IDF converter's capabilities by also automating the update of "replace.xlsx", "material.xlsx" files and "odym_materials = {}" list located at the "setting.py". That odym_materials list should be updated to contain all the newly added materials, no mass materials, and this list should be saved in the source code.

There will be no problems with updating the excel files, however, updating the hardcoded list "odym_materials" in settings.py is very cumbersome because it requires direct manipulation on the source code level. Also it is not very practical to have a hardcoded odym material list in the code itself, for example, I added additional 70 materials to the list for Saudi Arabian archetypes.

What I suggest is that we should have another tab on the material.xlsx that stores idf materials and their corresponding odym-materials equivalents. And we can automatically update that list when we convert a new IDF file. However, in either way user needs to manually write whether the IDF material corresponds to either "other", "concrete", "cement" etc. in odym materials. If you would approve this change, I am going to establish the conversion process based on this direction.

kamilakrych commented 2 years ago

I support the idea to move "odym_materials" to somewhere else. However, also in line with another issue (#40 move away from excel), I would suggest to use sth else, not excel. How about a json file or another text-based format?

shnkn commented 2 years ago

Thanks, @kamilitsa! Niko suggested using CSV files. What do you think about it?

kamilakrych commented 2 years ago

Yeah sure :) I just didn't know that csv files are different from xlsx files in this regard. But it seems they are, so go for it!

CBreton026 commented 2 years ago

I was just going to say that Niko mentioned lowering the barrier to entry for BuildMe in #40. CSV files are easy to modify / read / visualize using tools most people are comfortable with. Since the data to be stored isn't too complex, I also agree CSVs sound good!

nheeren commented 2 years ago

Thank you all for committing brainpower at this 😊

Actually I suspect that I was thinking of YAML when I wrote JSON (sorry). I am fine with either YAML or CSV. I would argue that the former is supposed to be a bit more human readable and the latter more for interoperability and larger amounts of data. Therefore my preference would be with YAML:

YAML

$ import yaml
$ print(yaml.dump(fallback_mat.to_dict('index')))

Air_4_in_vert:
  comment: 4 inch = 10 cm
  conductivity: 0.63
  density: 1.2
  thickness: 0.1
Bldg_paper_felt:
  comment: Data from Lesosai 2019 for "Dampfbremse Kraftpapier"
  conductivity: 0.2
  density: 575.0
  thickness: 0.00013

CSV

ep_name,density,thickness,conductivity,comment
Air_4_in_vert,1.2,0.1,0.63,4 inch = 10 cm
Bldg_paper_felt,575.0,0.00013,0.2,"Data from Lesosai 2019 for ""Dampfbremse Kraftpapier"""

However, I am against saving things into the source code as you mention. Let us rather use user-specific files that do not become part of the git. That means there could be a material_categories.yaml and a material_categories-user.yaml. Your script should only write to or create the latter.

nheeren commented 2 years ago

Just to make sure: This kind of development should happen on a separate branch and not on master, because it may impact other ongoing developments.

nheeren commented 2 years ago

Here is what I am doing to make OfficeM.idf work:

shnkn commented 2 years ago

Okay, finally I finished the app/script and its documentation. I committed the new tools to the Kamila_changes branch.

1 parent 0982046 commit 857694a4a32fd24ca81b451086b82d3a32b1fd04