Assembling heavy daylight model geometry

Mathiassn · November 3, 2021, 8:45am

I don’t get why the AssignGridsViews takes me 2 minutes when my model takes 1 second to assemble and I’m inputting empty streams into the AssignGridViews.

Curious to how can it take longer to do nothing to the model than to actually assembling it? (there’s 1.5M shades in the model)

See below

AbrahamYezioro · November 3, 2021, 9:09am

What happens when the grid is not empty?

-A.

Mathiassn · November 3, 2021, 10:12am

fixed the grid. still the collect model is super slow

AbrahamYezioro · November 3, 2021, 10:22am

I can’t tell, but i’m suspicious of the empty inputs. I see that there is another one there. Unplug this one and see what happens.
Just trying to debug possible reasons …
-A.

Mathiassn · November 3, 2021, 10:38am

Good point,

empty inputs wasnt the issue, see below

its just funny how it can take 1 sec to make the model, 2 secs to make the grids, but 2 minutes to merge the two!

Mathiassn · November 3, 2021, 1:27pm

In same thread,

the Shade components take 4 minuttes to run through 1.5M mesh faces. If the ambition is to fire large models through this bottle neck to pollination I would suggest someone looking into C#/Hops or atleast parallelizing the Mesh->Shade component.

I’m sort of reviving this thread I know, but still on large models parts of the legacy workflows feel more responsive (and most other parts are definately much better in LBT!)

but for instance me running a quickrender in this 1.5M poly model takes around 1-2 minuttes, because it’s converting hbjson to rad. So basically everytime i do something radiance related in this file, i’ll have a 2m+ delay. In the old workflow when first the rad files were written, i could do all my small quick renders etc without any lag in grasshopper.

I even did a parallel c# wrapper for the Msh2rad legacy component which gave a lot of speedup, take a look here GitHub - linkarkitektur/LINK_SHARE: Public IO repository with items shared with the rest of the world #Karma

Mathiassn · November 4, 2021, 9:47am

In same thread,

when trying to reload old results (in this case only 8000 daylight factor points), the DaylightFactor component takes 3 minuttes to read the results. Looks like it generating and converting all the shade->rad stuff without any reason, as I’m just supposed to read existing results. This took 1 second in the legacy workflow when I was looking up 8000 values in a rad folder.

Mathiassn · November 4, 2021, 12:08pm

looks like it’s the model.duplicate() command that causes this. Maybe if we split up the model.settings and model.geometry, we would be able to only duplicate settings instead geometry. Large models get large in memory and processing if they are to be copied at every component (although I know this is the grasshopper way…)

mikkel · November 4, 2021, 4:38pm

Thanks for putting it to the test, @Mathiassn!

I think @chris can provide more information on why things are as they are, so I will just leave my observations in this post for Chris.

The long time to assign grids is definitely caused by duplicating the model. If I replace line 54 (see link to github below) with model = _model it runs in no time. Again, @chris can probably tell if this is a very bad idea that can cause issues.

github.com

ladybug-tools/honeybee-grasshopper-radiance/blob/26ac54fbf2798bbd036ab9d78b2d978acb83947f/honeybee_grasshopper_radiance/src/HB Assign Grids and Views.py#L54

    
      
          
          
try:  # import ladybug_rhino dependencies
              from ladybug_rhino.grasshopper import all_required_inputs
          except ImportError as e:
              raise ImportError('\nFailed to import ladybug_rhino:\n\t{}'.format(e))
          
          

          
if all_required_inputs(ghenv.Component):
              assert isinstance(_model, Model), \
                  'Expected Honeybee Model. Got {}.'.format(type(_model))
              model = _model.duplicate()  # duplicate to avoid editing the input
              if len(grids_) != 0:
                  model.properties.radiance.add_sensor_grids(grids_)
              if len(views_) != 0:
                  model.properties.radiance.add_views(views_)

The reload_old_ bottleneck seems to be line 200 (see link to github below). I tested a much smaller model than your model. The time comparison in seconds between False/True for reload_old_ can be seen in the image below, as well as the time it takes to run inp.handle_value() for the model.

github.com

ladybug-tools/lbt-recipes/blob/23024b71bce0977f7c47621011af8cb2c3b7628a/lbt_recipes/recipe.py#L200

    
      
                  If None, no overriding will happen. (Default: None).
          """
          # create setup the project folder in which the inputs json will be written
          p_fold = project_folder if project_folder else self.default_project_folder
          if not os.path.isdir(p_fold):
              preparedir(p_fold)
          file_path = os.path.join(p_fold, '{}_inputs.json'.format(self.simulation_id))
          # create the inputs dictionary, ensuring all inputs are handled in the process
          inp_dict = {}
          for inp in self.inputs:
              inp.handle_value()
              if inp.is_path and inp.value is not None and inp.value != '':
                  # copy artifact to project folder
                  path_basename = os.path.basename(inp.value)
                  dest = os.path.join(p_fold, path_basename)
                  if os.path.isfile(inp.value):
                      try:
                          shutil.copyfile(inp.value, dest)
                      except shutil.SameFileError:
                          pass  # the file is already in the right place; no need to copy
                  elif os.path.isdir(inp.value):

Mathiassn · November 5, 2021, 7:16am

Hi Mikkel,

thanks for investigating this. I also ended up commenting out the duplicate part, but in order to avoid too many views/grids added to the model, my AssignGridViews look like this. I know it’s not a 100% grasshopper style.

    model = _model#.duplicate()  # duplicate to avoid editing the input
    #model = _model
    if len(grids_) != 0:
        
        if len(model.properties.radiance.views) == 0:
            model.properties.radiance.add_sensor_grids(grids_)
        else:
            model.properties.radiance.sensor_grids = []
            model.properties.radiance.add_sensor_grids(grids_)
    if len(views_) != 0:
        if len(model.properties.radiance.views) == 0:
            model.properties.radiance.add_views(views_)
        else:
            model.properties.radiance.views = []
            model.properties.radiance.add_views(views_)

Also unsure if my edits will be overridden when I use the LBT update script component

chris · November 5, 2021, 2:01pm

Hi @Mathiassn ,

Yes, it’s definitely the duplication of your large model geometry that’s causing the slowness. You don’t need to duplicate geometries when you create the model from smaller elements because the model is just a container that holds these objects. We DO need to duplicate the model when you add the sensor grids because, otherwise, you’ll be editing the model object that comes out of the HB Model component (breaking the Illusion of Grasshopper where each component edits the input object but doesn’t change this input, only outputting a new edited object).

Needless to say, with a few lines of custom code within your own GHPython component, you can do all of this inside one component and avoid the slowdown for your case. FYI, you can also write your Model to a compressed Pickle file, which you can plug into any of the Radiance recipes and this should save some time in translating the Honeybee Model to a Honeybee-Radiance folder. Just use the “HB Dump Objects Compressed” to write your Model to this pickle file and plug the output file into the _model input of the recipe.