Python plugin next steps

[joseph-robertson]

Extend the python plugin feature that was implemented in #4600. Specifically:

• [ ] optionally provide python script with OS handles/names and then FT does replacement in the python script
• [x] OS measure generates the python script (this is in the realm of user documentation / demonstration)
  • https://github.com/NREL/OpenStudio/pull/4858

See https://github.com/NREL/OpenStudio/issues/3839 for more information.

[joseph-robertson]

Extend the python plugin feature that was implemented in #4600. Specifically:

• [x] OpenStudio measure generates and exports the python plugin file
  • python_plugin.rb
• [ ] OpenStudio measure uses erb templating to render python plugin file
  • python_plugin_2.rb
• [ ] Optionally provide python plugin file with OS handles/names and then FT does replacement
• [ ] Create OS API for populating a plugin template file. See proposed design doc.
• [ ] Use heredocs to eliminate any python indenting issues caused by ruby
  • This can be an update to python_plugin.rb
• [ ] Use system python with non standard libraries (e.g., pandas)
  • Demonstrate sys.path.append and import pandas
  • Optionally wrap PythonPlugin:SearchPaths for adding system python path(s)

@jmarrec @tijcolem

[joseph-robertson]

Another idea mentioned by @DavidGoldwasser, add capability at OSW level for using the plugin. David, can you expand on this?

[joseph-robertson]

Notes from 12/7 meeting:

One issue with the current implementation of PythonPlugin is portability. A single python plugin .py file is not guaranteed to work across multiple models (e.g., zone names are different).

Approach 1 (A) To address this, we could use erb templating. The gist of this approach would be to pass a erb .py template file into PythonPluginInstance pre-substitution, and then make the substitutions based on contents in model. (jinja templating for python?) Update: Instead of passing template file into PythonPluginInstance, is the burden on user to do the rendering in the measure itself?

(B) The optional extension of this approach would be to wait until all measures are applied before making any substitutions. We could potentially create a new "EMS" class of measures that are called after Model measures.

We plan to prototype (A) from above. Update: see https://github.com/NREL/OpenStudio-resources/pull/185 for a demonstration.

Approach 2 Update E+ to load model on E+ warmup, save as a global, etc. Then you could access model by something like state.model() or state.osmodel() from the python plugin file.

[shorowit]

Would be nice to show how this works in the context of a python OpenStudio measure too. I assume it's a lot simpler.

(Personally, I would be okay with the E+ python plugin only being available via python OpenStudio measures if that significantly reduces the development effort.)