Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page
Ask Your Question
2

PAT 2.0 Batch Running

asked 2017-09-19 10:34:20 -0500

Alex Bennett gravatar image

updated 2017-09-19 12:07:58 -0500

I'm just starting to use PAT 2.0 after using the OpenStudio analysis spreadsheet in the past. The one function I am looking for in PAT from the spreadsheet and cannot find is the Parallel Batch Running. What I am trying to do is run a series of unique scenarios (so something like the full_factorial analysis doesn't work) from a list created in Excel. Is there a way to do this in PAT 2.0?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-09-19 12:07:04 -0500

updated 2017-09-19 14:28:51 -0500

Have you looked at the documentation for Design Alternatives for a manual analysis? I think that is what you are looking for. The design alternatives can be run locally or on Amazon EC2.

Update: (calling earlier measure argument values from within a measure) @Alex Bennett, I don't think this will fit in comment so I updated my answer.

The following method will loop through all upstream measure arguments, stopping at the first argument matching the requested name. It will then return the value of that measure.

def self.check_upstream_measure_for_arg(runner,arg_name)

# 2.x methods (currently not setup for measure display name but for snake_case arg names)
arg_name_value = {}
runner.workflow.workflowSteps.each do |step|
  if step.to_MeasureStep.is_initialized
    measure_step = step.to_MeasureStep.get

    measure_name = measure_step.measureDirName
    if measure_step.name.is_initialized
      measure_name = measure_step.name.get # this is instance name in PAT
    end
    if measure_step.result.is_initialized
      result = measure_step.result.get
      result.stepValues.each do |arg|
        name = arg.name
        value = arg.valueAsVariant.to_s
        if name == arg_name
          arg_name_value[:value] = value
          arg_name_value[:measure_name] = measure_name
          return arg_name_value # stop after find first one
        end
      end
    else
      #puts "No result for #{measure_name}"
    end
  else
    #puts "This step is not a measure"
  end
end

return arg_name_value

end

One example is that two or more measures have an argument or a specific 90.1 standards. In our measures this measure is often named "template". I would call this code in each measure to override the user entered value. with the value from the first instance of "template" as a measure argument. So if measures "A,C,X and Y" all called for "template" I would setup "template" as a variable for "A" and add code to "C,X, and Y" to use whatever was used for "A". This code is shown below.

# look at upstream measure for 'template' argument
# todo - in future make template in this measure an optional argument and only override value when it is not initialized. There may be valid use cases for using different template values in different measures within the same workflow.
template_value_from_osw  = OsLib_HelperMethods.check_upstream_measure_for_arg(runner, 'template')
if template_value_from_osw.size > 0
  runner.registerInfo("Replacing argument named 'template' from current measure with a value of #{template_value_from_osw[:value]} from #{template_value_from_osw[:measure_name]}.")
  args['template'] = template_value_from_osw[:value]
end

Another possible use case, if Measure "C" has not been run, or has not been run with specific measure arguments, then don't run measures "X,Y, and Z". While you can't really skip them on the fly, you can add a test at the very beginning of the run section, with a return true within the if statement if the test is true.

For some tests, you wouldn't even need upstream measures. You can directly check the model for building type, size, number of stories, climate zone etc. This gives you a lot of control to minimize variables, and use embedded logic to control the rest of the workflow. This would be good topic for advanced measure writing class.

edit flag offensive delete link more

Comments

The issue is that I will be doing larger scale runs with about 5000 unique scenarios so manually inputting all of them in Design Alternatives is not an option. Is there a way to load up a CSV or Excel file to Design Alternatives?

Alex Bennett gravatar image Alex Bennett  ( 2017-09-19 12:09:51 -0500 )edit

If you want a spreadsheet as input, then I would keep using the Analysis Spreadsheet vs. PAT. You can also directly use the CLI and run multiple OSW's at the same time. Are you using different measures for the 5000 datapoints, or just different argument values. Is there any way you can describe the space with variables so you can use an algorithmic approach, it doesn't have to be a full matrix. In OpenStudio 2.x you can write measures that look at upstream measure argument values, so that measure X can be told to only run if measure C ran, or can borrow argument value.

David Goldwasser gravatar image David Goldwasser  ( 2017-09-19 12:22:32 -0500 )edit

I am using different argument values. And that is interesting that the measures can now look upstream at argument values, how exactly is that setup? Would it be possible to create a CSV measure that reads a CSV of unique inputs and sets argument values that then can be borrowed by the other measures to run?

Alex Bennett gravatar image Alex Bennett  ( 2017-09-19 14:10:20 -0500 )edit

Thanks for all the detail! To clarify though is there a way to link the workflow (.OSW) to PAT? Or is the upstream argument reading only for CLI?

Alex Bennett gravatar image Alex Bennett  ( 2017-09-19 15:38:21 -0500 )edit

PAT, which is an OpenStudio Analysis, either generates OSW's from manual design alternatives, or from an algorithmic workflow. You can't take OSW's and import them into PAT. But if you can generate or alter a template OSW on your own with scripting language of your choice, you can then use the CLI to batch run them, using multiple cores. The runner methods to get upstream arguments will work on any simulation that use an OSW to run, which is how most OpenStudio simulations are run now. If you aren't going to use PAT to describe your design alternatives, what do you want to gain from it?

David Goldwasser gravatar image David Goldwasser  ( 2017-09-19 15:48:28 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

 

Question Tools

1 follower

Stats

Asked: 2017-09-19 10:34:20 -0500

Seen: 115 times

Last updated: Sep 19 '17