All of the OpenStudio workflows failed to execute

BcBod · April 30, 2024, 2:26pm

Hi Chris and others!

I am struggling with the DF Run URBANopt tool. The “All of the OpenStudio workflows failed to execute” Error keeps appearing. To try and solve it I re-installed all my LB components, openstudio and URBANopt, to make them all match within the compatibility matrix. Ladybug 1.7.0, OpenStudio 3.6.1, Openstudio App 1.6.0, URBANopt CLI 0.10.0, Rhino 7.0

Also, I ran the “LB versioner”. Both did not work. I still get the same error message.

I hope someone can help me out!

chris · May 29, 2024, 10:49pm

Hi @BcBod ,

Sorry for the late response. I realized that I forgot to update the Compatibility Matrix with the LBT 1.8.0 release but I just did it now. You are supposed to use URBANopt CLI 0.11.1 with LBT 1.8.0:

Also, your screenshot has components from both LBT 1.7 and LBT 1.8 on it. I recommend running the LB Sync Grasshopper File component to make sure that everything on your canvas is synced with your installation.

If doing those changes does not fix it, please upload the log file that is mentioned in the component error message. That should let me know what failed on your machine.

yimika · April 26, 2026, 7:29pm

Hi Chris,

I’m having this issue with Ladybug 1.10.0. I have updated everything according to the compatibility matrix and made sure all components are synced but it persists. I had UrbanOpt 1.1.0 installed but it said dragonfly required 1.2.0. When I updated UrbanOpt, I got the “All of the OpenStudio workflows failed to execute” error, and there are no log files as the subfolders in the simulation directory are empty.

chris · April 27, 2026, 5:45pm

Hi @yimika ,

Do you have a sample file that recreates this issue?

We recently made a change in the URBANopt workflow so that more data from the dragonfly models can be translated to the OSMs used in the URBANopt simulation. The URBANopt team also made some big changes with version 1.2 so that Ruby gems don’t have to be re-downloaded each time that you create a new project folder. It’s possible that there may be a bug that resulted from one of these changes.

yimika · April 27, 2026, 7:39pm

Here’s the sample file:

Mission_samplefile.gh (379.3 KB)

chris · April 27, 2026, 8:15pm

Thanks, @yimika .

I can see that it appears to be a bug in one of the Ruby gems of URBANopt 1.2. This is the failure message from URBANopt CLI:

Let me see if I can figure out what is going on and then I’ll report it to the URBANopt developers. I’ll also see if I can implement a workaround for the bug.

FYI, I did a validation of your model and you probably want to move the geometry to be closer to the Rhino XY plane so that your buildings aren’t experiencing wind speeds in the stratosphere in the E+ simulation:

chris · April 27, 2026, 11:19pm

@yimika ,

I figured out what the issue is - it’s the courtyard building:

It seems that the URBANopt GeoJSON Gem does not support using GeoJSON MultiPolygon for building footprints with holes/courtyards. The URBANopt gem currently seems to be written with the expectation that everything is a Polygon without any holes. From the URBANopt source code here, it seems like they had the intention of supporting MultiPolygon:

github.com

urbanopt/urbanopt-geojson-gem/blob/develop/lib/urbanopt/geojson/feature.rb#L295


      
                    errors = JSON::Validator.fully_validate(schema, feature[:properties])
                    if !errors.empty?
                      raise("Invalid properties for '#{feature[:properties][:name]}'\n  #{errors.join('\n  ')}")
                      return false
                    end
                  end
          
                  geometry_type = feature[:geometry][:type]
                  case geometry_type
                  when 'Polygon'
                  when 'MultiPolygon'
                  else
                    raise("Unknown geometry type '#{geometry_type}'")
                    return false
                  end
                  return feature
                end
              end
            end
          end

… but it seems like they never got the methods of the gem to work with MultiPolygons as far as I can tell. In any event, I opened an issue here so that they can add support for this:

github.com/urbanopt/urbanopt-geojson-gem

Support MultiPolygon for building footprints with courtyards

opened 10:50PM - 27 Apr 26 UTC

chriswmackey

This came up today from a user who was unable to get their model to simulate bec…ause one of their buildings had a courtyard: <img width="1334" height="596" alt="Image" src="https://github.com/user-attachments/assets/ca185252-cd57-435c-9aa2-63a7f16887db" /> This resulted in Dragonfly trying to use MultiPolygon in the GeoJSON to specify the feature instead of Polygon as you can see here in the file: [Mission_Block.json](https://github.com/user-attachments/files/27144372/Mission_Block.json) <img width="1464" height="674" alt="Image" src="https://github.com/user-attachments/assets/feaaa1f0-fadb-4b4e-8990-57aecb36d7c8" /> This caused the following exception to be thrown by the urbanopt-geojson-gem: ``` C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-geojson-1.2.0/lib/urbanopt/geojson/feature.rb:241:in `block in find_feature_center': undefined method `/' for [-111.0913500424786, 52.120736456804366, -111.0913500424786, 52.120736456804366, -111.0913500424786, 52.120736456804366]:Array (NoMethodError) latitude = station[1] * Math::PI / 180 ^ from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-geojson-1.2.0/lib/urbanopt/geojson/feature.rb:240:in `each' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-geojson-1.2.0/lib/urbanopt/geojson/feature.rb:240:in `find_feature_center' from C:/Users/Chris/simulation/Mission_Block/mappers/Honeybee.rb:88:in `create_osw' from (eval):1:in `create_input_files' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/simulation_dir_osw.rb:211:in `eval' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/simulation_dir_osw.rb:211:in `create_input_files' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/scenario_runner_osw.rb:41:in `block in create_simulation_files' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/scenario_runner_osw.rb:38:in `each' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/scenario_runner_osw.rb:38:in `create_simulation_files' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-scenario-1.2.0/lib/urbanopt/scenario/scenario_runner_osw.rb:69:in `run' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-cli-1.2.0/lib/uo_cli.rb:1454:in `<module:CLI>' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-cli-1.2.0/lib/uo_cli.rb:23:in `<module:URBANopt>' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-cli-1.2.0/lib/uo_cli.rb:22:in `<top (required)>' from <internal:C:/URBANopt-cli-1.2.0/ruby/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:C:/URBANopt-cli-1.2.0/ruby/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/gems/urbanopt-cli-1.2.0/bin/uo:3:in `<top (required)>' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/bin/uo:25:in `load' from C:/URBANopt-cli-1.2.0/gems/ruby/3.2.0/bin/uo:25:in `<main>' ``` From the code on this line, it seems like the intention was to support specifying building footprints with MultiPolygon: https://github.com/urbanopt/urbanopt-geojson-gem/blob/develop/lib/urbanopt/geojson/feature.rb#L295 It is just that the [`find_feature_center`](https://github.com/urbanopt/urbanopt-geojson-gem/blob/develop/lib/urbanopt/geojson/feature.rb#L234-L259) method was not written to handle them. It would be nice if this method could be rewritten to use just the outer boundary polygon whenever a MultiPolygon is found such that users do not get blocked by this limitation.

… and I added a workaround to Dragonfly for the time being so you can simulate your model:

I verified that the fix works for your model:

… and the fix/workaround is should be available via the LB Versioner in an hour.

Also, you can disregard my comment about your building being in the stratosphere. When I saw that your GeoJSON was the size of a Canadian province, I realized you were working in mm and not m.

Thanks for reporting!

yimika · April 27, 2026, 11:55pm

Thank you so much @chris !