ORE Studio is a graphical wrapper around Acadia's Open Source Risk Engine (ORE), which itself builds atop of QuantLib. Please note that this open source project has no affiliation whatsoever with ORE or QuantLib, but you cannot understand ORE Studio without at least a basic understanding of both of these projects.

QuantLib is defined as follows:

The QuantLib project (https://www.quantlib.org) is aimed at providing a comprehensive software framework for quantitative finance. QuantLib is a free/open-source library for modeling, trading, and risk management in real-life.

ORE tells us that

The Open Source Risk project aims at establishing a transparent peer-reviewed framework for pricing and risk analysis that can serve as

• a benchmarking, validation, training, teaching reference
• an extensible foundation for tailored risk solutions

Open Source Risk Engine (ORE) provides

• contemporary risk analytics and value adjustments (XVAs)
• interfaces for trade/market data and system configuration (API and XML)
• simple application launchers in Excel, LibreOffice, Python, Jupyter
• various examples that demonstrate typical use cases
• comprehensive test suites

ORE is based on QuantLib, the open source library for quantitative finance, and it extends QuantLib in terms of simulation models, financial instruments and pricing engines.

ORE Studio builds on top of ORE with the eventual aim of providing:

• persistent database storage for all of its inputs and outputs, with basic CRUD support;
• graphical user interface both for data generation as well as data exploration;
• ability to configure and orchestrate ORE execution.

The remainder of this document describes our approach in greater detail.

• GitHub: Most project interaction for developers occurs via GitHub.
• Website: Statically generated website with project documentation.

The objective of this project is to create a simple User Interface for ORE, for didactic purposes. Significantly, our intent is not to create a professional tool for enterprise-grade use. We instead follow on the footsteps of those like Karpathy, who view learning as deeply enmeshed with the act of building.

With this in mind, our strategy is two-fold:

• to learn by creating the tool itself; and
• to create a tool specifically designed for others to learn, explore and experiment within the domain of quantitative finance, both by using the tool as well as by extending it for their own purposes.

The next section explains how we intend to go on about it.

All documentation for this project is kept within git, right next to its source code. It uses Emacs and org-mode to automatically generate its website, in a variation of literate programming. We also use org-roam internally to organise our notes and org-babel to make code blocks executable where possible. Org-roam is an implementation of the Zettelkasten method, though you need not care too much about it if you do not use Emacs; just browse through the content via the website and start with "Documentation" as the entry point. Unfortunately this only works via the website, so you will not see some of the links within GitHub's rendering of the org-mode files.

If you do use Emacs, you can make use of a much richer roam experience. The file .dir-locals.el is configured to generate a local roam database when you run:

(org-roam-db-sync)

This snippet, as well as many like it, is an executable snippet via org-babel. Once you run it, you can then jump through all the pages using the normal org-roam facilities.

Lastly, you may notice that this content is somewhat academic in tone. Though we are not affiliated with any academic effort, I have kept a lot of bad habits from my days at university and these inform the approach — for example how we research prior art, organise the documentation, the use of references and so on. Nonetheless, rather than a research model, the project intends to be useful to academics and practitioners alike, within its stated constraints. If you do want to use the project for research, a DOI will be made available in Zenodo when we do our first release. Once sufficient functionality has been implemented to justify the effort, we'll write a Technical Report describing the tool.

Binary packages are available for each release in GitHub, with the links shown at the end of each release note. The binaries cover Debian Linux (though they probably also work for Ubuntu and other flavours), MacOS and Windows — all 64-bit only. Packages are also generated per commit for each Operative System and stored with the corresponding GitHub Workflow. Development is done from the main branch in git, so latest should always be greatest; but you may want to use packages from the previous sprint rather than what is currently under development (see badges above).

Notes:

• Other than Linux, we do not test the packages frequently. If you find any issues with a binary package, please raise an issue.
• The OSX installer provides you with a DMG. Once you open it in Finder, it mounts under /Volumes/, e.g.:

/Volumes/OreStudio-${VERSION}-Darwin/orestudio.app/Contents/Resources/bin

Where ${VERSION} is your ORE Studio version, such as 0.0.1.

In order to build ORE Studio you will need a modern C++ toolchain. On Linux and OSX, you'll need a recent compiler with C++ 20 support, such as GCC 13 or Clang 14, and Ninja or GNU Make. On Windows you'll need Visual Studio 2022. On all platforms, we make extensive use of CMake. Older compilers may work, but we try to always use the most recent releases. So, if you can, please try using to those.

In terms of dependencies, though ORE Studio should build fine with package-manager supplied libraries or even with hand-built dependencies, the recommended way to setup a development environment on all supported platforms is by using vcpkg, which is what this document describes. ORE Studio uses the "sub-module setup", whereby vcpkg is a git submodule of ORE Studio. All of the dependencies are declared in the vcpkg.json file. Unfortunately, some of these packages also have dependencies — particularly on Linux. If you are on Debian or Ubuntu, please run the script build\scripts\install_debian_packages.sh prior to building.

Our build makes use of CMake Presets. To know what these are you can either have a look at the presets file CMakePresets.json or, better still, ask CMake:

cmake --list-presets

For the remainder of this document we shall assume linux-clang-release, which is our preferred preset. If it isn't yours, remember to update the preset name to match your desired build.

To checkout ORE Studio, clone as follows:

git clone https://github.com/OreStudio/OreStudio.git --recurse-submodules

The --recurse-submodules is needed for the vcpkg submodule setup. As for the configure step:

cd OreStudio
cmake --preset linux-clang-release

You can then build ORE Studio on all platforms as follows:

cmake --build --preset linux-clang-release

If you'd like to run the project tests, execute the target run_all_tests or its abbreviation rat.

cmake --build --preset linux-clang-release --target rat

A quicker way to do all of these steps in one go is to use the workflow preset:

cmake --workflow --preset linux-clang-release

Last but not least, you can start the GUI via the target run_ores_qt:

cmake --build --preset linux-clang-release --target run_ores_qt