jugonzal07's profile - activity

Thanks so much! I knew there were mandatory files but failed to realize resource files must follow a strict convention a

I'm writing an OpenStudio measure with a long list of options for many of the input parameters. Initially, I tried to use a secondary file to host all the constants to keep things tidy but found importing parameters into the measure.rb file resulted in the OpenStudio application not populating my input dropdowns (although I could see them in the measure.xml ?) So I tried looking through other measures and found most folks just kind of listed them all out in the measure.rb file. Is there no better best practice?

MCVE directories for a working and broken example of what I mean can be found here:

• Link to working and broken measure

You will see both measures populate the choice argument with a module called MyConstants:

choices_os_vector = OpenStudio::StringVector.new
option_list = MyConstants::CHOICE_LIST
option_list.each do |option|
  choices_os_vector << option
end

The only difference is that working example has the module inside the measure.rb file while the broken example references the module from a separate file called my_choice_constants.rb.

I would much rather have this list of inputs reference a dynamic reference that updates with something like the OpenStudio Standards gem rather than have to update it in two places.

Thanks Julien, the MVCE has been uploaded and the question updated to reflect it. Let me know if that is more in line wi

OpenStudio Measure with long list of inputs -- best practice I'm writing an OpenStudio measure with a long list of optio

OpenStudio Measure with long list of inputs -- best practice I'm writing an OpenStudio measure with a long list of optio

OpenStudio Measure with long list of inputs -- best practice I'm writing an OpenStudio measure with a long list of optio

Hi all,

I have a school modeled in EnergyPlus 8.9 with a unitary multispeed heat pump and an EMS used to simulate a DOAS. When ran in a milder climate like Seattle it runs just fine, but when ran in Chicago I get this Density of Air issue:

** Severe ** PsyRhoAirFnPbTdbW: RhoAir (Density of Air) is calculated <= 0 [-384.79728]. ** ~~~ ** pb =[98725.00], tdb=[-274.04], w=[0.0000000]. ** ~~~ ** Routine=CalcMultiSpeedDXCoilHeating, Environment=RUN PERIOD 1, at Simulation time=07/01 00:34 - 00:35 ** Fatal ** Program terminates due to preceding condition.

Some cursory google searches say this error happens more frequently with buildings that have incorrect U-values for one of their envelope components but this model's U-values seem fine. Has anyone ran into this before? Thanks.

Files can be found at this Github Link

• IDF file
• ERR file
• HTML for 2 month simulation

Running the measure you linked in OS 3.3 correctly intersects and matches surfaces on my end as well.

See the image below for context. At the top, you'll see the model before surface matching. Below, you'll see the model in OS 2.9 and in 3.1. You'll notice how the boundary condition for the floors changes to Surface for all the surfaces except a sliver that remains adjacent to Ground.

If you look at the roof surfaces, you'll notice this sliver is now missing altogether in OS 3.1.

I'm unsure why this is happening. Here is a clue I get when doing the intersect surfaces in OS 3.1

[openstudio.model.Surface] <1> Initial area of surface 'Surface 18' 646.605 does not equal post intersection area 646.605

Link to source in C++ code as far as I can tell. Appears to have something to do with intersection code

Things I have checked:

• The order in which spaces are matched is identical
• Both versions of OpenStudio agree upon which spaces intersect.
• The OpenStudio methods OpenStudio::Model.intersectSurfaces(spaces) and OpenStudio::Model.matchSurfaces(spaces) do not resolve the issue (they made it worse somehow, not sure why).

LINK TO MINIMUM WORKING EXAMPLE:

https://github.com/jugonzal07/stack_o...

Meat of the surface code is under match_spaces on L95

def match_spaces(spaces)

    # Sort spaces for consistency between models
    spaces = sort_spaces(spaces)

    n = spaces.size

    boundingBoxes = []
    (0...n).each do |i|
        boundingBoxes[i] = spaces[i].transformation * spaces[i].boundingBox
    end

    (0...n).each do |i|
        (i+1...n).each do |j|
            next unless boundingBoxes[i].intersects(boundingBoxes[j])
            puts "#{spaces[i].name.to_s} intersects #{spaces[j].name.to_s}"
            spaces[i].intersectSurfaces(spaces[j])
            spaces[i].matchSurfaces(spaces[j])
        end #j
    end #i
end

Unfortunately running the measure appeared to have had the same result as when I manually ran OpenStudio::Model.intersec

Thanks so much David! This has all been very helpful. I will try explicitly running the measure you ran in 3.3 in 3.1 t

oh, sorry about that! I didn't mean to add os_matching_method.osm to the repo. That was a dummy file I was using to test

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 See the image below for context. At

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 See the image below for context. At

hi Aaron - this is being done with the OpenStudio SDK. In the code snippet I posted, you can see spaces[i].intersectSurf

