Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A bug related to OS:Schedule:File and OS:External:File with OpenStudio App #4046

Closed
tsbyq opened this issue Aug 14, 2020 · 7 comments · Fixed by NREL/OpenStudio-user-documentation#25

Comments

@tsbyq
Copy link

tsbyq commented Aug 14, 2020

Issue overview

When exporting an OpenStudio model with OS:External:File objects to IDF with OpenStudio App, related schedule objects are not translated properly. EnergyPlus simulation with the exported IDF fails due to blank "File Name" field in the Schedule:File.

Current Behavior

The OS:Schedule:File and OS:External:File objects are not handled correctly. Two unexpected behaviors:

  1. After an OpenStudio model with OS:Schedule:File and OS:External:File objects are exported to IDF, the "File Name" of Schedule:File object is empty.
  2. When a measure is applied with "Apply Measure Now" approach and generates new schedules associated with external files, the OpenStudio simulation fails due to missing schedule:file. Please note that if the measure that generate new schedules associated with external files are added to the "Measures" tab, the simulation runs successfully.

Expected Behavior

Corresponding to the two behaviors above, the expected behaviors are:

  1. After the OSM are exported to IDF, the "Schedule:File" in the IDF should refer to the correct external file path.
  2. The OpenStudio simulation should run normally with OS:Schedule:File and OS:External:File objects generated by other measures from the "Apply Measure Now" approach.

Steps to Reproduce

Steps to reproduce the first unexpected behavior:

  1. Apply "Create DOE Prototype Building" measure to create a new model (optional if a model is already available)
  2. Apply "Occupancy Simulator" measure with the "Apply Measure Now" GUI to create stochastic occupancy schedules (with OS:External:File and OS:Schedule:File objects). This step will create time-series schedules saved in an external CSV.
  3. Export the OSM to IDF

Steps to reproduce the second unexpected behavior:

  1. Same as above
  2. Same as above
  3. Go to the Run tab, click on the start run button.

Possible Solution

Improve the generated files storing mechanism.

Details

Environment

Some additional details about your environment for this issue (if relevant):

  • Platform (Operating system, version): Windows 10 Pro
  • Version of OpenStudio (if using an intermediate build, include SHA): both (1) OpenStudio v2.9.1 and (2) OpenStudio 3.0.1 with OpenStudioApplication-1.0.0 have this issue.

Context

This issue may affect users that uses schedules associated with external files.

@tsbyq tsbyq added the Triage Issue needs to be assessed and labeled, further information on reported might be needed label Aug 14, 2020
@macumber
Copy link
Contributor

I can also take a look at this unless someone else is

@tijcolem tijcolem added severity - Normal Bug component - Model and removed Triage Issue needs to be assessed and labeled, further information on reported might be needed labels Aug 21, 2020
@jmarrec
Copy link
Collaborator

jmarrec commented Sep 14, 2020

DId you end up looking at it @macumber?

@macumber
Copy link
Contributor

On my list for this week

@jmarrec
Copy link
Collaborator

jmarrec commented Mar 10, 2021

@macumber Should I look into it?

@jmarrec
Copy link
Collaborator

jmarrec commented Jun 2, 2021

It's hard to tell where things are going south: measure itself, OpenStudio SDK, openstudio-workflow gem, or OpenStudioApplication. There may be more than one bug (and there probably is)

BUT that being said, this measure itself appears faulty. It should be modified to start with. The measure tries way too hard to provide an absolute path to write the CSV/XML files to. It shouldn't do that. Also, if you run the measure by adding it to your workflow.osm (Or on the Measures tab of the app), the measure says it worked, but if you inspect your resulting files you actually end up with zero Schedule:File objects so it does not work in either case.

So I'm going to exclude the measure for the testing, and instead focus on a Minimum Complete Verifiable Example with a dummy measure that uses paths correctly to test this with.

measure.rb

class TestCreateAScheduleFile < OpenStudio::Measure::ModelMeasure
  # human readable name
  def name
    # Measure name should be the title case of the class name.
    return 'Test Create a ScheduleFile'
  end

  # human readable description
  def description
    return 'Test creating a ScheduleFile on the fly'
  end

  # human readable description of modeling approach
  def modeler_description
    return 'Test creating a ScheduleFile on the fly. To test whether we can successfully run that via workflow.osw AND apply Now in the App'
  end

  # define the arguments that the user will input
  def arguments(model)
    args = OpenStudio::Measure::OSArgumentVector.new

    return args
  end

  # define what happens when the measure is run
  def run(model, runner, user_arguments)
    super(model, runner, user_arguments)

    # use the built-in error checking
    if !runner.validateUserArguments(arguments(model), user_arguments)
      return false
    end

    # assign the user inputs to variables


    # report initial condition of model
    runner.registerInitialCondition("The model started with #{model.getScheduleFiles.size} ScheduleFiles.")

    csv_in_path = "#{File.dirname(__FILE__)}/resources/schedulefile.csv"

    runner.registerWarning("File.dirname(__FILE__)=#{File.dirname(__FILE__)}")
    runner.registerWarning("csv_in_path=#{csv_in_path}")
    runner.registerWarning("File.realpath('./')=#{File.realpath('./')}")
    runner.registerWarning("File.absolute_path('.')=#{File.absolute_path('.')}")

    # Note: copying is pointless. ExternalFile Ctor does that for you.
    # But I'm trying stuff, so I'm going to make an arbitrary copy with another name.
    # This replicates what the openstudio_results.html will do for eg to create the openstudio_results.html
    FileUtils.cp(csv_in_path, './somethingelse.csv')

    externalFile_ = OpenStudio::Model::ExternalFile::getExternalFile(model, csv_in_path)
    if (!externalFile_)
      runner.registerError("Failed to instantiate an External File")
      return false
    end

    scheduleFile = OpenStudio::Model::ScheduleFile.new(externalFile_.get())
    puts "===== scheduleFile ===="
    puts scheduleFile

    # report final condition of model

    runner.registerFinalCondition("The model finished with #{model.getScheduleFiles.size} ScheduleFiles.")

    return true
  end
end

# register the measure to be used by the application
TestCreateAScheduleFile.new.registerWithApplication

@macumber
Copy link
Contributor

macumber commented Jun 3, 2021

Not sure if this is the right place for this but I think it would be useful to document the supported workflows for generating files in the workflow and then finding them downstream. I just ran across this in the honeybee to openstudio translator when I had to copy a schedule CSV to a generated files directory because that is where the workflow gem is looking for them:

https://github.com/ladybug-tools/honeybee-openstudio-gem/pull/204/files
https://github.com/NREL/OpenStudio-workflow-gem/blob/c27ce74bd99e1b435cd9cd35db7009070b8c9e12/lib/openstudio/workflow/jobs/run_initialization.rb#L102

Documenting the correct use would allow everyone to standardize on one approach

@jmarrec
Copy link
Collaborator

jmarrec commented Jun 3, 2021

Yeah I agree some documentation is needed. If i recall correctly the workflow gem does append it first in line. Then the SDK does various things with workflowPaths[0], eg ExternalFile ctor copies the file it is passed to that path (so it does end up in generated_files/ if added from a workflow measure, or in files/ otherwise...)

OSrunner scans added files and does something too, but in my brief testing it didn't behave like I expected

jmarrec added a commit to jmarrec/OpenStudio-user-documentation that referenced this issue Jun 3, 2021
@tijcolem tijcolem added this to the OpenStudio SDK 3.3.0 milestone Jun 11, 2021
tijcolem added a commit that referenced this issue Jun 21, 2021
#4046 - Clarify the situation with output file in the ReportingMeasure Template
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants