Hi everyone, I’m trying to run an urban energy simulation, however after I run URBANopt and try and input the sql data to the HB End Use Intensity component, I get an error saying “1. Solution exception:Failed to find the “Building Area” table in the .sql file.”
I’m not quite sure how to solve this. When I do the same with the HB Read HVAC sizing or HB Read Room Energy Result, there seems to be no error, so I’m not sure what the issue is or how to fix it. Wondering if anyone could help? Thanks in advance!
Did the simulation actually run to completion? Do you see eplusout.htm files in the simulation sub-folders of the URBANopt project folder? If so, is there a Building Area table within the HTML?
Hey @chris , I’m not entirely sure what I did, but I managed to get it working. I think it’s because I was previously getting an error saying that it couldn’t find design days in the ddy file, so I used the EPWtoDDY component to obtain design days, and ended up only plugging that in as the epw file to the RunURBANopt component. I believe when I reconnected the epw file as well, the simulation managed to run. Thanks for getting back to me though!
** Severe ** RoofCeiling:Detailed=“FLR2_RESIDENTIAL_5_48E79620_CEILING_PLENUM…FACE0”, Vertex size mismatch between base surface :FLR2_RESIDENTIAL_5_48E79620_CEILING_PLENUM…FACE0 and outside boundary surface: FLR2_RESIDENTIAL_5_48E79620…FACE8
** ~~~ ** The vertex sizes are 6 for base surface and 7 for outside boundary surface. Please check inputs.
The simulation is obviously not completing, but I cannot figure out why.
You’re right that the EnergyPlus simulation is failing and the error that you’re getting is something that you should not encounter with a valid dragonfly model. Have you tried making sure that your Dragonfly model is valid with the DF Validate Model component?
If your are sure that your Rhino model units system is correct, the “DF Validate Model” component tells you that your model valid, and you confirm that you’re using the latest version of the LBT Grasshopper plugin, then I’ll take a look and fix it if you upload a minimal Grasshopper sample file that recreates the issue.
It seems like this may be a bug related to the auto-generation of ceiling plenums that dragonfly does.
Please note that I used a floorplan to create my DF model. I used DF validate, and it lists the following issue:
The following Buildings have overlaps in their Room2D geometry:
KingLinwoodMURB
Room2D “Stairs_9” overlaps with Room2D “Stairs_11” more than the tolerance (0.01) on Story “Office”.
KingLinwoodMURB
Room2D “Top_Stairs_9” overlaps with Room2D “Top_Stairs_11” more than the tolerance (0.01) on Story “Top_Office”.
When I remove all the stairs from the model, the model is able to be validated. This would indicate an issue with the input stair geometry I used, correct? Or are stairs treated differently within the program?
That being said, this unfortunately does not fix the problem. The EOpt still gives the same error, even after the model has been validated.
I have attached the grasshopper file here. I am not sure what minimal means in this case, but I have attempted to simplify as best as I can.
Glad that the Validation component helped you fix one of the the issues with your model since room overlaps like that can interfere with the adjacency solving. Also, thank you for uploading the file that creates the issue and it’s clear enough for me to follow what’s going on (I just asked for a “minimal” file because some people upload spaghetti soup grasshopper definitions and it’s just hard to know what part of the script I’m supposed to check).
Your issue is definitely related to the auto-generated ceiling plenums that Dragonfly is trying to add. I will investigate this further and likely push a fix. In the meantime, if you just set add_plenum_ to False on your DF Model to GeoJSON component, I am able to run the URBANopt simulation without issues. Given that the plenum spaces are all unconditioned and unoccupied, removing them from your simulation should not impact the estimated energy use all that much. So this hopefully unblocks you for now and you can always run an updated simulation with plenums later after I have pushed the fix.
Thank you so much for the fix! Unfortunately, I am still having a lot of trouble getting outputs from my file. I have validated the DF model, set a folder location for the geojson file, ran LB Versioner to get the updated DF model to geojson command, and I have been trying to do every fix I can think of. Feels like I am circling the issue, but I am unable to figure out what it is. At the moment, when I run my script I get a geojson file and no outright error is written on my DF run URBANopt, but no data outputs come out (except for a scenario location). The CSV file is empty save what is shown below:
Your simulation is running successfully for me and it looks like you just are not waiting long enough for the simulation to finish. All of those warnings don’t have any consequence on the accuracy of your resulting simulation and, if you wait long enough, the simulation will successfully translate your model to OpenStudio and start simulating it:
If you’re unhappy with how long your simulation is taking to finish, I would recommend setting use_multiplier_ to True, which should drop the run time down dramatically. Also, using a shade_dist_ to get rid of the shade geometry that is far away from your Building will also help a lot. All of those tiny little buildings in the distance are not going to affect your energy use in a measurable way.
That is strange, it is still not working for me. I have not been cancelling the simulation on my own, it just doesn’t complete. I have attached most recent osw.log that has the error in statements. in.osw.log (18.4 KB)
With that error, it is my guess that it is a problem with the installation of UrbanOPT? Given the errors appear to be about gems (which I will admit, I have no idea what a gem is in this context except for the fact that it appears to be running the UrbanOPT code).
EDIT: I believe the problem is as a result of my UrbanOPT download being corrupted in some way. After following their installation guide, I run into an issue in GitBash. I run the two commands they advise, with no errors:
$ /c/urbanopt-cli-0.9.0/setup-env.sh
$ . ~/.env_uo.sh
But, when I want to check the version using
uo -v
The following error appears, before the version is accurately shown.
Top level ::CompositeIO is deprecated, require ‘multipart/post’ and use Multipa rt::Post::CompositeReadIO instead!
Top level ::Parts is deprecated, require ‘multipart/post’ and use Multipart::Po st::Parts instead!
0.9.0
The same error occurs if I check the history using
uo -h
I hop that can provide some insight into the issue I am struggling with here.
I tried the same thing with a different version of urbanOPT (0.9.1) and got the same error in Gitbash.
Your trying to create a geometry that is smaller than 1 centimeter, which is below the native EnergyPlus absolute tolerance. When I encounter this issue, it almost always means that the units of the Rhino model are not correct. So I would make sure that your Rhino model is in meters (or feet?) and not in millimeters or something like that.
That fixed this issue. That being said, I am back to the original problem with the following error when inputting my sql file into HB End Use Intensity:
Solution exception:Failed to find the “Building Area” table in the .sql file.
I have simplified my model down to a single story and a single residential Room2d. I have simplified my study period to only one week, reported daily. I have validated my model. I have tried both with and without plenums and set use_multiplier to true. I have uninstalled and reinstalled ladybug (using the Pollinator downloader) and UrbanOPT (0.9.0) about three times.
I am still looking to resolve this issue, and I apologize for taking up so much of your time.
I have attached the most recent grasshopper model here.
I realize Dragonfly is arguably the most complicated way to build an energy model since it’s operating at a high level of abstraction that’s really only appropriate for large urban areas with multiple buildings where you have a really good understanding of all the inputs (and ideally you have run some small-scale tests before you’ve started scaling up to the urban level).
Given that there was only one building in your original file and you seem to be more in a phase of exploring some of the model inputs (like HVAC systems), I might recommend that you first build your models in Honeybee before trying to move to Dragonfly. Or, if you really feel that you need to use Dragonfly, you can use it to construct your model with Dragonfly components and then you can translate it to Honeybee in order to run an energy simulation with it using the HB Model to OSM component.
Following this workflow, I can see that your simulation is failing because the heating coil autosizing is failing:
I’ll admit that this looks like a bug in the OpenStudio standards routines for the central ASHP objects and I might report this to NREL on their GitHub. But it seems to result from the fact that you’re trying to use the ASHP object in such a cold climate that’s a bit beyond what NREL designed it for. Interestingly, I can get it to run with using the PSZ-HP object so, if you’re looking to run a simulation with heat pumps, I would recommend this one, which seems to include some extra features that enable it to run in cold climates.
FYI, I am adding some better error reporting into the URBANopt component so that you get the EnergyPlus Fatal Error reported on the component when a given building has failed simulation:
I still recommend using the the HB Model to OSM route until you’ve gotten a good understanding of how the building simulates before trying to scale up. But this will at least make it easier to debug URBANopt issues when they arise on the forum.
I wasn’t quite aware of the complexity of Dragonfly before beginning this project. It was introduced to me as a large urban scale version of HB, as the project I am working on involves several different multi-use buildings (the one-storey, one-room model in my previous GH script was just for my own troubleshooting). Given how new it is, I was (and am) excited to work with it. Overall, this has been a great learning experience, and I will definitely be focusing on smaller scale testing first, in the future.
I will explore using HB for this building, but the intent was to include a second high rise and a few smaller scale residential buildings in this model. I used the first building to explore the functionality of DF.
It is relieving to find out that this issue is as a result of an issue in OpenStudio. Now that I have set the All-Air system to be PVZ-HP, the simulation is now running properly.
The detailed error reporting is a great idea, thank you for letting me know.
Your patience and response rate have been phenomenal, thank you so much : )
Hi @chris sorry to bother you with this again. I’m getting the same error once again, and I’ve tried all the fixes you’d mentioned to @amoroz through the thread, but none of them work. I continue to get " [Error: Failed to find the “Building Area” table in the .sql file". It doesn’t work for me even when I change the HVAC system type to PSZ-HP. I was wondering if you’d happen to have any insight on this?
As I said above, this is because the EnergyPlus simulation failed. I opened your Grasshopper file but none of the geometry is internalized and there are a few cases where you are referencing local files on your system, which I do not have.
I see that you are also using the older components, which do not report the EnergyPlus simulation error to you. So, if you update your plugin using the LB Versioner and then run the LB Sync Grasshopper File component to ensure that you have the latest components on your canvas, you should see the exact error that EnergyPlus is running into. I imagine that it probably has to do with your selection of HVAC system much like it did in @amoroz 's case.
Hi @chris ,
Thanks a lot for the response, and sorry about the local files and geometry not being internalised. I had previously updated LBT, Pollination/Grasshopper, OpenStudio, and URBANopt, because I was getting a different error, and after updating, I started getting the building area error again. However, I tried switching some of the parameters now, and it appears to work again. I believe I may have accidentally left the window ratio parameter at 1.0 after the last update, which might have been what was causing the error previously with the program not being able to calculate the building area. Thanks so much for your help, really appreciate it!
