Skip to content

MONAI_Design

Jump to bottom Edit New page
Wenqi Li edited this page Jul 22, 2021 · 42 revisions

MONAI Design Pages

Introduction

This page is the base page of the MONAI design document. If you are intending to contribute to the MONAI code base, it is important that you get an understanding of the design and of MONAI so that we can ensure that your contribution to MONAI helps it .

This document is separated into a number of sections:

  • High-level design - critical elements of design that sit at the architecture layer and above
  • Design conventions - design and code-level conventions that should be adhered to if possible when considering new applications, networks, layers, mechanisms, etc.
    • Application design conventions
    • Network design conventions
  • Design discussions - highlighting design decisions for optional extensions to the standard MONAI componentry

Table of Contents

MONAI design

- TODO: code examples and more detail for all of the following subsections

In order to meet the design goals set down by the user pathways, the MONAI codebase should be demonstrative of what we think are best practices uses of the API. One of its strengths should be the rich set of applications that are developed through the components that we build, as they represent exemplars for others to follow. There are a number of aspects to be considered here:

  1. Consistent validation of parameters
  2. Clear and consistent reporting of validation failures
  3. Consistent network configuration capabilities and conventions for doing so
  4. Consistent network customisation capabilities and conventions for doing so

Consistent validation of parameters

Consistent validation of parameters is very important in python modules; duck typing means that errors are often found far from the API call site at which they might first have been validated, which leads to obscure exceptions and unnecessary time spent debugging. Writing validation code for every function is onerous, but validation helper functions for all of the common parameter types are a simple solution. These are function calls that perform sensible check for parameters based both on their types and the concepts that they represent. For example, a float parameter must be a floating point value of some description but a learning rate is a float that must also be positive (under normal circumstances).

- TODO: more examples

Validation failure reporting

Another benefit to the provision of parameter validation methods is that they can also ensure consistency and clarity in the reporting of API contract violations.

- TODO: more detail required

Network configuration & customisation convention / consistency

Network configuration & customisation convention / consistency Networks that become part of Monai should be built to what we consider to be current best practices with respect to configurability. This configurability should be presented and used in consistent ways across networks, where applicable. The following aspects are all considered configurable:

  • Channel counts
  • 2D / 3D versions of networks *1
  • Weight initialisation
  • Normalisation layer
  • Dropout
  • Activation
  • Number of layers in layered networks
    • Block repeat counts
  • Convolutional block definition / override
- *1 TODO: potentially controversial; discuss

MONAI design by topic

This section documents the design of different components of MONAI. If you are intending to contribute to the code base, we recommend that you become familiar with the design decisions across the software as a whole, but particularly in the area where you intend to make a contribution. Detailed contribution guidelines can be found here.

Each design topic is covered in its own sub-page, linked below:

Concrete design discussions by topic

This section documents the concrete designs / design proposals for different topics of Monai design. Design is actively ongoing for many topics, so you can find a summary of all design topics here and their current status, as well as links to the specific pages.

Stages

  • Proposal: Proposals have been made for this design topic, but not actively discussed
  • Active: Design discussions are actively being scheduled and resolved
  • Agreed: Design for this area is effectively agreed (but still open to change if necessary) and subject to occasional review to ensure that the design continues to meet the needs of the software

Each concrete design discussion topic is covered in its own sub-page, linked below:

Layer configurability

- TODO: fill this section out, including examples

Vanilla pytorch networks are often defined to work with a specific image format. When a network is required to function with a number of different image formats, there is no pytorch mechanism for doing so.

Typically, such configuration should happen at model instantiation time rather than model execution time.

We can use factories / factory methods to do this effectively, and default to 4D BFHW if not specified.

TODO: populate following sections

Pre-processing steps

Losses Selection from across Clara Train / Niftynet custom losses

Networks

  • Neural architecture search
  • Ensembling - see engines / engine helpers also Engines
  • Q learning
  • PixelRNN / PixelCNN
  • Features
  • Ensembling
  • Network meta training
  • Hyper parameter search - generator based
  • Federated learning
  • Learning without forgetting

Adaptive losses

  • For Asynchronicity - MR vs CT different preprocessing pipelines - Need for modularity
  • Conditional training
  • Data sink solutions (csv, images, tables
  • Allow for different processing (folder wise, individual subject)

Optimisers

  • Medical imaging specific optimisers
  • Hybrid optimisers

Copyright (c) MONAI Consortium

Working Groups

Clone this wiki locally