Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question
1

Access the openstudio application measure path

asked 2023-09-09 22:52:50 -0600

lzwang26's avatar

updated 2023-09-10 10:58:58 -0600

Hi,

I am developing an openstudio measure. I want to get the measure local path "C:/Users/username/OpenStudio/Measures/measurename/measure.rb" by using commands in the measure method "run(model, runner, user_arguments)". However, when the measure is running by the openstudio application, the path I get (using Dir.pwd) is a template path (e.g. C:/Users/username/AppData/Local/Temp/osmodel-1694197536-7/resources/measures/xxx). Is there any way to get the measure local path "C:/Users/username/OpenStudio/Measures/measurename/measure.rb" in the run() method?

Thank you!

Best,

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
4

answered 2023-09-10 21:49:11 -0600

What are you trying to do lzwang26? The OpenStudio Application does copy all the measures in your current model to a temporary directory when it is running the model. Any files in your measure's resources directory would also be copied into the resources directory in the temporary directory. You can also write output files from your measure to the generated_files directory, these will be copied back to the original directory after the run. Basically, you should not need to know the absolute path of the original measure, you should be able to do what you want to do with relative paths in the temporary directory.

Here are some code snippets that might be useful in your measure:

# get the current workflow being run
workflow = runner.workflow

# get the current workflow step being run
currentStep = workflow.currentStep.get
runner.registerInfo("currentStep = #{currentStep}")

# convert the current workflow to a measure step
currentMeasureStep = currentStep.to_MeasureStep.get

# can use the findMeasure method to find a measure by measure dir name
currentMeasurePath = workflow.findMeasure(currentMeasureStep.measureDirName).get
runner.registerInfo("currentMeasurePath = #{currentMeasurePath}")

# get the relative file paths searched for files in the current workflow
filePaths = workflow.filePaths
runner.registerInfo("filePaths = #{filePaths.join(', ')}")

# the first entry in the path is for generated output files the measure would write
File.open(File.join(filePaths[0].to_s, "output1.txt"), 'w') do |f|
  f.puts "Output 1"
end

# get the absolute file paths searched for files in the current workflow
absoluteFilePaths = workflow.absoluteFilePaths
runner.registerInfo("absoluteFilePaths = #{absoluteFilePaths.join(', ')}")

# the first entry in the path is for generated output files the measure would write
File.open(File.join(absoluteFilePaths[0].to_s, "output2.txt"), 'w') do |f|
  f.puts "Output 2"
end

# directory with the input osw file
oswDir = workflow.oswDir
runner.registerInfo("oswDir = #{oswDir}")

# relative directory with the osw file
rootDir = workflow.rootDir
runner.registerInfo("rootDir = #{rootDir}")

# absolute directory with the osw file
absoluteRootDir = workflow.absoluteRootDir
runner.registerInfo("absoluteRootDir = #{absoluteRootDir}")

# relative directory to the run directory
runDir = workflow.runDir
runner.registerInfo("runDir = #{runDir}")

# absolute directory to the run directory
absoluteRunDir = workflow.absoluteRunDir
runner.registerInfo("absoluteRunDir = #{absoluteRunDir}")

# relative path to the output osw file
outPath = workflow.outPath
runner.registerInfo("outPath = #{outPath}")

# absolute path to the output osw file
absoluteOutPath = workflow.absoluteOutPath
runner.registerInfo("absoluteOutPath = #{absoluteOutPath}")

# relative paths containing measures
measurePaths = workflow.measurePaths
runner.registerInfo("measurePaths = #{measurePaths.join(', ')}")
edit flag offensive delete link more

Comments

Hi macumber. Thank you so much for your answer! My case is a little special. I have a yaml file under the path "C:\Users\username\OpenStudio\Measures\measurename\resources\yamlfile.yml". Every time the measure runs, I hope to write the user selected arguments to this yaml file. Next time the measure runs, these selected arguments can be automatically loaded into the measure. I can manipulate the ymal file under the temp folder, but the yaml file under the path "C:\Users\username\OpenStudio\Measures\measurename\resources\yamlfile.yml" seems not update. Do you have some suggestions? Thank you!

lzwang26's avatar lzwang26  ( 2023-09-10 22:49:35 -0600 )edit
1

I think @macumber's suggestion works for you. The first time your measure runs, a project-specific yamlfile.yml could be generated and saved in the generated_files directory. For subsequent runs, the measure could check if generated_files/yamlfile.yml exists, if so read/validate, and if successful populate your measure input fields in the App. The file is rewritten with user-driven changes. We do something very similar with TBD; having both input/output JSON files preserved in the files folder. Works.

Denis Bourgeois's avatar Denis Bourgeois  ( 2023-09-12 05:39:24 -0600 )edit

... a side note. In your case, I would have the measure generate a new .yml from scratch (e.g. hash.to_yaml) if one did not exist in generated_files or files. It took us a few development cycles to nail down the solution (~25 lines) for TBD (the Apply Measures Now option was challenging). Are you keeping a template .yml for users to first edit by hand? That works if users are instructed to save the file in generated_files or files.

Denis Bourgeois's avatar Denis Bourgeois  ( 2023-09-12 05:56:55 -0600 )edit

Hi Denis, thank you so much for your comments and help! I agree with you, if we instruct the user to do something first, e.g. create or edit the yaml file, it will work. But if we can directly read and write the files in "C:/Users/username/OpenStudio/Measures/measurename/", it would be more convenient for the user because they don't need to conduct extra steps.

lzwang26's avatar lzwang26  ( 2023-09-12 15:18:53 -0600 )edit

Hey @lzwang26. "... if we instruct the user to do something first": my 2nd suggestion is ONLY IF you really want to allow users to edit the .yml file BEFORE running the measure a first time. For all other cases, generate the .yml file from scratch (either with default values, or user selections) and store in files or generated_files. Subsequent runs read-in .yml entries (if the file exists). And so on.

Denis Bourgeois's avatar Denis Bourgeois  ( 2023-09-12 17:33:49 -0600 )edit

Your Answer

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

Add Answer

Training Workshops

Careers

Question Tools

1 follower

Stats

Asked: 2023-09-09 21:18:03 -0600

Seen: 221 times

Last updated: Sep 18 '23