Skip to content

Dev ~ Architecture Notes

Jump to bottom
Kevin McElwee edited this page Oct 18, 2018 · 6 revisions

Tests

Every .py file shall define a _tests() function. When that file is executed from the command line (e.g. python /omf/omf/feeder.py) the tests shall execute.

To run all the tests in the project, python /omf/omf/runAllTests.py

Coding Style Guide

  1. Spaces or tabs? Tabs.
  2. Single quotes or double? Single.
  3. Module, function, class, etc. names? camelCase for all names. InitialCapsCase for class names.
  4. Zero trailing spaces.
  5. Every function, module and class needs a docstring inside triple quotes.
  6. Remove the #!/bin/python because nobody's running this stuff as shell scripts.
  7. Use unicode literals e.g. & # x2192; instead of →.
  8. Variable name lengths? Aim for shorter. Do not use uncommon abbreviations. This is tricky and a judgment call. Then document the conventions and clean up the code to match them.
  9. Indenting dictionaries or long lists? See longDict below.
  10. Nesting functions: try not to do it. This is tricky and a judgment call.
longDict = {
    'item':3,
    'other': {
        'x':3
        'z':2 },
    ...
    'end':6 }

Library Overview

/omf/calibration/ - Code for calibrating load models on feeders to SCADA data.

/omf/data/ - All the OMF data used for testing. Feeders, users, weather, saved model results, etc., etc. In the omf.coop production system, this data is kept on a database. Each data objects is a json file.

/omf/reports/ - Each report takes model output data and turns it into charts and graphs. The html files are templates for rendering via the matching .py.

/omf/running/ - Directory for writing temporary files that processes need. When we run Gridlab, for example, each run gets its own directory in here. After the execution is complete, if there are no errors, we persist the results we need to disk/database and then delete the working directory.

/omf/scratch/ - Prototypes and tests for future development.

/omf/solvers/ - Python libraries to execute different models. As on 1 Jan 2014 includes NREL's SAM and Gridlab-D. We also keep binaries for the models in here so we know exactly what code we executed to get what results.

/omf/static/ - Static resources for our web app: images, icons, css, etc.

/omf/studies/ - Each study module defines user inputs and expected outputs for simulating a certain kind of behavior. So, for example, there's gridlabd.py that contains functions for specifying things needed from the user, setting up gridlab runs for the solver library, getting that into a glm with the right objects, and turning the output from the resulting bunch of .csv files on disk into clean data for the reporting modules.

/omf/templates/ - HTML templates that are rendered by the web server to provide the web interface.

/omf/uploads/ - User uploads stored here until they get put into the database.

/omf/feeder.py - Code for creating in-memory representations of feeders. Heavily influenced by Gridlab GLM format. Can manipulate feeder objects, graph them, etc.

/omf/milToGridlab.py - Converts a pair of Milsoft Windmil .seq and .std files into a feeder object.

/omf/web.py - The web server code. Each function maps a url (e.g. omf.coop/listAnalayses) to python code that generates the result.

/omf/work.py - Code for sending jobs to the queue so they can be picked up by servers in our production cluster at omf.coop. Also has a mode for running all jobs locally for testing during development.

Clone this wiki locally