I am having to enter F-Factors for floors for a recent ASHRAE 90.1 Appendix-G project, and I’m wondering if anyone has a nice process / workaround for getting those into an LBT model? Am I correct that there is not a standard input LBT component to create / assign those? I could not find one, but maybe I just missed it?
I ended up hacking something together to create, then add the text for the F-Factors to the OSM file directly, then re-running it. I suppose that works ok - but seems less than ideal? I wonder if anyone has found a better / simpler way?
Or have folks found a work-around to avoid having to use F- and C- factors for 90.1 App G compliance? Seems as though that standard is really instant on using those factors instead of U-Values?
Note that I had to add the text to the OSM myself, as when I added it to the IDF in ‘ModelToOSM’ (add_str_) it didn’t make it through into the OSM? The custom text made it into the IDF, but somewhere got dropped by the time it got to the OSM?
Similarly, I couldn’t add any custom text to the ‘RunOSM’ component without getting an error for some reason?
Good question. The _add_str_ input is only intended to add additional IDF strings and so it won’t work to add additional text to the OSM. The idea is that you could use the _measures_ input to edit the OSM if the OpenStudio SDK is your preferred way of editing the model.
Frankly, I didn’t know that a workflow like what you have there was possible with just OSM text since I didn’t realize that everything could work out smoothly with the OSM handles. Are you using the OpenStudio SDK C# bindings in your custom component there? Or are you just generating the handles yourself?
In any event, I don’t know if 90.1 Appendix G is inherently that strict about F- and C- factors. I know that the most important thing that App G emphasizes is that you should use the same simulation methods for both the baseline and the proposed models. But I really don’t think a reviewer should fault someone for using a more accurate simulation method, particularly if you are using a more robust set of ground heat transfer assumptions instead of F-factors. What version of ASHRAE 90.1 are you following? I know that it’s partly because of ambiguities like this that ASHRAE 90.1 2019 decided to make the new Appendix G reference the 2004 criteria and just take a percentage reduction from that. It seems that the criteria were getting really complex in 2016.
Ah - gotcha, that makes sense on the _add_str. Not a problem. Regarding the ‘handles’ - suppose maybe I might have caused some possible issues without knowing it?
The OSM handles appeared to me to be just uuid.uuid4 items, so I tried using that format to create the text blocks, and it seemed to all work just fine so far (famous last words, I know). Though I could be totally wrong and maybe someday it’ll all cause a problem. I could not find any documentation that specified the format for the ‘handles’ - so was just trial and error. So far so good though, for whatever thats worth.
But yeah: for the 90.1 AppG part: I’m all very new to that modeling standard - so I could be totally wrong on that. But it appears to me that it states pretty clearly that we ‘have’ to use those F-Factors? In Section G3.1 (using their online access thing, 2016 version I believe) where it outlines the ‘proposed’ vs. ‘baseline’ model structure, it seems to say:
So I don’t really know, but just reading the text there is seems to me that there isn’t any option other than using those F-Factors? Again: if anyone knows a work around, I’d be all for it - the F-Factor thing seems really less than ideal? I’ll look into the 2019 version though as you say - perhaps things have changed in that new version. This particular model is for NJ which is still on 2016 though.
Sorry for the late reply. What you did with the handles might actually be ok for this case but aren’t these new F-factor constructions meant to be referenced by the surfaces of the model? So you need to update the handles of the construction property of the surfaces in order to reference the F-factor constructions, right?
In any case, ASHRAE 2016 was the peak of complexity for Appendix G modeling so I do not envy your position. But I also see that the F-factors are in the envelope tables as far back as ASHARAE 90.1 2004 so this might not actually change the situation at hand.
We should probably just add support for F-factors as a possible boundary condition object in Honeybee. I think we can also probably figure out the perimeter exposed to the outdoors automatically. I opened an issue for it here and I will try to get to it at some point:
ha - thanks @chris , appreciate that. Yeah, its been quite a challenge to try and learn all that bananas stuff in there. A good learning opportunity, but whoa its a lot…
Either way: For the F-Factors: yes that seems right - I need to update the right ground-contact surfaces with the right ‘handle’ and reference to the right F-Factor construction, as well as change the BC of that surface to “GroundFCfactorMethod”. The method I’m using at the moment is ugly and makes a lot of assumptions about the format of the OSM, but works roughly like this:
Create a simple F-Factor class to handle the txt-block-formatting, params, etc…
Go through the HB-Rooms, find the ground-contact surfaces, and create ‘real’ individual F-Factors for each surface, using the surface’s area and perim (doesn’t do ‘exposed’ perim properly just yet…)
At the end, after the original OSM is made (with no F-Factors), read it back in, find those surfaces, change their attributes, add in the new F-Factors, write it all out to a new OSM, re-run the OSM.
So far so good. The last part makes a lot of assumptions about the format / order / structure of the OSM file in order to find the right text blocks / rows, so might not be generalizable outside HB workflow here. But it’s working well enough for me right now at least.
I’ve attached an example with the code blocks if it is helpful at all.
best, @edpmay
Thanks for sharing, @edpmay . If you end up implementing something that automatically gets the exposed perimeter and depth (mostly) correct, we can reuse that part when I eventually add the C and F factors to the core libraries.
Please let us know when and if this gets integrated.