You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know that C-Factors and F-Factors are technically constructions but I think they would probably be better represented in the schema as their own type of boundary condition that gets added by honeybee-energy to the core set of boundary conditions. This way, there's still a "real" construction to fall back on if someone changes the boundary condition.
I am thinking that we can have a method that loops through the faces to find any ground boundary conditions and then tries to convert them to C or F factors by analyzing the geometry. So we would just expose this in Grasshopper as a component that takes a list of rooms or a model and converts "Ground to C/F-Factors".
I know that C-Factors and F-Factors are technically constructions but I think they would probably be better represented in the schema as their own type of boundary condition that gets added by honeybee-energy to the core set of boundary conditions. This way, there's still a "real" construction to fall back on if someone changes the boundary condition.
I am thinking that we can have a method that loops through the faces to find any ground boundary conditions and then tries to convert them to C or F factors by analyzing the geometry. So we would just expose this in Grasshopper as a component that takes a list of rooms or a model and converts "Ground to C/F-Factors".
More info here:
https://discourse.ladybug.tools/t/ashrae-90-1-f-factors-for-floors/14267/3
The text was updated successfully, but these errors were encountered: