Code Monkey home page Code Monkey logo

simbody's Introduction

Simbody Travis Appveyor Codecov

Simbody is a high-performance, open-source toolkit for science- and engineering-quality simulation of articulated mechanisms, including biomechanical structures such as human and animal skeletons, mechanical systems like robots, vehicles, and machines, and anything else that can be described as a set of rigid bodies interconnected by joints, influenced by forces and motions, and restricted by constraints. Simbody includes a multibody dynamics library for modeling motion in generalized/internal coordinates in O(n) time. This is sometimes called a Featherstone-style physics engine.

Simbody provides a C++ API that is used to build domain-specific applications; it is not a standalone application itself. For example, it is used by biomechanists in OpenSim, by roboticists in Gazebo, and for biomolecular research in MacroMoleculeBuilder (MMB). Here's an artful simulation of several RNA molecules containing thousands of bodies, performed with MMB by Samuel Flores:

Sam Flores' Simbody RNA simulation

Read more about Simbody at the Simbody homepage.

Simple example: a double pendulum

Here's some code to simulate and visualize a 2-link chain:

#include "Simbody.h"
using namespace SimTK;
int main() {
    // Define the system.
    MultibodySystem system;
    SimbodyMatterSubsystem matter(system);
    GeneralForceSubsystem forces(system);
    Force::Gravity gravity(forces, matter, -YAxis, 9.8);

    // Describe mass and visualization properties for a generic body.
    Body::Rigid bodyInfo(MassProperties(1.0, Vec3(0), UnitInertia(1)));
    bodyInfo.addDecoration(Transform(), DecorativeSphere(0.1));

    // Create the moving (mobilized) bodies of the pendulum.
    MobilizedBody::Pin pendulum1(matter.Ground(), Transform(Vec3(0)),
            bodyInfo, Transform(Vec3(0, 1, 0)));
    MobilizedBody::Pin pendulum2(pendulum1, Transform(Vec3(0)),
            bodyInfo, Transform(Vec3(0, 1, 0)));

    // Set up visualization.
    system.setUseUniformBackground(true);
    Visualizer viz(system);
    system.addEventReporter(new Visualizer::Reporter(viz, 0.01));

    // Initialize the system and state.
    State state = system.realizeTopology();
    pendulum2.setRate(state, 5.0);

    // Simulate for 20 seconds.
    RungeKuttaMersonIntegrator integ(system);
    TimeStepper ts(system, integ);
    ts.initialize(state);
    ts.stepTo(20.0);
}

Double-pendulum simulation in Simbody

See Simbody's User Guide for a step-by-step explanation of this example.

Features

  • Wide variety of joint, constraint, and force types; easily user-extended.
  • Forward, inverse, and mixed dynamics. Motion driven by forces or prescribed motion.
  • Contact (Hertz, Hunt and Crossley models).
  • Gradient descent, interior point, and global (CMA) optimizers.
  • A variety of numerical integrators with error control.
  • Visualizer, using OpenGL

You want to...


Dependencies

Simbody depends on the following:

  • cross-platform building: CMake 2.8.10 or later (3.1.3 or later for Visual Studio).
  • compiler: Visual Studio 2015, 2017, or 2019 (Windows only), gcc 4.9.0 or later (typically on Linux), Clang 3.4 or later, or Apple Clang (Xcode) 8 or later.
  • linear algebra: LAPACK 3.6.0 or later and BLAS
  • visualization (optional): FreeGLUT, Xi and Xmu
  • API documentation (optional): Doxygen 1.8.6 or later; we recommend at least 1.8.8.

Using Simbody

  • Creating your own Simbody-using project with CMake To get started with your own Simbody-using project, check out the cmake/SampleCMakeLists.txt file.

Installing

Simbody works on Windows, Mac, and Linux. For each operating system, you can use a package manager or build from source. In this file, we provide instructions for 6 different ways of installing Simbody:

  1. Windows: build from source using Microsoft Visual Studio.
  2. Linux or Mac (make): build from source using gcc or Clang with make.
  3. Mac (Homebrew): automated build/install with Homebrew.
  4. Ubuntu/Debian: install pre-built binaries with apt-get.
  5. FreeBSD: install pre-built binaries with pkg.
  6. Windows using MinGW: build from source using MinGW.
  7. Windows/Mac/Linux: install pre-built binaries with the Conda package manager.
  8. Install using vcpkg: download and install simbody using the vcpkg dependency manager

If you use Linux, check Repology to see if your distribution provides a package for Simbody.

These are not the only ways to install Simbody, however. For example, on a Mac, you could use CMake and Xcode.

C++11 and gcc/Clang

Simbody 3.6 and later uses C++11 features (the -std=c++11 flag). Simbody 3.3 and earlier use only C++03 features, and Simbody 3.4 and 3.5 can use either C++03 or C++11; see the SIMBODY_STANDARD_11 CMake variable in these versions. Note that if you want to use the C++11 flag in your own project, Simbody must have been compiled with the C++11 flag as well.

Windows using Visual Studio

Get the dependencies

All needed library dependencies are provided with the Simbody installation on Windows, including linear algebra and visualization dependencies.

  1. Download and install Microsoft Visual Studio, version 2015, 2017, or 2019. The Community edition is free and sufficient.
  • 2015: By default, Visual Studio 2015 does not provide C++ support; when installing, be sure to select Custom, and check Programming Languages > Visual C++ > Common Tools for Visual C++ 2015. If you have already installed Visual Studio without C++ support, simply re-run the installer and select Modify.
  • 2017 and later: In the installer, select the Desktop development with C++ workload.
  • Any other C++ code you plan to use with Simbody should be compiled with the same compiler as used for Simbody.
  1. Download and install CMake, version 3.1.3 or higher.
  2. (optional) If you want to build API documentation, download and install Doxygen, version 1.8.8 or higher.

Download the Simbody source code

  • Method 1: Download the source code from https://github.com/simbody/simbody/releases. Look for the highest-numbered release, click on the .zip button, and unzip it on your computer. We'll assume you unzipped the source code into C:/Simbody-source.
  • Method 2: Clone the git repository.
    1. Get git. There are many options:

    2. Clone the github repository into C:/Simbody-source. Run the following in a Git Bash / Git Shell, or find a way to run the equivalent commands in a GUI client:

       $ git clone https://github.com/simbody/simbody.git C:/Simbody-source
       $ git checkout Simbody-3.7
      
    3. In the last line above, we assumed you want to build a released version. Feel free to change the version you want to build. If you want to build the latest development version ("bleeding edge") of Simbody off the master branch, you can omit the checkout line.

      To see the set of releases and checkout a specific version, you can use the following commands:

       $ git tag
       $ git checkout Simbody-X.Y.Z
      

Configure and generate project files

  1. Open CMake.
  2. In the field Where is the source code, specify C:/Simbody-source.
  3. In the field Where to build the binaries, specify something like C:/Simbody-build, just not inside your source directory. This is not where we will install Simbody; see below.
  4. Click the Configure button.
    1. When prompted to select a generator, in the dropdown for Optional platform for generator, choose x64 to build 64-bit binaries or leave blank to build 32-bit binaries. In older versions of CMake, select a generator ending with Win64 to build 64-bit binaries (e.g., Visual Studio 14 2015 Win64 or Visual Studio 15 2017 Win64), or select one without Win64 to build 32-bit binaries (e.g., Visual Studio 14 2015 or Visual Studio 15 2017).
    2. Click Finish.
  5. Where do you want to install Simbody on your computer? Set this by changing the CMAKE_INSTALL_PREFIX variable. We'll assume you set it to C:/Simbody. If you choose a different installation location, make sure to use yours where we use C:/Simbody below.
  6. Play around with the other build options:
    • BUILD_EXAMPLES to see what Simbody can do. On by default.
    • BUILD_TESTING to ensure your Simbody works correctly. On by default.
    • BUILD_VISUALIZER to be able to watch your system move about! If building remotely, you could turn this off. On by default.
    • BUILD_DYNAMIC_LIBRARIES builds the three libraries as dynamic libraries. On by default. Unless you know what you're doing, leave this one on.
    • BUILD_STATIC_LIBRARIES builds the three libraries as static libraries, whose names will end with _static. Off by default. You must activate either BUILD_DYNAMIC_LIBRARIES, BUILD_STATIC_LIBRARIES, or both.
    • BUILD_TESTS_AND_EXAMPLES_STATIC if static libraries, and tests or examples are being built, creates statically-linked tests/examples. Can take a while to build, and it is unlikely you'll use the statically-linked libraries.
    • BUILD_TESTS_AND_EXAMPLES_SHARED if tests or examples are being built, creates dynamically-linked tests/examples. Unless you know what you're doing, leave this one on.
  7. Click the Configure button again. Then, click Generate to make Visual Studio project files.

Build and install

  1. Open C:/Simbody-build/Simbody.sln in Visual Studio.

  2. Select your desired Solution configuration from the drop-down at the top.

    • Debug: debugger symbols; no optimizations (more than 10x slower). Library and visualizer names end with _d.
    • RelWithDebInfo: debugger symbols; optimized. This is the configuration we recommend.
    • Release: no debugger symbols; optimized. Generated libraries and executables are smaller but not faster than RelWithDebInfo.
    • MinSizeRel: minimum size; optimized. May be slower than RelWithDebInfo or Release.

    You at least want optimized libraries (all configurations but Debug are optimized), but you can have Debug libraries coexist with them. To do this, go through the full installation process twice, once for each configuration.

  3. Build the project ALL_BUILD by right-clicking it and selecting Build.

  4. Run the tests by right-clicking RUN_TESTS and selecting Build. Make sure all tests pass. You can use RUN_TESTS_PARALLEL for a faster test run if you have multiple cores.

  5. (Optional) Build the project doxygen to get API documentation generated from your Simbody source. You will get some warnings if your doxygen version is earlier than Doxygen 1.8.8; upgrade if you can.

  6. Install Simbody by right-clicking INSTALL and selecting Build.

Play around with examples

Within your build in Visual Studio (not the installation):

  1. Make sure your configuration is set to a release configuration (e.g., RelWithDebInfo).
  2. Right click on one of the targets whose name begins with Example - and select Select as Startup Project.
  3. Type Ctrl-F5 to start the program.

Set environment variables and test the installation

