NatLabRockies / NatLabRockies/OpenStudio

Different behavior with workspace.addObjects vs. workspace.addObject for invalid IDF files

Open
#3,351 10 comments 0 reactions 1 assignee View on GitHub

@jmarrec is already working on this.

Since Feb 26, 2019.

component - Workspace severity - Minor Bug
Dominant language
C++
Stars
646
Forks
237
Avg merge
3d 11h
Merged PRs (30d)
10

Description

After seeing post related to this on UH I looked at the https://bcl.nrel.gov/node/83281

It currently uses code like this.

source_idf = OpenStudio::IdfFile::load(OpenStudio::Path.new(source_idf_path)).get
add_objects = workspace.addObjects(source_idf.objects)

If the IDF has one or more invalid objects nothing is added to the model with addObjects. You can see the objects in source_idf but some have been altered where missing or invalid fields were. Additionally if you call source_idf.objects.size it returns the correct size. While initial and final condition report number of objects I thought a better warning would be useful, so I added code below to alert. There is also code now if size is 0 to say the file is empty (or has nothing seen as an object).

    if add_objects.empty?
      runner.registerError("Source IDF file may be invalid. No valid objects were added.")
      return false
    end

I wanted to see which object were the problem so I tried stepping through objects and adding one at a time using the code below.

    source_idf.objects.each do |object|
      runner.registerInfo("Adding #{object.getString(0)}")
      new_object = workspace.addObject(object)
    end

I was a little bit surprised that in this case the objects are all brought in, although it is the altered version of them, that are likely invalid or not what is expected by the user.

As an example this invalid object

BuildingSurface:Detailed,
  Example Surface for Zone In Model,      !- Name
  0, -6.5452625, 0,                       !- X,Y,Z Vertex 3 {m}
  0, 0, 0;                                !- X,Y,Z Vertex 4 {m}

Comes in like this

BuildingSurface:Detailed,
  Example Surface for Zone In Model,      !- Name
  0,                                      !- Surface Type
  ,                                       !- Construction Name
  ,                                       !- Zone Name
  0,                                      !- Outside Boundary Condition
  ,                                       !- Outside Boundary Condition Object
  0,                                      !- Sun Exposure
  ,                                       !- Wind Exposure
  ,                                       !- View Factor to Ground
  ;                                       !- Number of Vertices

There are two possible issues. One, it seems that addObjects and addObject should take similar approach on a specific object. The second issue is if there is a way to alert user by maybe returning bool or optional. I think it is important that generally the objects are returned, so probably don't want to change that. Maybe the warning about things being changed should be here

source_idf = OpenStudio::IdfFile::load(OpenStudio::Path.new(source_idf_path)).get

I could try to compare the resulting source_idf.to_s against the IDF file loaded in as text file and confirm that they are the same, but sometimes minor things like comments are changed and are not an issue. Some fancy regex could try to address this.

As a note, when I import the IDF to OS app or SketchUp plugin using reverse translation, I am warned about the IDF in each case, it would be nice to have access that in some form in measures. (not sure if the warnings are triggered in loading IDF or reverse translation. for InjectIdfOjbects measure there is no reverse translation, but I just wanted to see what the GUI showed.

OS App error:

The collection is INVALID at strictness level 'Draft', because of the errors:
Field      level data error of type DataType          .
Error is in an object of type 'BuildingSurface:Detailed', named 'Example Surafce for Zone In Model', in field 1.
Additional information about the error type: field-level data is of an incorrect type.
Field      level data error of type DataType          .
Error is in an object of type 'UtilityCost:Charge:Block', named '', in field 3.
Additional information about the error type: field-level data is of an incorrect type.

Plugin error

The following errors occurred on import.

Error: Fewer than 3 vertices detected for surface '1'
Error: Fewer than 3 vertices detected for surface '1'

Error: Cannot create Surface for object: BuildingSurface:Detailed,
  Example Surafce for Zone In Model,      !- Name
  0,                                      !- Surface Type
  ,                                       !- Construction Name
  ,                                       !- Zone Name
  0,                                      !- Outside Boundary Condition
  ,                                       !- Outside Boundary Condition Object
  0,                                      !- Sun Exposure
  ,                                       !- Wind Exposure
  ,                                       !- View Factor to Ground
  Autocalculate;                          !- Number of Vertices

The following warnings occurred on import.
Warning: Could not find GlobalGeometryRules object, assuming defaults
Warning: Could not find Building object, assuming 0 rotation
Warning: Could not find Building object, assuming 0 rotation
Warning: Could not find Building object, assuming 0 rotation
Warning: Could not find Building object, assuming 0 rotation

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.