4. Getting Involved

This project is hosted in github. To provide feedback about bugs and errors or questions and requests for enhancements, use github’s Issue-tracker.

4.1. Sources & Dependencies

To get involved with development, you need a POSIX environment to fully build it (Linux, OSX or Cygwin on Windows).

First you need to download the latest sources:

$ git clone https://github.com/ankostis/wltp.git wltp.git
$ cd wltp.git

Virtualenv

You may choose to work in a virtualenv (isolated Python environment), to install dependency libraries isolated from system’s ones, and/or without admin-rights (this is recommended for Linux/Mac OS).

Attention

If you decide to reuse stystem-installed packages using --system-site-packages with virtualenv <= 1.11.6 (to avoid, for instance, having to reinstall numpy and pandas that require native-libraries) you may be bitten by bug #461 which prevents you from upgrading any of the pre-installed packages with pip.

Liclipse IDE

Within the sources there are two sample files for the comprehensive LiClipse IDE:

  • eclipse.project
  • eclipse.pydevproject

Remove the eclipse prefix, (but leave the dot()) and import it as “existing project” from Eclipse’s File menu.

Another issue is caused due to the fact that LiClipse contains its own implementation of Git, EGit, which badly interacts with unix symbolic-links, such as the docs/docs, and it detects working-directory changes even after a fresh checkout. To workaround this, Right-click on the above file Properties ‣ Team ‣ Advanced ‣ Assume Unchanged

Then you can install all project’s dependencies in `development mode using the setup.py script:

$ python setup.py --help                           ## Get help for this script.
Common commands: (see '--help-commands' for more)

  setup.py build      will build the package underneath 'build/'
  setup.py install    will install the package

Global options:
  --verbose (-v)      run verbosely (default)
  --quiet (-q)        run quietly (turns verbosity off)
  --dry-run (-n)      don't actually do anything
...

$ python setup.py develop                           ## Also installs dependencies into project's folder.
$ python setup.py build                             ## Check that the project indeed builds ok.

You should now run the test-cases (see ref:metrics, below) to check that the sources are in good shape:

$ python setup.py test

Note

The above commands installed the dependencies inside the project folder and for the virtual-environment. That is why all build and testing actions have to go through python setup.py some_cmd.

If you are dealing with installation problems and/or you want to permantly install dependant packages, you have to deactivate the virtual-environment and start installing them into your base python environment:

$ deactivate
$ python setup.py develop

or even try the more permanent installation-mode:

$ python setup.py install                # May require admin-rights

4.2. Development procedure

For submitting code, use UTF-8 everywhere, unix-eol(LF) and set git --config core.autocrlf = input.

The typical development procedure is like this:

  1. Modify the sources in small, isolated and well-defined changes, i.e. adding a single feature, or fixing a specific bug.

  2. Add test-cases “proving” your code.

  3. Rerun all test-cases to ensure that you didn’t break anything, and check their coverage remain above 80%:

    $ python setup.py nosetests --with-coverage --cover-package wltp.model,wltp.experiment --cover-min-percentage=80

    Tip

    You can enter just: python setup.py test_all instead of the above cmd-line since it has been aliased in the setup.cfg file. Check this file for more example commands to use during development.

  4. If you made a rather important modification, update also the Changes file and/or other documents (i.e. README.rst). To see the rendered results of the documents, issue the following commands and read the result html at build/sphinx/html/index.html:

    $ python setup.py build_sphinx                  # Builds html docs
$ python setup.py build_sphinx -b doctest       # Checks if python-code embeded in comments runs ok.

  5. If there are no problems, commit your changes with a descriptive message.

  6. Repeat this cycle for other bugs/enhancements.

  7. When you are finished, push the changes upstream to github and make a merge_request. You can check whether your merge-request indeed passed the tests by checking its build-status Integration-build status on the integration-server’s site (TravisCI).

    Hint

    Skim through the small IPython developer’s documentantion on the matter: The perfect pull request

4.3. Specs & Algorithm

This program was implemented from scratch based on this GTR specification (included in the docs/ folder). The latest version of this GTR, along with other related documents can be found at UNECE’s site:

The WLTC-profiles for the various classes in the devtools/data/cycles/ folder were generated from the tables of the specs above using the devtools/csvcolumns8to2.py script, but it still requires an intermediate manual step involving a spreadsheet to copy the table into ands save them as CSV.

Then use the devtools/buildwltcclass.py to construct the respective python-vars into the wltp/model.py sources.

Data-files generated from Steven Heinz’s ms-access vehicle info db-table can be processed with the devtools/preprocheinz.py script.

4.3.1. Cycles

_images/wltc_class1.png _images/wltc_class2.png _images/wltc_class3a.png _images/wltc_class3b.png

4.4. Tests, Metrics & Reports

In order to maintain the algorithm stable, a lot of effort has been put to setup a series of test-case and metrics to check the sanity of the results and to compare them with the Heinz-db tool or other datasets included in the project. These tests can be found in the wltp/test/ folders.

Additionally, below are auto-generated representative diagrams with the purpose to track the behavior and the evolution of this project.

You can reuse the plotting code here for building nice ipython-notebooks reports, and (optionally) link them in the wiki of the project (see section above). The actual code for generating diagrams for these metrics is in wltp.plots and it is invoked by scripts in the docs/pyplot/ folder.

4.4.1. Mean Engine-speed vs PMR

First the mean engine-speed of vehicles are compared with access-db tool, grouped by PMRs:

(Source code)

Both tools generate the same rough engine speeds. There is though a trend for this project to produce lower rpm’s as the PMR of the vehicle increases. But it is difficult to tell what each vehicle does isolated.

The same information is presented again but now each vehicle difference is drawn with an arrow:

(Source code)

It can be seen now that this project’s calculates lower engine-speeds for classes 1 & 3 but the trend is reversed for class 2.

4.4.2. Mean Engine-speed vs Gears

Below the mean-engine-speeds are drawn against the mean gear used, grouped by classes and class-parts (so that, for instance, a class3 vehicle corresponds to 3 points on the diagram):

(Source code)

(Source code)

(Source code)

4.5. Development team

  • Author:
    • Kostis Anagnostopoulos
  • Contributing Authors:
    • Heinz Steven (test-data, validation and review)
    • Georgios Fontaras (simulation, physics & engineering support)
    • Alessandro Marotta (policy support)

4.6. Discussion