If you are only building Simbody to use it with OpenSim, you can skip this section.

  1. Allow executables to find Simbody libraries (.dll's) by adding the Simbody bin/ directory to your PATH environment variable.
    1. In the Start menu (Windows 7 or 10) or screen (Windows 8), search environment.
    2. Select Edit the system environment variables.
    3. Click Environment Variables....
    4. Under System variables, click Path, then click Edit.
    5. Add C:/Simbody/bin; to the front of the text field. Don't forget the semicolon!
  2. Allow Simbody and other projects (e.g., OpenSim) to find Simbody. In the same Environment Variables window:
    1. Under User variables for..., click New....
    2. For Variable name, type SIMBODY_HOME.
    3. For Variable value, type C:/Simbody.
  3. Changes only take effect in newly-opened windows. Close any Windows Explorer or Command Prompt windows.
  4. Test your installation by navigating to C:/Simbody/examples/bin and running SimbodyInstallTest.exe or SimbodyInstallTestNoViz.exe.

Note: Example binaries are not installed for Debug configurations. They are present in the build environment, however, so you can run them from there. They will run very slowly!

Layout of installation

How is your Simbody installation organized?

  • bin/ the visualizer and shared libraries (.dll's, used at runtime).
  • doc/ a few manuals, as well as API docs (SimbodyAPI.html).
  • examples/
    • src/ the source code for the examples.
    • bin/ the examples, compiled into executables; run them! (Not installed for Debug builds.)
  • include/ the header (.h) files; necessary for projects that use Simbody.
  • lib/ "import" libraries, used during linking.
  • cmake/ CMake files that are useful for projects that use Simbody.

Linux or Mac using make

These instructions are for building Simbody from source on either a Mac or on Ubuntu.

Check the compiler version

Simbody uses recent C++ features, that require a modern compiler. Before installing Simbody, check your compiler version with commands like that:

  • g++ --version
  • clang++ --version

In case your compiler is not supported, you can upgrade your compiler.

Upgrading GCC to 4.9 on Ubuntu 14.04

Here are some instructions to upgrade GCC on a Ubuntu 14.04 distribution.

$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install gcc-4.9 g++-4.9

If one wants to set gcc-4.9 and g++-4.9 as the default compilers, run the following command

$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9

Remember that when having several compilers, CMake flags CMAKE_C_COMPILER and CMAKE_CXX_COMPILER can be used to select the ones desired. For example, Simbody can be configured with the following flags:

$ cmake -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9

Get dependencies

On a Mac, the Xcode developer package gives LAPACK and BLAS to you via the Accelerate framework. Mac's come with the visualization dependencies.

On Ubuntu, we need to get the dependencies ourselves. Open a terminal and run the following commands.

  1. Get the necessary dependencies: $ sudo apt-get install cmake liblapack-dev.
  2. If you want to use the CMake GUI, install cmake-qt-gui.
  3. For visualization (optional): $ sudo apt-get install freeglut3-dev libxi-dev libxmu-dev.
  4. For API documentation (optional): $ sudo apt-get install doxygen.

LAPACK version 3.6.0 and higher may be required for some applications (OpenSim). LAPACK can be downloaded from http://www.netlib.org/lapack/, and compiled using the following method. It is sufficient to set LD_LIBRARY_PATH to your LAPACK install prefix and build Simbody using the -DBUILD_USING_OTHER_LAPACK:PATH=/path/to/liblapack.so option in cmake.

cmake ../lapack-3.6.0 -DCMAKE_INSTALL_PREFIX=/path/to/new/lapack/ -DCMAKE_BUILD_TYPE=RELEASE -DBUILD_SHARED_LIBS=ON
make
make install

Get the Simbody source code

There are two ways to get the source code.

  • Method 1: Download the source code from https://github.com/simbody/simbody/releases. Look for the highest-numbered release, click on the .zip button, and unzip it on your computer. We'll assume you unzipped the source code into ~/simbody-source.
  • Method 2: Clone the git repository.
    1. Get git.

      • Mac: You might have it already, especially if you have Xcode, which is free in the App Store. If not, one method is to install Homebrew and run brew install git in a terminal.
      • Ubuntu: run sudo apt-get install git in a terminal.
    2. Clone the github repository into ~/simbody-source.

       $ git clone https://github.com/simbody/simbody.git ~/simbody-source
       $ git checkout Simbody-3.7
      
    3. In the last line above, we assumed you want to build a released version. Feel free to change the version you want to build. If you want to build the latest development version ("bleeding edge") of Simbody off the master branch, you can omit the checkout line.

      To see the set of releases and checkout a specific version, you can use the following commands:

       $ git tag
       $ git checkout Simbody-X.Y.Z
      

Configure and generate Makefiles

  1. Create a directory in which we'll build Simbody. We'll assume you choose ~/simbody-build. Don't choose a location inside ~/simbody-source.

     $ mkdir ~/simbody-build
     $ cd ~/simbody-build
    
  2. Configure your Simbody build with CMake. We'll use the cmake command but you could also use the interactive tools ccmake or cmake-gui. You have a few configuration options to play with here.

    • If you don't want to fuss with any options, run:

        $ cmake ~/simbody-source
      
    • Where do you want to install Simbody? By default, it is installed to /usr/local/. That's a great default option, especially if you think you'll only use one version of Simbody at a time. You can change this via the CMAKE_INSTALL_PREFIX variable. Let's choose ~/simbody:

        $ cmake ~/simbody-source -DCMAKE_INSTALL_PREFIX=~/simbody
      
    • Do you want the libraries to be optimized for speed, or to contain debugger symbols? You can change this via the CMAKE_BUILD_TYPE variable. There are 4 options:

      • Debug: debugger symbols; no optimizations (more than 10x slower). Library and visualizer names end with _d.
      • RelWithDebInfo: debugger symbols; optimized. This is the configuration we recommend.
      • Release: no debugger symbols; optimized. Generated libraries and executables are smaller but not faster than RelWithDebInfo.
      • MinSizeRel: minimum size; optimized. May be slower than RelWithDebInfo or Release.

      You at least want optimized libraries (all configurations but Debug are optimized), but you can have Debug libraries coexist with them. To do this, go through the full installation process twice, once for each configuration. It is typical to use a different build directory for each build type (e.g., ~/simbody-build-debug and ~/simbody-build-release).

    • There are a few other variables you might want to play with:

      • BUILD_EXAMPLES to see what Simbody can do. On by default.
      • BUILD_TESTING to ensure your Simbody works correctly. On by default.
      • BUILD_VISUALIZER to be able to watch your system move about! If building on a cluster, you could turn this off. On by default.
      • BUILD_DYNAMIC_LIBRARIES builds the three libraries as dynamic libraries. On by default.
      • BUILD_STATIC_LIBRARIES builds the three libraries as static libraries, whose names will end with _static.
      • BUILD_TESTS_AND_EXAMPLES_STATIC if tests or examples are being built, creates statically-linked tests/examples. Can take a while to build, and it is unlikely you'll use the statically-linked libraries.
      • BUILD_TESTS_AND_EXAMPLES_SHARED if tests or examples are being built, creates dynamically-linked tests/examples. Unless you know what you're doing, leave this one on.

      You can combine all these options. Here's another example:

        $ cmake ~/simbody-source -DCMAKE_INSTALL_PREFIX=~/simbody -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_VISUALIZER=off
      

Build and install

  1. Build the API documentation. This is optional, and you can only do this if you have Doxygen. You will get warnings if your doxygen installation is a version older than Doxygen 1.8.8.

     $ make doxygen
    
  2. Compile. Use the -jn flag to build using n processor cores. For example:

     $ make -j8
    
  3. Run the tests.

     $ ctest -j8
    
  4. Install. If you chose CMAKE_INSTALL_PREFIX to be a location which requires sudo access to write to (like /usr/local/, prepend this command with a sudo .

     $ make -j8 install
    

Just so you know, you can also uninstall (delete all files that CMake placed into CMAKE_INSTALL_PREFIX) if you're in ~/simbody-build.

$ make uninstall

Play around with examples

From your build directory, you can run Simbody's example programs. For instance, try:

    $ ./ExamplePendulum

Set environment variables and test the installation

If you are only building Simbody to use it with OpenSim, you can skip this section.

  1. Allow executables to find Simbody libraries (.dylib's or so's) by adding the Simbody lib directory to your linker path. On Mac, most users can skip this step.

    • If your CMAKE_INSTALL_PREFIX is /usr/local/, run:

        $ sudo ldconfig
      
    • If your CMAKE_INSTALL_PREFIX is neither /usr/ nor /usr/local/ (e.g., ~/simbody'):

      • Mac:

          $ echo 'export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:~/simbody/lib' >> ~/.bash_profile
        
      • Ubuntu:

          $ echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/simbody/lib/x86_64-linux-gnu' >> ~/.bashrc
        

      These commands add a line to a configuration file that is loaded every time you open a new terminal. If using Ubuntu, you may need to replace x86_64-linux-gnu with the appropriate directory on your computer.

  2. Allow Simbody and other projects (e.g., OpenSim) to find Simbody. Make sure to replace ~/simbody with your CMAKE_INSTALL_PREFIX.

    • Mac:

        $ echo 'export SIMBODY_HOME=~/simbody' >> ~/.bash_profile
      
    • Ubuntu:

        $ echo 'export SIMBODY_HOME=~/simbody' >> ~/.bashrc
      
  3. Open a new terminal.

  4. Test your installation:

     $ cd ~/simbody/share/doc/simbody/examples/bin
     $ ./SimbodyInstallTest # or ./SimbodyInstallTestNoViz
    

Layout of installation

The installation creates the following directories in CMAKE_INSTALL_PREFIX. The directory [x86_64-linux-gnu] only exists if you did NOT install to /usr/local/ and varies by platform. Even in that case, the name of your directory may be different.

  • include/simbody/ the header (.h) files; necessary for projects that use Simbody.
  • lib/[x86_64-linux-gnu]/ shared libraries (.dylib's or .so's).
    • cmake/simbody/ CMake files that are useful for projects that use Simbody.
    • pkgconfig/ pkg-config files useful for projects that use Simbody.
    • simbody/examples/ the examples, compiled into executables; run them! (Not installed for Debug builds.)
  • libexec/simbody/ the simbody-visualizer executable.
  • share/doc/simbody/ a few manuals, as well as API docs (SimbodyAPI.html).
    • examples/src source code for the examples.
    • examples/bin symbolic link to the runnable examples.

Mac and Homebrew

If using a Mac and Homebrew, the dependencies are taken care of for you.

Install

  1. Install Homebrew.

  2. Open a terminal.

  3. Add the Open Source Robotics Foundation's list of repositories to Homebrew:

    $ brew tap osrf/simulation
    
  4. Install the latest release of Simbody.

    $ brew install simbody
    

    To install from the master branch instead, append --HEAD to the command above.

Where is Simbody installed?

Simbody is now installed to /usr/local/Cellar/simbody/<version>/, where <version> is either the version number (e.g., 3.6.1), or HEAD if you specified --HEAD above.

Some directories are symlinked (symbolically linked) to /usr/local/, which is where your system typically expects to find executables, shared libraries (.dylib's), headers (.h's), etc. The following directories from the Simbody installation are symlinked:

  • include/simbody -> /usr/local/include/simbody
  • lib -> /usr/local/lib
  • share/doc/simbody -> /usr/local/share/doc/simbody

Layout of installation

What's in the /usr/local/Cellar/simbody/<version>/ directory?

  • include/simbody/ the header (.h) files; necessary for projects that use Simbody.
  • lib/ shared libraries (.dylib's), used at runtime.
    • cmake/simbody/ CMake files that are useful for projects that use Simbody.
    • pkgconfig/ pkg-config files useful for projects that use Simbody.
    • simbody/examples/ the examples, compiled into executables; run them! (Not installed for Debug builds.)
  • libexec/simbody/ the simbody-visualizer executable.
  • share/doc/simbody/ a few manuals, as well as API docs (SimbodyAPI.html).
    • examples/src source code for the examples.
    • examples/bin symbolic link to executable examples.

Ubuntu and apt-get

Starting with Ubuntu 15.04, Simbody is available in the Ubuntu (and Debian) repositories. You can see a list of all simbody packages for all Ubuntu versions at the Ubuntu Packages website. The latest version of Simbody is usually not available in the Ubuntu repositories; the process for getting a new version of Simbody into the Ubuntu repositories could take up to a year.

Install

  1. Open a terminal and run the following command:

     $ sudo apt-get install libsimbody-dev simbody-doc
    

Layout of installation

Simbody is installed into the usr/ directory. The directory [x86_64-linux-gnu] varies by platform.

  • usr/include/simbody/ the header (.h) files; necessary for projects that use Simbody.
  • usr/lib/[x86_64-linux-gnu] shared libraries (.so's).
    • cmake/simbody/ CMake files that are useful for projects that use Simbody.
    • pkgconfig/ pkg-config files useful for projects that use Simbody.
  • usr/libexec/simbody/ the simbody-visualizer executable.
  • usr/share/doc/simbody/ a few manuals, as well as API docs (SimbodyAPI.html).
    • examples/src source code for the examples.
    • examples/bin symbolic link to executable examples.

FreeBSD and pkg

Simbody is available via the FreeBSD package repository.

Install

  1. Open a terminal and run the following command:

     $ sudo pkg install simbody
    

Windows using MinGW

Warning: The MinGW generation and build is experimental!

This build is still experimental, because of :

  • the various MinGW versions available (Thread model, exception mechanism)
  • the compiled libraries Simbody depends on (Blas, Lapack and optionnaly glut).

Below are three sections that gives a list of supported versions, command line instructions, and reasons why is it not so obvious to use MinGW.

Supported MinGW versions

If you do not want to go into details, you need a MinGW version with :

  • a Posix thread model and Dwarf exception mechanism on a 32 bit computer
  • a Posix thread model and SJLJ exception mechanism on a 64 bit computer

Other versions are supported with additional configurations.

The table below lists the various versions of MinGW versions tested:

OS Thread Exception Comment URL
1 64 Bits Posix SJLJ All features supported, all binary included (Recommended version) MinGW64 GCC 5.2.0
2 64 Bits Posix SEH Needs to be linked against user's Blas and Lapack MinGW64 GCC 5.2.0
3 32 Bits Posix Dwarf No visualization, all binary included MinGW64 GCC 5.2.0
4 32 Bits Posix SJLJ No visualization, needs to be linked against user's Blas and Lapack MinGW64 GCC 5.2.0

We recommend to use the first configuration where all features are supported and does not need additional libraries to compile and run. The URL allows to download directly this version. The second version needs to be linked against user's Blas and Lapack (A CLI example is given below). Blas and Lapack sources can be downloaded from netlib. For the 3rd and 4th versions that run that target a 32 bit behaviour, visualization is not possible for the time being. (It is due to a compile and link problem with glut). Moreover for the 4th one, one needs to provide Blas and Lapack libraries.

Please note that only Posix version of MinGW are supported.

If your version is not supported, CMake will detect it while configuring and stops.

Instructions

Below are some examples of command line instructions for various cases. It is assumed you are running commands from a build directory, that can access Simbody source with a command cd ..\simbody.

It is recommended to specify with the installation directory with flag CMAKE_INSTALL_PREFIX (e.g. -DCMAKE_INSTALL_PREFIX="C:\Program Files\Simbody"). If not used, the installation directory will be C:\Program Files (x86)\Simbody on a 64 bit computer. This might be confusing since it is the 32 bit installation location.

Example of instructions where one uses Blas and Lapack libraries provided (to be used in a Windows terminal, where MinGW is in the PATH):

rem CMake configuration
cmake ..\simbody -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Program Files\Simbody"
rem Compilation
mingw32-make
rem Test
mingw32-make test
rem Installation
mingw32-make install

Example of instructions where one uses Blas and Lapack libraries provided (to be used in a Windows terminal, where MinGW is NOT in the PATH):

rem Variable and path definition
set CMAKE="C:\Program Files\CMake\bin\cmake.exe"
set MinGWDir=C:\Program Files\mingw-w64\i686-5.2.0-posix-sjlj-rt_v4-rev0\mingw32
set PATH=%MinGWDir%\bin;%MinGWDir%\i686-w64-mingw32\lib
rem CMake configuration
%CMAKE% ..\simbody -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ^
 -DCMAKE_INSTALL_PREFIX="C:\Program Files\Simbody" ^
 -DCMAKE_C_COMPILER:PATH="%MinGWDir%\bin\gcc.exe" ^
 -DCMAKE_CXX_COMPILER:PATH="%MinGWDir%\bin\g++.exe" ^
 -DCMAKE_MAKE_PROGRAM:PATH="%MinGWDir%\bin\mingw32-make.exe"
rem Compilation
mingw32-make
rem Test
mingw32-make test
rem Installation
mingw32-make install

Example of instructions where one uses Blas and Lapack libraries provided (to be used in a MSYS terminal with MinGW in the PATH):

# CMake configuration
cmake ../simbody -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Program Files\Simbody"
# Compilation
make
# Test
make test
# Installation
make install

Example of instructions where one provides our own Blas and Lapack libraries (to be used in a MSYS terminal with MinGW in the PATH):

# CMake configuration
cmake ../simbody -G"MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX="C:\Program Files\Simbody" \
-DCMAKE_C_COMPILER:PATH="C:\Program Files\mingw-w64\i686-5.2.0-posix-sjlj-rt_v4-rev0\mingw32\bin\gcc.exe" \
-DCMAKE_CXX_COMPILER:PATH="C:\Program Files\mingw-w64\i686-5.2.0-posix-sjlj-rt_v4-rev0\mingw32\bin\g++.exe" \
-DBUILD_USING_OTHER_LAPACK:PATH="C:\Program Files\lapack-3.5.0\bin\liblapack.dll;C:\Program Files\lapack-3.5.0\bin\libblas.dll"
make
# Test
make test
# Installation
make install

MinGW details

This paragraph explains the reason why one can not use any MinGW version.

MinGW is available with two thread models :

  • Win32 thread model
  • Posix thread model

One has to use the Posix thread model, since all thread functionalities (e.g. std:mutex) are not implemented.

To ease building on Windows, Simbody provides compiled libraries for Blas and Lapack :

  • On Windows 32 Bits, these were compiled with a Dwarf exception mechanism,
  • On Windows 64 Bits, these were compiled with a SJLJ exception mechanism.

If one chooses a MinGW compilation, we need to respect this exception mechanism. A program can not rely on both mechanisms. This means that if we want to use the compiled libraries, our MinGW installation should have the same exception mechanism. Otherwise, we need to provide our own Blas and Lapack libraries.

To see which exception mechanism is used, user can look at dlls located in the bin directory of MinGW. The name of mechanism is present in the file libgcc_XXXX.dll, where XXXX can be dw, seh or sjlj. For some MinGW versions, this information is also available by looking at the result of gcc --version.

CMake will check the version of your MinGW, and if the exception mechanism is different, then the configuration stops because of this difference. If one provides Blas and Lapack libraries with the CMake variable BUILD_USING_OTHER_LAPACK, compilation with MinGW is always possible.

Windows, Mac, and Linux Using Conda

Conda is a cross platform package manager that can be used to install Simbody on Windows, Mac, or Linux. To install Simbody using Conda you must first install Miniconda or Anaconda. Either of these will provide the conda command which can be invoked at the command line to install Simbody from the Conda Forge channel as follows:

$ conda install -c conda-forge simbody

This command will install Simbody (both the libraries and headers) into the Miniconda or Anaconda installation directory as per the standard layout for each of the operating systems described above. The Conda Forge Simbody recipe can be found in Conda Forge's feedstock repository.

Installing simbody(vcpkg)

You can download and install simbody using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install simbody

The simbody port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Acknowledgments

We are grateful for past and continuing support for Simbody's development in Stanford's Bioengineering department through the following grants:

  • NIH U54 GM072970 (Simulation of Biological Structures)
  • NIH U54 EB020405 (Mobilize Center)
  • NIH R24 HD065690 (Simulation in Rehabilitation Research)
  • OSRF subcontract 12-006 to DARPA HR0011-12-C-0111 (Robotics Challenge)

Prof. Scott Delp is the Principal Investigator on these grants and Simbody is used extensively in Scott's Neuromuscular Biomechanics Lab as the basis for the OpenSim biomechanical simulation software application for medical research.

simbody's People

Contributors

adamkewley avatar andreasscholz avatar antoinefalisse avatar aymanhab avatar carmichaelong avatar chrisdembia avatar clonedeath avatar cmbruns avatar cpizzolato avatar elen4 avatar fcanderson avatar gjacquenot avatar guillaumejacquenot avatar j-rivero avatar jmwang avatar kingchurch avatar klshrinidhi avatar mjhmilla avatar peastman avatar radmer avatar scpeters avatar serval2412 avatar sherm1 avatar stavness avatar tbeu avatar thomasklau avatar tkuchida avatar twdorn avatar xantares avatar yurivict avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

simbody's Issues

where should Simbody examples be installed?

This is a follow-on to pr #64.
@j-rivero, @scpeters, @thomas-moulard
The Simbody installation includes some example programs, provided in both source and binary form. On Windows these end up in <SimbodyInstallDir>/examples/{bin,src,...} which is adequate there. However I don't think they are going to the right place on Mac and Linux, where the installed files are spread around rather than being concentrated in a single directory. On Mac they end up in /usr/local/examples/.... I don't know what happens on Linux.

Where should these go? Is there a GnuInstallDirs convention for examples?

Visualizer won't build on OS X Mavericks (10.9): glut is gone?

I was unable to build simbody-visualizer on Mavericks. It gave a bunch of messages indicating that glut was deprecated, then failed to link. It built fine if I turned off building of the visualizer (in CMake), and then passed all tests.

@scpeters have you had any luck getting the visualizer to build, or are you disabling that also? Is there any hope for getting glut or freeglut to work in 10.9?

Plan for a new simbody release (3.4)?

Dear Simbody team:

Is there any plan to release a new version of simbody? I was looking to ask debian for an official submission but it would be great to release an official version with all the latest changes we did to the build system and examples.

Thanks.

P.D: my best wishes for this new year and thanks for all the collaboration you have done during the 2013 :)

Line & FreeLine mobilizers in Euler angle mode should use 2 angles, not 3

(Transferred from SimTK, original filed 2010-03-8 as bug 1072)

Terminal or free bodies that are "linear" in the sense that all their mass is
arranged along a line with no rotational inertia about that line (like O2 or
CO2 molecules) need special handling. They are not fully general rigid bodies
and must not have a degree of rotational freedom about the inertialess axis.
Simbody provides "Line" (2 rotational dofs) and "FreeLine" (2 rotations + 3
translations) mobilizers to model these reduced bodies.

Despite having only 2 rotational dofs, to avoid singularities during dynamic
simulation, the orientation must be represented by a 4-element quaternion. When
modeling with setUseEulerAngles(true), all quaternion-using mobilizers switch
to Euler angles. Currently they all switch to three Euler angles, but these
2-dof mobilizers should use only two Euler angles, equivalent to azimuth and
elevation. The current approach can cause some obscure problems when used with
optimizers because there is a hidden constraint among the three angles, but
the use-Euler-angles mode is used specifically to avoid constraints among the
q's.

Line and FreeLine should thus use 4 q's in dynamics mode and 2 q's in statics
(Euler angle) mode.

Rotation matrices should be re-orthogonalized for long chains

(Transferred from SimTK.org. Original filed 2011-10-28 as bug 1556)

Sam Flores was simulating a large RNA molecule, basically 11,000 bodies in a
long chain of pin joints. When the inertia of a body near the end of the chain
was transformed from its local frame to ground, it tripped a bug catcher which
complained that the inertia diagonals failed to satisfy the triangle inequality.
The error was around 1e-10 and was caused by the rotation R_GB containing errors
around 1e-9, for example column norms and determinant were all about 1+1e-9
instead of 1.

Although some numerical errors are inevitable as rotations are propagated along
a long chain, Rotations should be re-orthogonalized so that they are always
good Rotation matrices even if there is some error in the orientations they
represent.

Workaround checked in to Simbody 2.3 and 3.0 was to loosen the allowable inertia
diagonal slop from 1e-14 to about 1e-8.

isSameMobilizedBody() doesn't work as documented

MobilizedBody::isSameMobilizedBody() is supposed to compare two MobilizedBody handles to see if they both point to the same implementation object. Instead, it is comparing the handle addresses so only returns true if they are the same handles, leading to false negatives when a handle is used as a reference to an object owned elsewhere.

Optimizer's setDifferentiatorMethod() ignored after useNumericalGradient() has been called

Apparently when Optimizer::useNumericalGradient() and probably ...Jacobian() are called they record the currently-active Differentiator method. Subsequent attempts to change it produce no error but have no effect.

This should at least be fixed in the documentation, better to generate an error, and better still to allow it to take effect whenever it makes logical sense.

Karianne Bergen got bit by this working in OpenSim 3.1.

Using a "develop" branch

I think @sherm1 decided a few months ago that, given the number of developers on simbody, it makes sense to only use a master branch, and to not have a "develop" branch. But I think maybe we should consider using a develop branch.

I'm just thinking of the way I obtain software from GitHub: I always expect that master will be stable. I think others have that expectation too.

Simbody cmake config not self consistent; breaks builds of dependent systems

When building from source the artifacts seem to get dumped in which ever directory cmake is called from. This seems to break the assumptions of ./cmake/SimbodyConfig.cmake.in which look for libraries in ./Simbody/lib if it finds include files in ./Simbody/include

Furthermore the packaged version of libsimbody also has a similar problem as it gets installed to /usr/lib/x86_64-linux-gnu/ and at best looks in /usr/lib.

It seems that SimbodyConfig.cmake.in is in need of repair, and CMakeLists.txt may need some as well.

I can probably fix this if there is agreement that this is a need and the fix is likely to be accepted.

Force::Custom::Implementation should provide access to containing subsystem

(Transferred from SimTK.org. Original filed 2011-03-10 as feature request #1426)

From within a force element it is useful to get access to the containing
ForceSubsystem (e.g. for allocating state variables). The internal ForceImpl
class provides getForceSubsystem() for that purpose but the user-extensible
Force::Custom::Implementation class does not.

Mobilizer default geometry not updated when mobilizer is reversed

(Transferred from SimTK.org. Filed by Ajay Seth 2009-04-09)

Looking at the default decorative geometry of the ellipsoid, it does not appear to change sense- that is it is always affixed to the parent, when in the reverse case it should be affixed to the body.

Need a way to map back from DecorativeGeometry to the associated object

@aymanhab wants to be able to select in the OpenSim GUI geometry that results from DecorativeGeometry objects, and then map those back to the OpenSim objects to which the user meant to refer. We decided that the DecorativeGeometry objects should maintain a "user reference pointer", that is, a void* that means something to the person who created it. Then a selection that identifies a DecorativeGeometry can return the associated pointer which can be mapped back to something meaningful.

Tag for simbody 3.3 release

It would be nice to tag the simbody 3.3 release. I believe the current head (3252208) was used to make the deb at packages.osrfoundation.org.

Distance (Rod) constraint is poorly scaled

(Transferred from SimTK -- original filed 2008-02-19 as bug 562)

The current implementation of Constraint::Rod "cleverly" uses the square of
the distance constraint which is cheaper to compute and produces beautiful 1st
and 2nd time derivatives. However, this results in the position constraint error
having units which are not length like the other translational constraints.
In fact they differ from length by a factor of roughly 2*d where d is the rod
length.

The effect of this problem is that if d differs a lot from 1 the constraint
will be enforced either too tightly (if d>>1) or too loosely (d<<1).

A quick fix would be to switch to using the square root form of the distance
constraint and its derivatives. Then the current default scaling of 1 is good.

A better longer term fix would be to add an interface for the concrete constraints
to implement which would allow each constraint to specify is own scaling default.
Normally a constraint would be scaled by 1, here it would be scaled by 1/(2d)
or something like that. Then the cheaper and more beautiful form could be used
with no ill effects.

Optimize performance of locked mobilizers

Currently when mobilizers are locked the mobility force elements on the mobilizers are still active. Can we optimize the locked mobilizer performance by automatically disabling all force elements on the mobilizers and re-enabling them when the mobilizers are unlocked ? The ideal goal for performance is to treat locked mobilizers as rigid bodies relative to their parent.

LD_LIBRARY_PATH shouldn't be required

It is odd that you have to set the LD_LIBRARY_PATH before running code which includes simbody. I've installed many libraries from source that set this up properly for various linux distributions. I'm not sure how to fix it yet, but I think it is worth noting an issue about this.

Some pages about this stuff:

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
http://www.cc.dtu.dk/?page_id=304

From the first document:

"LD_LIBRARY_PATH is handy for development and testing, but shouldn't be modified by an installation process for normal use by normal users"

Compilation errors with libc++ (Mac OSX 10.9 Mavericks)

The new version of Mac OSX uses libc++ by default, rather than libstdc++, which causes a number of compilation errors. For example, when building TestVectorMath, it gives several complaints about operator overloading and templates:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3585:17: error: 
      no viable overloaded '+='
            __m += __delta;
            ~~~ ^  ~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3743:5: note: in
      instantiation of function template specialization 'std::__1::__sort<std::__1::__less<double, double> &,
      SimTK::VectorIterator<double, SimTK::VectorBase<double> > >' requested here
    __sort<_Comp_ref>(__first, __last, __comp);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3752:5: note: in
      instantiation of function template specialization 'std::__1::sort<SimTK::VectorIterator<double, SimTK::VectorBase<double>
      >, std::__1::__less<double, double> >' requested here
    _VSTD::sort(__first, __last, __less<typename iterator_traits<_RandomAccessIterator>::value_type>());
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__config:300:15: note: 
      expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/internal/VectorMath.h:358:5: note: in instantiation of
      function template specialization 'std::__1::sort<SimTK::VectorIterator<double, SimTK::VectorBase<double> > >' requested
      here
    std::sort(temp.begin(), temp.end());
    ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp:331:20: note: in instantiation of function template
      specialization 'SimTK::sort<double>' requested here
        testVector(sort(vector), expectedVec);
                   ^

Full console output:

$ make TestVectorMath
...
[100%] Building CXX object SimTKcommon/tests/CMakeFiles/TestVectorMath.dir/TestVectorMath.cpp.o
cd /tmp/simbody-Fnqf/simbody-Simbody-3.3/build/SimTKcommon/tests && /usr/local/Library/ENV/4.3/clang++   -DSimTK_SIMBODY_AUTHORS=\"Michael.Sherman_Peter.Eastman\" -DSimTK_SIMBODY_COPYRIGHT_YEARS=\"2005-13\" -DSimTK_SIMBODY_SVN_REVISION="\"Unversioned directory\"" -DSimTK_SimTKCOMMON_AUTHORS=\"Michael.Sherman_Peter.Eastman\" -DSimTK_SimTKCOMMON_COPYRIGHT_YEARS=\"2005-10\" -DSimTK_SimTKCOMMON_LIBRARY_NAME=SimTKcommon -DSimTK_SimTKCOMMON_MAJOR_VERSION=3 -DSimTK_SimTKCOMMON_MINOR_VERSION=3 -DSimTK_SimTKCOMMON_PATCH_VERSION=0 -DSimTK_SimTKCOMMON_SVN_REVISION="\"Unversioned directory\"" -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/Platform/Mac/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Scalar/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/SmallMatrix/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Mechanics/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/BigMatrix/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Geometry/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Simulation/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Random/include -I/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/Polynomial/include    -o CMakeFiles/TestVectorMath.dir/TestVectorMath.cpp.o -c /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp:24:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon.h:32:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/basics.h:38:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/internal/common.h:234:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/complex:247:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/sstream:174:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ostream:130:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:434:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3585:17: error: 
      no viable overloaded '+='
            __m += __delta;
            ~~~ ^  ~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3743:5: note: in
      instantiation of function template specialization 'std::__1::__sort<std::__1::__less<double, double> &,
      SimTK::VectorIterator<double, SimTK::VectorBase<double> > >' requested here
    __sort<_Comp_ref>(__first, __last, __comp);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3752:5: note: in
      instantiation of function template specialization 'std::__1::sort<SimTK::VectorIterator<double, SimTK::VectorBase<double>
      >, std::__1::__less<double, double> >' requested here
    _VSTD::sort(__first, __last, __less<typename iterator_traits<_RandomAccessIterator>::value_type>());
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__config:300:15: note: 
      expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/internal/VectorMath.h:358:5: note: in instantiation of
      function template specialization 'std::__1::sort<SimTK::VectorIterator<double, SimTK::VectorBase<double> > >' requested
      here
    std::sort(temp.begin(), temp.end());
    ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp:331:20: note: in instantiation of function template
      specialization 'SimTK::sort<double>' requested here
        testVector(sort(vector), expectedVec);
                   ^
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp:24:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon.h:32:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/basics.h:38:
In file included from /tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/internal/common.h:234:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/complex:247:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/sstream:174:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ostream:130:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ios:216:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__locale:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:434:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3585:17: error: 
      no viable overloaded '+='
            __m += __delta;
            ~~~ ^  ~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3743:5: note: in
      instantiation of function template specialization 'std::__1::__sort<std::__1::__less<double, double> &,
      SimTK::VectorIterator<double, SimTK::RowVectorBase<double> > >' requested here
    __sort<_Comp_ref>(__first, __last, __comp);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:3752:5: note: in
      instantiation of function template specialization 'std::__1::sort<SimTK::VectorIterator<double,
      SimTK::RowVectorBase<double> >, std::__1::__less<double, double> >' requested here
    _VSTD::sort(__first, __last, __less<typename iterator_traits<_RandomAccessIterator>::value_type>());
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__config:300:15: note: 
      expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/./include/SimTKcommon/internal/VectorMath.h:365:5: note: in instantiation of
      function template specialization 'std::__1::sort<SimTK::VectorIterator<double, SimTK::RowVectorBase<double> > >' requested
      here
    std::sort(temp.begin(), temp.end());
    ^
/tmp/simbody-Fnqf/simbody-Simbody-3.3/SimTKcommon/tests/TestVectorMath.cpp:332:20: note: in instantiation of function template
      specialization 'SimTK::sort<double>' requested here
        testVector(sort(rowvector), expectedVec);
                   ^
2 errors generated.
make[3]: *** [SimTKcommon/tests/CMakeFiles/TestVectorMath.dir/TestVectorMath.cpp.o] Error 1
make[2]: *** [SimTKcommon/tests/CMakeFiles/TestVectorMath.dir/all] Error 2
make[1]: *** [SimTKcommon/tests/CMakeFiles/TestVectorMath.dir/rule] Error 2
make: *** [TestVectorMath] Error 2

Default install directory seems incorrect and documentation doesn't match anymore

I just built Simbody on Ubuntu 13.04 (git hash 7e06039).

ccmake no longer gave an option for SimTK_INSTALL_PREFIX as was specified in the included HowToBuildSimbodyFromSource_MacLinux.pdf on page 6. So I installed without checking that variable. This installed Simbody into /usr/local instead of /usr/local/SimTK. The new option CMAKE_INSTALL_PREFIX that was added in PR #40 doesn't show up in the ccmake default, only the advanced section and for me the default value was /usr/local.

Screw mobilizer should allow runtime pitch change & similarly for other elements

The pitch should be stored in an instance variable in the State so that it can be changed without requiring topology to be rebuilt. (Gazebo has an API for setting it.)

EDIT: there are many other elements in Simbody that need state-modifiable versions of their parameters. Here is the beginning of a checklist:

  • Screw mobilizer's pitch
  • PointInPlane constraint's normal direction, height, and follower point location
  • Ball constraint's two point locations (and radius?)
  • lots more

Mobilizer::lock() doesn't reset Q and U immediately

The lock() method doesn’t change q or u but rather just records the new locked position. Then the next call to prescribe() forces q and u to the right values. prescribe() is usually called as part of integration.

When we use lock() for controlling a robotic arm we would like the mobility to be locked instantaneously. If the lock() is called at POSITION level it will be nice if it automatically clear the U to 0, reset or record the Q. So that when unlock() is called it won't pick up residual U.

3 tests fail on Ubuntu 13.10

I just installed Simbody (ddadd1c) into a fresh Ubuntu 13.10 desktop OS and three tests fail after compiling:

97% tests passed, 3 tests failed out of 98

Total Test time (real) = 595.11 sec

The following tests FAILED:
     71 - TestGeo (OTHER_FAULT)
     75 - TestTriangleMesh (OTHER_FAULT)
     87 - TestObservedPointFitter (Failed)
Errors while running CTest
make: *** [test] Error 8

What should I do to figure out what is going wrong?

CMAKE_INSTALL_PREFIX not used

In the root CMakeLists.txt, the CMAKE_INSTALL_PREFIX variable is replaced by the value of SimTK_INSTALL_PREFIX. In the comments (which were added in afc617e), it states that CMAKE_INSTALL_PREFIX is "always set to something incorrect by CMake". Is this just an issue with Windows? We use CMAKE_INSTALL_PREFIX regularly on Ubuntu and OSX for gazebo.

NoSlip1d constraint does not allow the Case body to be one of the two constrained bodies.

(Transferred from SimTK.org. Filed by Ajay Seth 2009-03-31.)

I think the no-slip constraint should allow the case body to be the same as one of the other bodies. I can't think of any reason that shouldn't work fine, and the fact that it is prohibited is actually an accident -- there is no explicit test preventing it; it just got caught by some generic constraint bugcatching code.

Distribute simbody through the Debian repositories.

See:
http://askubuntu.com/questions/16446/how-to-get-my-software-into-ubuntu
https://wiki.debian.org/DebianMentorsFaq

We can either get it into Ubuntu, or into Debian, which will eventually get it into Ubuntu for us.

A "Debian Developer" needs to package it for us, or one of us needs to become a Debian Developer. I assume none of us want to become Debian Developers. We can find such people to do it for us at http://mentors.debian.net/. The Debian Developer would be called a sponsor, and we would be called the maintainers. Well, @sherm1 or @j-rivero would be, I suppose.

This is probably the most useful page: http://mentors.debian.net/intro-maintainers.

Before we do this, I think we should rename the VisualizerGUI executable to something like simbody-visualizer. Or, the debian package should not include this executable.

Maybe @j-rivero knows a good amount about how we could go about this.

Size of repository is really large

When I cloned this repo I was suprised at how long it took to download. It seems it was on the order of 150mb+.

moorepants@moorepants-UL30A:simbody(master)$ find . -size +500k -ls
14551698 1164 -rw-rw-r--   1 moorepants moorepants  1187875 Oct 12 15:44 ./doc/HowToBuildSimbodyFromSource_Windows.pdf
14551697  584 -rw-rw-r--   1 moorepants moorepants   594432 Oct 12 15:44 ./doc/HowToBuildSimbodyFromSource_Windows.doc
14551695  552 -rw-rw-r--   1 moorepants moorepants   564224 Oct 12 15:44 ./doc/HowToBuildSimbodyFromSource_MacLinux.doc
14551696 1176 -rw-rw-r--   1 moorepants moorepants  1200874 Oct 12 15:44 ./doc/HowToBuildSimbodyFromSource_MacLinux.pdf
15082756 162476 -r--r--r--   1 moorepants moorepants 166367623 Oct 12 15:44 ./.git/objects/pack/pack-09fa36e59a726779ac09bd68c80fa718829ab9f0.pack
15082757  932 -r--r--r--   1 moorepants moorepants   953716 Oct 12 15:44 ./.git/objects/pack/pack-09fa36e59a726779ac09bd68c80fa718829ab9f0.idx
19664888  664 -rw-rw-r--   1 moorepants moorepants   676403 Oct 12 15:44 ./SimTKmath/doc/SimmathUserGuide.pdf
19664887 3708 -rw-rw-r--   1 moorepants moorepants  3793408 Oct 12 15:44 ./SimTKmath/doc/SimmathUserGuide.doc
19664958  716 -rw-rw-r--   1 moorepants moorepants   729739 Oct 12 15:44 ./SimTKmath/tests/adhoc/nlpqlp.cpp
19664999  644 -rw-rw-r--   1 moorepants moorepants   657674 Oct 12 15:44 ./Simbody/doc/SimbodyAdvancedProgrammingGuide.docx
19665002 1220 -rw-rw-r--   1 moorepants moorepants  1246968 Oct 12 15:44 ./Simbody/doc/SimbodyAndMolmodelUserGuide.pdf
19665004 2688 -rw-rw-r--   1 moorepants moorepants  2751495 Oct 12 15:44 ./Simbody/doc/SimbodyTheoryManual.pdf
19665003 7000 -rw-rw-r--   1 moorepants moorepants  7164580 Oct 12 15:44 ./Simbody/doc/SimbodyTheoryManual.docx
19665001  876 -rw-rw-r--   1 moorepants moorepants   896783 Oct 12 15:44 ./Simbody/doc/SimbodyAndMolmodelUserGuide.docx
19664997  664 -rw-rw-r--   1 moorepants moorepants   676204 Oct 12 15:44 ./Simbody/doc/FrictionConstraints.docx
19665000  744 -rw-rw-r--   1 moorepants moorepants   759048 Oct 12 15:44 ./Simbody/doc/SimbodyAdvancedProgrammingGuide.pdf
19665012 2440 -rw-rw-r--   1 moorepants moorepants  2498359 Oct 12 15:44 ./Simbody/examples/ExampleAmysIKProblem.cpp
19665223  624 -rw-rw-r--   1 moorepants moorepants   636158 Oct 12 15:44 ./Simbody/tests/adhoc/ContactBigMeshes_Femur.obj
19664971  620 -rw-rw-r--   1 moorepants moorepants   634357 Oct 12 15:44 ./Simbody/Visualizer/VisualizerGUI/glut32/glext.h
19664210  692 -rw-rw-r--   1 moorepants moorepants   704526 Oct 12 15:44 ./Platform/Windows/lib_x86/libquadmath-0.dll
19664207 1048 -rw-rw-r--   1 moorepants moorepants  1069582 Oct 12 15:44 ./Platform/Windows/lib_x86/libgfortran-3.dll
19664202 11528 -rw-rw-r--   1 moorepants moorepants 11802640 Oct 12 15:44 ./Platform/Windows/lib_x86/SimTKlapack.dll
19664208 5844 -rw-rw-r--   1 moorepants moorepants  5983228 Oct 12 15:44 ./Platform/Windows/lib_x86/liblapack.dll
15599500 1280 -rw-rw-r--   1 moorepants moorepants  1310056 Oct 12 15:44 ./Platform/Windows/lib_x64/libquadmath-0.dll
15599496  732 -rw-rw-r--   1 moorepants moorepants   749404 Oct 12 15:44 ./Platform/Windows/lib_x64/libgcc_s_sjlj-1.dll
15599497 7168 -rw-rw-r--   1 moorepants moorepants  7337949 Oct 12 15:44 ./Platform/Windows/lib_x64/libgfortran-3.dll
15599471  656 -rw-rw-r--   1 moorepants moorepants   671682 Oct 12 15:44 ./Platform/Windows/lib_x64/libblas.dll
15599498 6044 -rw-rw-r--   1 moorepants moorepants  6187063 Oct 12 15:44 ./Platform/Windows/lib_x64/liblapack.dll

It seems that the pdfs, word docs, and windows dll's are the likely culprits. From interacting with other software projects, it isn't typical to store binaries in distributed version control repositories both because versioning them has little use and cloning is slow. I'd be happy to submit a pull request that completely purges all of the generated files such as the dlls and pdfs from the repo. Copies of these could be hosted on the SimTK website instead of in the software repository.

Constraint::PrescribedMotion doesn't allow a constant function in Debug mode

(Transferred from SimTK.org. Original filed 2011-09-22 as bug 1541)
From Ajay Seth:
This works just fine in release (as the assertions are removed). Perfectly good
work around exists: use a polynomial function of time that returns a constant.

Sherm has seen this on 2011 09 22 at 1:38pm in his office.

optimizer limits should restrict differentiator perturbations

(Transferred from SimTK.org. Original filed 2012-06-04 as bug #1680)

When an optimizer is given limits on the variable values, it may reach those
limits but will not exceed them. When at the limit, it may need to calculate
a gradient. When the gradient is not supplied analytically, the SimTK::Differentiator
is used, but it doesn't know about the limits. So it may perturb variables so
that they slightly exceed the limit, which may cause errors to be reported by
the underlying objective function. This happened in an OpenSim example with
excitations, which are limited to 0..1.

So the Differentiator should be taught about limits, and the optimizers should
be modified to convey the limits to it.

Increase the maintainability of (installation) documentation

It's come up in other issues that if the (install) documentation were in a plain text format, it would be easier to maintain. See #47, #48.

Do we want to move the install documentation? An option would be to write them in Markdown/RST, which could be converted into a PDF using pandoc or something like that.

make doxygen not working if simbody has parent folder named src

make doxygen works on my mac (doxygen 1.8.5), but it's not finding code files to analyze on my Ubuntu machine (12.10 quantal with doxygen 1.8.1.2). There's quite a few warnings and then it doesn't mention any specific code files that it parsed. Here's the console output:

$ make doxygen
warning: ignoring unsupported tag `AUTOLINK_SUPPORT       =' at line 289, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `USE_MDFILE_AS_MAINPAGE =' at line 882, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `SOURCE_TOOLTIPS        =' at line 938, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `CLANG_ASSISTED_PARSING =' at line 979, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `CLANG_OPTIONS          =' at line 987, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET  =' at line 1090, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `MATHJAX_FORMAT         =' at line 1439, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `MATHJAX_CODEFILE       =' at line 1467, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `EXTERNAL_SEARCH        =' at line 1516, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `SEARCHENGINE_URL       =' at line 1527, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `SEARCHDATA_FILE        =' at line 1535, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `EXTERNAL_SEARCH_ID     =' at line 1543, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `EXTRA_SEARCH_MAPPINGS  =' at line 1553, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `LATEX_EXTRA_FILES      =' at line 1647, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `GENERATE_DOCBOOK       =' at line 1840, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `DOCBOOK_OUTPUT         =' at line 1848, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
warning: ignoring unsupported tag `EXTERNAL_PAGES         =' at line 2026, file /home/scpeters/ws/gazebo_simbody/build_isolated/simbody/devel/Doxyfile
Searching for include files...
Searching for example files...
Searching for images...
Searching for files in directory /home/scpeters/ws/gazebo_simbody/src/simbody/doc/images
Searching for files in directory /home/scpeters/ws/gazebo_simbody/src/simbody/Simbody/doc/images
Searching for files in directory /home/scpeters/ws/gazebo_simbody/src/simbody/SimTKmath/doc/images
Searching for files in directory /home/scpeters/ws/gazebo_simbody/src/simbody/SimTKcommon/doc/images
Searching for dot files...
Searching for msc files...
Searching for files to exclude
Searching for files to process...
Searching for files in directory /home/scpeters/ws/gazebo_simbody/src/simbody
Reading and parsing tag files
Building group list...
Building directory list...
Building namespace list...
Building file list...
Building class list...
Associating documentation with classes...
Computing nesting relations for classes...
Building example list...
Searching for enumerations...
Searching for documented typedefs...
Searching for members imported via using declarations...
Searching for included using directives...
Searching for documented variables...
Building member list...
Searching for friends...
Searching for documented defines...
Computing class inheritance relations...
Computing class usage relations...
Flushing cached template relations that have become invalid...
Creating members for template instances...
Computing class relations...
Add enum values to enums...
Searching for member function documentation...
Building page list...
Search for main page...
Computing page relations...
Determining the scope of groups...
Sorting lists...
Freeing entry tree
Determining which enums are documented
Computing member relations...
Building full member lists recursively...
Adding members to member groups.
Distributing member group documentation.
Computing member references...
Inheriting documentation...
Generating disk names...
Adding source references...
Adding xrefitems...
Sorting member lists...
Computing dependencies between directories...
Generating citations page...
Counting data structures...
Resolving user defined references...
Finding anchors and sections in the documentation...
Combining using relations...
Adding members to index pages...
Generating style sheet...
Generating search indices...
Generating example documentation...
Generating file sources...
Generating file documentation...
Generating page documentation...
Generating group documentation...
Generating class documentation...
Generating namespace index...
Generating graph info page...
Generating directory documentation...
Generating index page...
Generating page index...
Generating module index...
Generating namespace index...
Generating namespace member index...
Generating annotated compound index...
Generating alphabetical compound index...
Generating hierarchical class index...
Generating member index...
Generating file index...
Generating file member index...
Generating example index...
finalizing index lists...
symbol cache used 30/65536 hits=393 misses=30
lookup cache used 85/65536 hits=134 misses=119
finished...
Built target doxygen

Delete obsolete binaries from Simbody repo

Simbody's repo contains some binary libraries that are needed on some platforms but can't be built from Simbody source, such as pthreads, glut and lapack for Windows. This used to include Linux as well and an older Windows lapack called SimTKlapack; these libraries aren't needed and should be deleted.

Warning: don't get carried away and try to edit these binaries out of the repo history. Considerable mayhem may ensue; see issue #46.

Visualizer built in Debug mode should have "_d" in its name

(Transferred from SimTK.org. Original was filed 2011-07-28 as bug #1500)

Currently both Debug and Release builds of the Simbody Visualizer create an
executable of the same name, e.g. Visualizer.exe on Windows. Depending on build
order, this can result in a (slow) debuggable Visualizer being used with a (fast)
release set of Simbody libraries.

The debug version of the Visualizer should be named analogously to the debug
libraries -- add an "_d" suffix. Then by default the release Visualizer should
be used, with fallback to the _d one if release isn't available. Probably this
should still be true when using debug Simbody libraries, since it is rare that
anyone but us would be debugging the Visualizer. Maybe add an environment variable
that could select a non-default Visualizer executable; that could be used to
select the debug one when we're debugging.

Cannot use multiplyByMInv or calcMInv in OpenSim::Controller::computeControls(), when calling this latter method more than once

I am working on an operational-space controller based off Gerald Brantner's BIO 485 project at Stanford and Emel Demircan's direct marker control.

I am implementing it in OpenSim in an OpenSim::Controller, and am using it as a tool, just like CMCTool.

https://github.com/chrisdembia/direct-marker-tracking

I have run into an issue that Gerald also ran into. I am making calls to multiplyByMInv() inside OpenSim::DirectMarkerTrackingController::computeControls(), but I get a SimTK exception if this is called 2 times:

DEBUG COUNT: 1
DirectMarkerTrackingController.computeControls:  t = 0
DEBUG COUNT: 2
DirectMarkerTrackingController.computeControls:  t = 0
terminate called after throwing an instance of 'SimTK::Exception::StageTooLow'
  what():  SimTK Exception thrown at State.cpp:2069:
  Expected stage to be at least Dynamics in StateImpl::getCacheEntry() but current stage was Velocity

This can be reproduced by building my project at https://github.com/chrisdembia/direct-marker-tracking and running:
opensim-tracker double_pendulum_tracker_setup.xml. I am using trunk for opensim, and master for simbody.

I used the same workaround that Gerald uses. To get the code to work (to use the workaround) change withBug to false, in DirectMarkerTrackingController.cpp (https://github.com/chrisdembia/direct-marker-tracking/blob/master/DirectMarkerTrackingController.cpp#L79).

Differentiator should check if sizes were set for gradient & jacobian functions

(Transferred from SimTK.org. Filed 2010-02-03)

(Tim Dorn ran into this problem)

If a user derives a Differentiator function from GradientFunction or JacobianFunction but neglects to call the appropriate base class constructor, the sizes will be passed as "-1" so this mistake is easy to detect. However, despite extensive error checking in Differentiator it doesn't appear to check those sizes for reasonableness before plowing ahead and encountering mysterious disasters.

Those checks should be added, with a helpful error message mentioning that the base class constructors need to be called explicitly.

Provide cmake config file instead of module

There are two ways that cmake uses to search when find_package is invoked. Downstream developers often write module that search for a package location based on the expected header files and library names, while package maintainers can provide a cmake config template file that is populated at build time with the absolute paths. The latter case is preferable since it reduces the probability of bugs in the module search logic and plays more nicely on systems with multiple simbody installations (something I do).

Currently simbody has a module; I would propose using a cmake config file instead.

BUILD_EXAMPLES CMake variable does nothing?

I am able to set BUILD_EXAMPLES to TRUE and end up with no example targets.

Looking at Simbody/examples/CMakeLists.txt, it seems that the building of examples depends primarily on the values of BUILD_TESTING_SHARED, BUILD_STATIC_LIBRARIES, and BUILD_TESTING_STATIC, and not at all on BUILD_EXAMPLES.

Am I mistaken? If not, I will create a PR to fix this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.