hi @aaron-boranian - this is being done with the OpenStudio SDK. In the code snippet I posted, you can see spaces[i].int

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 See the image below for context. At

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 See the image below for context. At

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 See the image below for context. At

OpenStudio 3.1 erases surfaces when surface matching. Not present in OpenStudio 2.9 When doing regression checks on upda

Thanks for catching that. I have updated the link.

Thanks for catch that. I have updated the link.

Hi all, I ended up writing my own script for calculating a wall and floor intersection. It comes with some caveats (fou

Hi all,

We've hit a bug in our code base that will randomly add unnecessary edges/surfaces when doing surface matching. It's surprisingly inconsistent and I haven't been able to pin down why it happens.

Below is a screenshot before and after performing intersect surfaces and match surfaces. I have a ceiling plenum space touching a set zones for a perimeter and core layout. For some reason, two extra lines are added:

I created a minimum working example with the old legacy code we use for surface matching and intersecting. The original author has long since left the project but it seems fairly simple to grasp. The code and example for regenerating this problem can be found on github here. The script you'd want to run is titled surface_matching.rb. The one edit you'd need to make is on line 48 for the path to the before_matching.osm file.

require 'openstudio'

# Helper to load a model in one line
def osload(path)
    translator = OpenStudio::OSVersion::VersionTranslator.new
    ospath = OpenStudio::Path.new(path)
    model = translator.loadModel(ospath)
    if model.empty?
        raise "Path '#{path}' is not a valid path to an OpenStudio Model"
    else
        model = model.get
    end
    return model
end

def match_blocks(model)
    spaces = model.getSpaces
    outside_spaces = []
    spaces.each do |space|
        space.surfaces.each do |surface|
            if (surface.outsideBoundaryCondition == "Outdoors" ||
                    surface.outsideBoundaryCondition == "Ground")
                outside_spaces << space
                break
            end
        end
    end

    n = outside_spaces.size

    boundingBoxes = []
    (0...n).each do |i|
        boundingBoxes[i] = outside_spaces[i].transformation * outside_spaces[i].boundingBox
    end

    (0...n).each do |i|
        (i+1...n).each do |j|
            next if not boundingBoxes[i].intersects(boundingBoxes[j])
            outside_spaces[i].intersectSurfaces(outside_spaces[j])
            outside_spaces[i].matchSurfaces(outside_spaces[j])
        end #j
    end #i
end


#----- Main testing starts here

osm_path = 'C:/git/stack_overflow_questions/unmet_hours/surface_matching/before_matching.osm'

model = osload(osm_path)

# Match and intersect surfaces
match_blocks(model)

File.open("after_matching.osm", 'w') {|f| f.write(model)}

Any thoughts on what's causing this?

Thanks!

Big thanks to all the folks who helped here (@macumber and @david-goldwasser). I pushed out a solution on github here

Thanks all for the responses. I'll give some of these a try! I agree that sorting the surfaces, at the very least, will

Thanks all for the responses. I'll give some of these a try! I agree that sorting the surfaces, at the very least, will

Thanks David, I ended up using a similar idea to what you had. You can find it in my answer above.

Thanks David, I ended up using a similar idea to what you had. You can find it in my answer above..

Hi all,

I'm looking to find the best way to use the OpenStudio SDK to check if two surfaces intersect. Rather than write my own code to do this, I assumed there's likely something packaged into the SDK to help me do this.

Ideally, the code would look something like.

#Made up function 'intersectsWith'
surfaces_intersect = surface1.intersectsWith(surface2)

if surfaces_intersect 
   #DO SOMETHING
end

Where

• surface1,surface2 are OpenStudio::Model::Surface
• surfaces_intersect = a boolean that determines if surface1 and surface2 intersect

I've looked into the computeIntersection for Surface found here but am unsure if this is path would be the most elegant way to do this.

For context, I'm trying to dynamically determine the perimeter of a floor surface exposed to ambient to set them for a FFactorGroundFloorConstruction. I haven't seen any way to easily do this in OpenStudio. Here is my approach:

1. Identify if floor with outside boundary condition equal to Ground. If so, flag as a floor requiring a FFactorGroundFloorConstruction
2. Identify all walls in this floor's space. If the wall's outside boundary condition is Outdoors AND it intersects the floor of interest, find it's projection on the x, y plane (i.e. the length of floor that is exposed to perimeter along this wall). NOTE: This assumes a wall only touches 1 floor; this might not always be true.
3. Add these perimeters for the floor to ultimately arrive at the exposed perimeter.

I cannot complete step two as I do not have a way to determine if a wall intersects a floor surface.

Any ideas? Thanks!

Thanks David, I ended up using a similar idea to what you had. You can find it in my answer below.