diff --git a/CODING_STANDARDS.md b/CODING_STANDARDS.md index 2f3763c..158ffa7 100644 --- a/CODING_STANDARDS.md +++ b/CODING_STANDARDS.md @@ -1,75 +1 @@ -# Visual Studio Settings - -* Use indentation of 3. -* Use spaces instead of tabs. -* If using Resharper, make sure a Resharper settings file is available to format your code. - -# Naming Convention - -Use meaningful and understandable names. Code should read as a story and only some well known abbreviations such as DTO, PK etc. should be used. - -## Classes and Methods - -* Use **Pascal Casing** for class name `public class SomeClass`. -* Use **Pascal Casing** for public and protected method name `public void SomeMethod()`. -* Use **Camel Casing** for private method name ` private int somePrivateMethod()`. -* Prefix interface with I `public interface IMyInterface`. -* Suffix exception classes with Exception `public class SBSuiteException: Exception`. - -## Variables - -* Prefix private/protected member variable with `_` (underscore): `private int _parentContainerId`. -* Use **ALL_CAPS Casing** for constant variables: `public const double DEFAULT_PERCENTILE = 0.5;`. -* Use **Camel Casing** for local variable names and method arguments: `int ingredientNode`. -* All members variable should be declared at one place of a class definition. -* Prefer variables initialization at the point of declaration . -* Do not use public members. Use properties instead. -* Do not use Hungarian notation (e.g. b for boolean, s for strings etc.). -* Except for program constants, never use global variables. - -## Comments - -* Do not comment the obvious -* Indent comment at the same level of indentation as the code you are documenting -* All comments must be written in English -* Do not generate comments automatically -* Do comment algorithm specifics. For example, why your loop starts at index 1 and not at 0. -* If a lot of comments are required to make a method easier to understand, break down the method in smaller methods -* Really, do not comment the obvious - -# Coding Style - -* No hard coded strings and magic number should be used. Declare a constant instead. -* Method with return values should not have side effects unless absolutely required. -* Exit early instead of having nested if statements. - - For example, instead of - - ``` - public void UpdateValue(bool isVisible, bool isEditable, double value) - { - if(isVisible) - { - if(isEditable) - { - _value = value; - } - } - } - ``` - use - - ``` - public void UpdateValue(bool isVisible, bool isEditable, double value) - { - if(!isVisible || !isEditable) - return; - - _value = value; - } - ``` -* Do not write `if` statements in one line. -* Do not write `for` and `forEach` statements in one line. -* Always use block `{}` for `for` and `forEach` statements. -* Always have a default case for `switch` statement, potentially throwing an exception if the default is unreachable. - +You can find the C# coding standards for the OSP Suite in the developer documentation [here](https://github.com/Open-Systems-Pharmacology/developer-docs/blob/main/setup/coding_standards.md). \ No newline at end of file diff --git a/CODING_STANDARDS_R.md b/CODING_STANDARDS_R.md index e9c0a32..bfc5fd6 100644 --- a/CODING_STANDARDS_R.md +++ b/CODING_STANDARDS_R.md @@ -1,285 +1 @@ -# Coding Standards for R - -We will follow the style guide with very few changes to benefit from two R packages supporting this style guide: - -- [`{styler}`](http://styler.r-lib.org/) -- [`{lintr}`](https://github.com/jimhester/lintr) - -This coding standards will outline the more important aspects of the aforementioned style. - -# Modifications from tidyverse Coding Standards - -- Naming will use `camelCase` instead of `snake_case`. - -- Favor usage of `return()` even when the return value does not need to be specified explicitly. - -# RStudio IDE Settings - -- Indentation of 2 - -- Use spaces instead of tabs - -- Use UTF-8 text encoding (Ref: ) - -drawing - -- Use `{tinytex}` for `LaTeX` compilation (Ref: ) - -drawing - -- Use AGG graphics device (Ref: ) - -drawing - -- Use a blank slate (there should not be any residue from previous session when you start a new session to ensure long-term reproducibility of the software) - -drawing - -# Naming Convention - -Use meaningful and understandable names. Code should read as a story and only some well known abbreviations (such as pk) should be used. - -## Files - -File names containing both source code (`/R`) and tests (`/tests`) should follow the kebab-case naming convention and should have `.R` extension. - -```r -# bad -DataCombined.R -test-DataCombined.R - -# good -data-combined.R -test-data-combined.R -``` - -## Object names - -- Variable and function names should use only lowercase letters and numbers. Use **camelCase** to separate words within a name. - -- Class names on the other hand should use **Pascal Casing**. - -- True constant variables should use **ALL_CAPS Casing**. - -```r -# Class - -Parameter <- R6Class("Parameter", ....) - -# Variable - -parameterToDelete <- ... - -# Method and function - -performSimulation <- function (...) - -# Constant variables - -DEFAULT_PERCENTILE <- 0.5 -``` - -- Do not use Hungarian notation (e.g., g for global, b for Boolean, s for strings, etc.) - -## Functions - -Prefer using `return()` for explicitly returning result, although you can rely on R to implicitly return the result of the last evaluated expression in a function. - -## Comments - -- Do not comment the obvious. -- Use comments to explain the **why**, and not the **what** or **how**. -- Indent comment at the same level of indentation as the code you are documenting. -- All comments must be written in English. -- Do not generate comments automatically. -- Do comment algorithm specifics. For example, why would you start a loop at index 1 and not at 0, etc. -- If a lot of comments are required to make a method easier to understand, break down the method in smaller methods. -- Really, do not comment the obvious. - -## Documentation - -- Use roxygen comments (`#'`) as described [here](http://r-pkgs.had.co.nz/man.html#roxygen-comments). - -- Do not include empty lines between the function code and its documentation. - -```r -# Good -#' @export -weekend <- list("Saturday", "Sunday") - -# Bad -#' @export - -weekend <- list("Saturday", "Sunday") -``` - -- Internal functions, if documented, should use the tag `#' @keywords internal`. This makes sure that package websites don't include these internal functions. - -- Prefer using `markdown` syntax to write roxygen documentation (e.g. use `**` instead of `\bold{}`). - -- To automate the conversion of existing documentation to use `markdown` syntax, install [roxygen2md](https://roxygen2md.r-lib.org/) package and run `roxygen2md::roxygen2md()` in the package root directory and carefully check the conversion. - -## Conventions - -- Function names as code with parentheses (good: `dplyr::mutate()`, `mutate()`; bad: *mutate*, **mutate**) -- Variable and (`R6`/`S3`/`S4`) object names as code (good: `x`; bad: x, *x*, **x**) -- Package names as code with `{` (good: `{dplyr}`; bad: `dplyr`, *dplyr*, **dplyr**) -- Programming language names as code (e.g. `markdown`, `C++`) - -Note that these conventions are adopted to facilitate (auto-generated) cross-linking in `{pkgdown}` websites. - -### Documenting functions - - - -### Documenting classes - -Reference classes are different across `S3` and `S4` because methods are associated with classes, not generics. RC also has a special convention for documenting methods: the docstring. The docstring is a string placed inside the definition of the method which briefly describes what it does. This makes documenting RC simpler than `S4` because you only need one roxygen block per class. - -```r -#' This is my Person class -#' @title Person Class -#' @docType class -#' @description Person class description -#' @field name Name of the person -#' @field hair Hair colour -#' -#' @section Methods: -#' \describe{ -#' \item{set_hair Set the hair color} -#' } -#' -#' @examples -#' Person$new(name="Bill", hair="Blond") -#' @export -Person <- R6::R6Class("Person", - public = list( - name = NULL, - hair = NULL, - initialize = function(name = NA, hair = NA) { - self$name <- name - self$hair <- hair - }, - - set_hair = function(val) { - self$hair <- val - }, - ) -) -``` - -When referring to the class property (`$name`) or method (`$set_hair()`) in package vignettes, use the `$` sign to highlight that they belong to an object. Note that the method always has parentheses to distinguish it from a property. - -If a class has a private method, its name should start with `.` to highlight this (e.g. `$.set_hair_color()`). - -# Syntax - -## Spacing - -Use the `styler` addin for RStudio. It will style the files for you. For more, see [here](https://style.tidyverse.org/syntax.html#spacing) - -## Global Variables - -- Except for program constants or truly global states, never use global variables. If a global object is required, this should be absolutely discussed with the team. - -- No hard coded strings and magic number should be used. Declare a constant instead. - -## Booleans - -- Avoid using boolean abbreviations (`T` and `F`). Instead, use `TRUE` and `FALSE` (respectively). - -## Style - -### Long Lines - -Strive to limit your code (including comments and roxygen documentation) to 80 characters per line. - -### Assignments - -Use `<-`, not `=`, for assignment. - -### Semicolons - -Don't put `;` at the end of a line, and don't use `;` to put multiple commands on one line. - -**Note:** All these styling issues, and much more, are corrected automatically with `{styler}`. - -### Code blocks - -- `{` should be the last character on the line. Related code (e.g., an `if` clause, a function declaration, a trailing comma, etc.) must be on the same line as the opening brace. - -- The contents should be indented. - -- `}` should be the first character on the line. - -- It is OK to drop the curly braces for very simple statements that fit on one line, **as long as they don't have side-effects**. - -```r -# Good -y <- 10 -x <- if (y < 20) "Too low" else "Too high" - -# Bad -if (y < 0) stop("Y is negative") - -if (y < 0) - stop("Y is negative") - -find_abs <- function(x) { - if (x > 0) return(x) - x * -1 -} -``` - -# Tests - -Refer to chapter [Tests](https://style.tidyverse.org/tests.html) - -# Error messages - -Refer to chapter [Errors](https://style.tidyverse.org/error-messages.html) - -# Rmarkdown - -Package vignettes are written using `{rmarkdown}` package. Here are some good practices to follow while writing these documents: - -- It is strongly recommended that only alphanumeric characters (`a-z`, `A-Z` and `0-9`) and dashes (`-`) are used in chunk labels, because they are not special characters and will surely work for all output formats. Other characters, spaces and underscores in particular, may cause trouble in certain packages, such as `{bookdown}`, `{styler}`. -Ref: - -```` -# bad - -```{r load theme, echo=FALSE} -``` - -# good - -```{r load-theme, echo=FALSE} -``` -```` - -- Let your rmarkdown breathe. You should use blank lines to separate different elements to avoid ambiguity. -Ref: - - -```` -# bad ----------------- - -My line is right above my chunk. -```{r} -``` -# and the next section right below - -# good ----------------- - -There is a line between text and chunk. - -```{r} -``` - -# and the next section is separated by line as well -```` - -# See also - -A more comprehensive list of tools helpful for package development can be found in this [resource](https://github.com/IndrajeetPatil/awesome-r-pkgtools/blob/master/README.md). +You can find the R coding standards for the OSP Suite in the developer documentation [here](https://github.com/Open-Systems-Pharmacology/developer-docs/blob/main/ospsuite-r-specifics/CODING_STANDARDS_R.md) \ No newline at end of file diff --git a/GETTING_STARTED.md b/GETTING_STARTED.md index 8c8a755..09eeffa 100644 --- a/GETTING_STARTED.md +++ b/GETTING_STARTED.md @@ -1,47 +1 @@ -# Developer Getting Started - -## Installing the prerequisites -1. Install Visual Studio 2017 Community Edition or better. [Visual Studio Install](https://www.visualstudio.com/downloads/) - -1. Install Ruby and Rake. [Ruby Install](https://rubyinstaller.org/downloads/) - -1. Install MikTeX. [MikTeX Install](https://github.com/Open-Systems-Pharmacology/MiKTeX/releases/download/v2.9.3/MikTex.2.9.3.msi). - -1. Obtain Devexpress License and Install - - * DevExpress WinForms Controls and Libraries is used in the graphical user interface of the suite. You will need to obtain a license in order to work with the user interface. - - * DevExpress only provides trials on their current product offering, so you may have to acquire the license prior to downloading an older version if that's required to build the suite. - - * Obtain your license from DevExpress [DevExpress Order](https://www.devexpress.com/Support/Order/). Then get the installer for the version mentioned above that's required [DevExpress Install](https://www.devexpress.com/ClientCenter/DownloadManager/) - -1. Install MSXML 4 [MSXML4 Installer](https://www.microsoft.com/en-ca/download/details.aspx?id=15697) - -1. Install nuget.exe and ensure that it is in your `PATH` variable [NuGet Install](https://dist.nuget.org/index.html) - -1. Add `OSPSuite.Core` as a nuget source using the following command -``` - nuget sources add -name ospsuite-core -source https://ci.appveyor.com/nuget/ospsuite-core -``` - -## Building and Running - -1. Clone the repository locally (either from the open-systems-pharmacology organization or from your own fork) - -1. For PK-Sim and MoBi, run the `postclean.bat` command - - There are several requirements to running the software that are not automatically performed when building with Visual Studio. An automated `postclean` batch file is used to take care of these tasks. - -1. Compile Source - -1. Run Tests - -1. Run the Application - -## Useful Tips - -1. The suite is using appveyor as a CI server which also provides a nuget feed that should be registered on your system. This will prevent you from having to enter AppVeyor password with each new instance of Visual Studio. This option is only available for developers with access to the appveyor feed. If you wish to be granted access to the feed, please let us know by posting a request in the forum. - -``` -nuget sources add -Name AppVeyor -source https://ci.appveyor.com/nuget/open-systems-pharmacology-ci -User -Password -``` +You can find the tutorial for setting up the OSP Suite C# Development Environment [here](https://github.com/Open-Systems-Pharmacology/developer-docs/blob/main/setup/getting_started.md) \ No newline at end of file diff --git a/GIT_WORKFLOW.md b/GIT_WORKFLOW.md index 87f93ad..56d2fa6 100644 --- a/GIT_WORKFLOW.md +++ b/GIT_WORKFLOW.md @@ -1,120 +1 @@ -The proposed workflow will use `git merge` and `git rebase` for different tasks. Our goal is to establish a workflow that will ensure a clean and useful public history graph. The public history should be concise yet clear and reflect the work of the team in a cohesive way. - -We will use `git merge` to incorporate the entire set of commit of one branch (typically the `develop` branch) into another one (typically `master`). - -We will use `git rebase` for all other type of code integration (sub tasks of a given swim lane etc..). - -# Definition -* The `master` branch is the ultimate source of truth. It should always be possible to use the code on `master` and create a production setup. - -* The `develop` branch is the branch where the development is taking place. Ultimately, when a new release is created, the commits in `develop` will be merged back into `master`. - -* A `feature` branch is a short lived branch that is used during the implementation of a given task. It will be deleted once the feature is implemented and merged into `develop`. - -* The git version to use is `1.8.5` or newer. This will allow the setting of the configuration option `git pull -rebase = preserve`. This option specify that _on pull, rebase should be used instead of merge_. But incoming merge commit should be preserved. - -* Unless required otherwise, all work should be performed on a fork of the repository. A _Pull Request (PR)_, will be used to incorpate changes into the `develop` branch. - -# Use Case: Implementing Task "426 it should be possible to delete observed data" -_Note:_ A task is a cohesive unit of work. This can be part of a bigger feature or a bug fix. We assume that a fork of the repository has already been created. - -1. Create a `feature` branch with a **meaningful name**, **starting with the id of the task**. We will need to acquire the latest changes from the remote `develop` branch first and then create the feature branch - * With option git pull -rebase = preserve - ``` - git checkout develop - git pull upstream #<= git fetch upstream develop && git rebase -p upstream/develop - git checkout -b 426-delete-observed-data - ``` - * Without option git pull -rebase = preserve - ``` - git checkout develop - git fetch upstream develop - git rebase -p upstream/develop - git checkout -b 426-delete-observed-data - ``` -2. Do work in your `feature` branch, committing early and often. -3. Rebase frequently to incorporate any upstream changes in the `develop` branch (to resolve conflicts as early as possible) - ``` - git fetch upstream develop - git rebase -p upstream/develop - ``` -4. Once work on the feature is complete, you are ready to create a PR. The first step is to push the code to your own repo and then create a PR onto the original repo for review: - ``` - git fetch upstream develop - git rebase -p upstream/develop - git push -u origin 426-delete-observed-data - ``` - - At that stage, your local branch `426-delete-observed-data` is set to track the remote branch `426-delete-observed-data` so you will be able to use the simple `git push` command from now on to udate your repo. - -5. Create pull request on github so that your change may be reviewed. The pull request should be between the `develop` branch on the `upstream` repo and the `feature` branch on your `fork`. The PR message **should** use the task id and the whole description of the task. For example `Fixes #426 it should be possible to delete observed data`. - -6. Upon code review, you may have to change the code slightly to take reviewer comments and concerns into account. If so just continue committing your work on your local `426-delete-observed-data` branch and repeat the steps above. - -7. Once the latest push has been accepted and all tests are passing, the reviewer can accept the pull request by using the `Squash and Merge` option. This will effectively squash all your commit into one and rebase the one commit from `426-delete-observed-data` onto `develop`. - -8. Delete your remote branch `426-delete-observed-data` as it is not required anymore - -9. Locally you can now repeat the synchronization of your develop branch - ``` - git checkout develop - git pull upstream - ``` -10. Your local `426-delete-observed-data` can also be deleted. - ``` - git branch -d 426-delete-observed-data - ``` -11. Optionally you may wish to remove any pointers locally to remote branch that do not exist anymore - ``` - git remote prune origin - ``` -12. A useful alias can be created in git to avoid repeating the same commands again and again for synchronizing remote `develop` branch with local `feature` branch. - - ``` - [alias] - sync = !git fetch upstream $1 && git rebase upstream/$1 - syncd = !git sync develop - ``` - Simply call `git syncd` to synchronize changes with the `develop` branch. To synchronize with an hypothetical other branch called `experience`, use `git sync experience` - -# Use Case: Creating a new release 6.5.1 -The work on the `develop` branch is finished and we are ready to tag the version officially. A tagged version will be a version that has been approved for work in production. - -This is extremely simple with github using the concept of release. - -1. Click on the `releases` section from the `Code` tab -1. Click on `Draft new release` -1. Pick the `develop` branch or the latest commit on `develop` corresponding to the commit to tag -1. Name the tag `v6.5.1`. -1. Give a meaningful name to the release `Release 6.5.1` -1. Optionally enter a description in the description field. This is typically where release notes should be written using the power of markdown. Files can also be attached to the description (manual, notes etc) -1. Publish release! _Great job_ - - -# Use Case: Creating a hot fix -Release 6.5.1 has been out for a few weeks and a nasty bug (issue 756 on the bug tracking system) was reported that can corrupt a project file. We need to create a hot fix asap to address the issue. The hot fix should be applied to 6.5.1 obviously, but the actual fix should also be pushed to other branches such as `develop` - -1. Create a branch based on the tag and create a new branch to collect all fixes for the hotfix - ``` - git fetch upstream - git checkout tags/v6.5.1 -b hotfix/6.5.2 - git push -u upstream hotfix/6.5.2 - ``` - -2. Create a branch for the one issue to solve - ``` - git checkout -b 756-project-corrupted - ``` - -3. Implement hot fix in this local branch -4. Push commit to start the code review process - - ``` - git sync hotfix/6.5.2 - git push origin 756-project-corrupted - ``` -5. After completed review, rebase PR into `hotfix/6.5.2` -6. Repeat for all issues that will be part of the hotfix (one or more) -7. Create release off of `hotfix/6.5.2` called Release `6.5.2` with tag `v6.5.2` -8. Merge branch `hotfix/6.5.2` into `develop` (fixing potential conflicts if any) -9. Delete branch `hotfix/6.5.2` +You can find a detailed description of the GitHub Workflow, the branch naming strategies and release guidelines in the developer documentation [here](https://github.com/Open-Systems-Pharmacology/developer-docs/blob/main/setup/git_workflow.md) \ No newline at end of file diff --git a/README.md b/README.md index b106fd0..0332b03 100644 --- a/README.md +++ b/README.md @@ -26,7 +26,7 @@ PK-Sim® uses building blocks that are grouped into [**Individuals**](https://do ### MoBi -[MoBi®](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation) is a systems biology software tool for multiscale physiological modeling and simulation. Within the restrictions of ordinary differential equations, almost any kind of (biological) model can be imported or set up from scratch. Examples include biochemical reaction networks, compartmental disease progression models, or PBPK models. However, the de novo development of a PBPK model, for example, is very cumbersome such that the preferred procedure is to import them from PK-Sim®. Importantly, MoBi® also allows for the combination of the described examples and thereby is a very powerful tool for modeling and simulation of multiscale physiological systems covering molecular details on the one hand and whole-body architecture on the other hand. +[MoBi®](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation) is a systems biology software tool for multiscale physiological modeling and simulation. Within the restrictions of ordinary differential equations, almost any kind of (biological) model can be imported or set up from scratch. Examples include *in vitro* dissolution testing, biochemical reaction networks, compartmental disease progression models, or PBPK models. However, the de novo development of a PBPK model, for example, is very cumbersome such that the preferred procedure is to import it from PK-Sim®. Importantly, MoBi® also allows for the combination of the described examples and thereby is a very powerful tool for modeling and simulation of multiscale physiological systems covering molecular details on the one hand and whole-body architecture on the other hand. De novo model establishment and simulation is supported by graphical tools and building blocks to support expert users. MoBi® uses building blocks that are grouped into [**Molecules**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#molecules), [**Reactions**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#reactions), [**Spatial Structures**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#spatial-structures), [**Passive Transports**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#transport-processes), [**Observers**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#observers), [**Events**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#events-and-applications), [**Molecule Start Values**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#molecule-start-values), [**Parameter Start Values**](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/model-building-components#parameter-start-values) and [**Observed Data**](https://docs.open-systems-pharmacology.org/shared-tools-and-example-workflows/import-edit-observed-data). Building blocks out of the above-mentioned groups can be combined to [generate models](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/setting-up-simulation). The advantage of building blocks is that they can be reused. Examples: @@ -35,7 +35,7 @@ De novo model establishment and simulation is supported by graphical tools and b ### Qualification framework -The qualification framework enables an automated validation of various scenarios (use-cases) supported by the OSP platform. This technical framework is used, for example, to release, in full confidence, a new version of the OSP Suite by verifying automatically that an ever-growing list of scenarios is performing as expected. Qualification framework is described in detail [here](https://docs.open-systems-pharmacology.org/shared-tools-and-example-workflows/qualification). +The qualification framework enables an automated validation of various scenarios (use-cases) supported by the OSP platform. This technical framework is used, for example, to release, in full confidence, a new version of the OSP Suite by verifying automatically that an ever-growing list of scenarios is performing as expected. The qualification framework is described in detail [here](https://docs.open-systems-pharmacology.org/shared-tools-and-example-workflows/qualification). ### Validation and automation tools @@ -48,10 +48,10 @@ Validation and automation tools include for example: The OSP software suite provides a set of packages for the R computing environment that allow scripted workflows with the models developed in PK-Sim® and MoBi®. -- [ospsuite](https://github.com/Open-Systems-Pharmacology/OSPSuite-R) package provides the functionality of loading, manipulating, and simulating the simulations created in PK-Sim® and MoBi®. It also offers extended workflows such as parameter sensitivity or PK-parameter calculation. The package is described in detail in [R documentation](https://docs.open-systems-pharmacology.org/working-with-r/r-introduction). -- [tlf](https://github.com/Open-Systems-Pharmacology/TLF-Library) package offers a set of functions and methods for creating standardized reporting **T**ables, **L**istings, and **F**igures. -- [ospsuite.reportingengine](https://github.com/Open-Systems-Pharmacology/OSPSuite.ReportingEngine) for automated generation of model reports. -- [ospsuite.utils](https://github.com/open-systems-pharmacology/OSPSuite.RUtils) provides a collection of utility functions useful for R packages in the OSP ecosystem. +- [ospsuite](https://github.com/Open-Systems-Pharmacology/OSPSuite-R) package provides the functionality of loading, manipulating, and simulating the simulations created in PK-Sim® and MoBi®. It also offers extended workflows such as parameter sensitivity or PK-parameter calculation. The package is described in detail in [R documentation](https://www.open-systems-pharmacology.org/OSPSuite-R/). +- [tlf](https://www.open-systems-pharmacology.org/TLF-Library/) package offers a set of functions and methods for creating standardized reporting **T**ables, **L**istings, and **F**igures. +- [ospsuite.reportingengine](https://www.open-systems-pharmacology.org/OSPSuite.ReportingEngine/) for automated generation of model reports. +- [ospsuite.utils](https://www.open-systems-pharmacology.org/OSPSuite.RUtils/) provides a collection of utility functions useful for R packages in the OSP ecosystem. - [ospsuite.parameteridentification](https://github.com/Open-Systems-Pharmacology/OSPSuite.ParameterIdentification) provides the functionality of performing parameter identification (i.e., fitting the model to observed data) with simulations. The package is currently under development and everyone is encouraged to contribute. **OSP Qualification Framework and R packages are not included in the main OSP Suite setup and must be installed separately. Installation instructions are provided in the documentation of the tools or on the GitHub download site.** @@ -67,12 +67,17 @@ PK-Sim can also import and export *project snapshots* in [JSON format](https://e ## Code Status +[![](https://img.shields.io/github/downloads/Open-Systems-Pharmacology/Suite/latest/total?label=%E2%AD%B3%20Downloads%20latest%20release)](https://github.com/Open-Systems-Pharmacology/Suite/releases/latest) +[![](https://img.shields.io/github/downloads/Open-Systems-Pharmacology/Suite/total?label=%E2%AD%B3%20Downloads%20total)](https://github.com/Open-Systems-Pharmacology/Suite/releases) + [![Setup status](https://ci.appveyor.com/api/projects/status/1p3m417amhra2gic/branch/develop?svg=true&passingText=Suite-Setup)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/suite/branch/develop) [![PK-Sim status](https://ci.appveyor.com/api/projects/status/65aa66s8aj2tcp45/branch/develop?svg=true&passingText=PK-Sim)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/pk-sim/branch/develop) [![MoBi status](https://ci.appveyor.com/api/projects/status/qgv5bpwys5snl7mk/branch/develop?svg=true&passingText=MoBi)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/mobi/branch/develop) [![R status](https://ci.appveyor.com/api/projects/status/5ug50xlaot1x59jy/branch/develop?svg=true&passingText=ospsuite-r)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/ospsuite-r/branch/develop) [![Installation Validator status](https://ci.appveyor.com/api/projects/status/hffh219angc4svdh/branch/develop?svg=true&passingText=InstallationValidator)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/installationvalidator/branch/develop) +[![Check Markdown links](https://github.com/Open-Systems-Pharmacology/Suite/actions/workflows/MarkdownLinksCheck.yml/badge.svg)](https://github.com/Open-Systems-Pharmacology/Suite/actions/workflows/MarkdownLinksCheck.yml) +[![XRefCheck](https://github.com/Open-Systems-Pharmacology/Suite/actions/workflows/XRefCheck.yml/badge.svg)](https://github.com/Open-Systems-Pharmacology/Suite/actions/workflows/XRefCheck.yml) ## Software installation diff --git a/appveyor.yml b/appveyor.yml index 279196c..4d13bc5 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -1,7 +1,7 @@ version: '{build}' init: -- ps: Update-AppveyorBuild -Version "$($env:ospsuite_version).$($env:appveyor_build_version)" +- ps: Update-AppveyorBuild -Version "$($env:ospsuite_nightly_version).$($env:appveyor_build_version)" install: - cmd: set PATH=C:\Ruby22\bin;%PATH% @@ -21,7 +21,7 @@ install: Copy-Item C:\MikTex.msi . -build_script: rake "create_setup[%APPVEYOR_BUILD_VERSION%]" +build_script: rake "create_setup[%APPVEYOR_BUILD_VERSION%, hotfix/11.3]" artifacts: - path: "**/output/OSPSuite*.exe" diff --git a/validation and qualification/BatchComparison/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_13_09_54.pdf b/validation and qualification/BatchComparison/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_13_09_54.pdf new file mode 100644 index 0000000..72fe74b Binary files /dev/null and b/validation and qualification/BatchComparison/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_13_09_54.pdf differ diff --git a/validation and qualification/PlattformTest_Results/01_Win10_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_5_54_43.pdf b/validation and qualification/PlattformTest_Results/01_Win10_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_5_54_43.pdf new file mode 100644 index 0000000..61b6691 Binary files /dev/null and b/validation and qualification/PlattformTest_Results/01_Win10_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_5_54_43.pdf differ diff --git a/validation and qualification/PlattformTest_Results/02_Win2016_Server_UpgradeFrom_11.2/Open Systems Pharmacology Suite - 11-Installation Validation_04_03_24_12_32_40.pdf b/validation and qualification/PlattformTest_Results/02_Win2016_Server_UpgradeFrom_11.2/Open Systems Pharmacology Suite - 11-Installation Validation_04_03_24_12_32_40.pdf new file mode 100644 index 0000000..95dae5f Binary files /dev/null and b/validation and qualification/PlattformTest_Results/02_Win2016_Server_UpgradeFrom_11.2/Open Systems Pharmacology Suite - 11-Installation Validation_04_03_24_12_32_40.pdf differ diff --git a/validation and qualification/PlattformTest_Results/03_Win2019_Server/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_19_56_03.pdf b/validation and qualification/PlattformTest_Results/03_Win2019_Server/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_19_56_03.pdf new file mode 100644 index 0000000..0fcd515 Binary files /dev/null and b/validation and qualification/PlattformTest_Results/03_Win2019_Server/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_19_56_03.pdf differ diff --git a/validation and qualification/PlattformTest_Results/04_Win11_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_20_07_20.pdf b/validation and qualification/PlattformTest_Results/04_Win11_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_20_07_20.pdf new file mode 100644 index 0000000..2838442 Binary files /dev/null and b/validation and qualification/PlattformTest_Results/04_Win11_EN/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_20_07_20.pdf differ diff --git a/validation and qualification/PlattformTest_Results/05_Win11_Japanese/Open Systems Pharmacology Suite - 11-Installation Validation_04_09_24_10_33_01.pdf b/validation and qualification/PlattformTest_Results/05_Win11_Japanese/Open Systems Pharmacology Suite - 11-Installation Validation_04_09_24_10_33_01.pdf new file mode 100644 index 0000000..5a5f10a Binary files /dev/null and b/validation and qualification/PlattformTest_Results/05_Win11_Japanese/Open Systems Pharmacology Suite - 11-Installation Validation_04_09_24_10_33_01.pdf differ diff --git a/validation and qualification/PlattformTest_Results/06_Win11_Chinese/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_23_37_13.pdf b/validation and qualification/PlattformTest_Results/06_Win11_Chinese/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_23_37_13.pdf new file mode 100644 index 0000000..e0bb271 Binary files /dev/null and b/validation and qualification/PlattformTest_Results/06_Win11_Chinese/Open Systems Pharmacology Suite - 11-Installation Validation_04_08_24_23_37_13.pdf differ diff --git a/validation and qualification/README.md b/validation and qualification/README.md index 592de09..c6391a3 100644 --- a/validation and qualification/README.md +++ b/validation and qualification/README.md @@ -6,10 +6,10 @@ ### Unit and integration tests -* [PK-Sim](https://ci.appveyor.com/project/open-systems-pharmacology-ci/pk-sim/builds/46710845/tests) -* [MoBi](https://ci.appveyor.com/project/open-systems-pharmacology-ci/mobi/builds/46710844/tests) -* [Installation Validator](https://ci.appveyor.com/project/open-systems-pharmacology-ci/installationvalidator/builds/46052834/tests) -* [OSPSuite.Core](https://ci.appveyor.com/project/open-systems-pharmacology-ci/ospsuite-core/builds/46710346/tests) +* [PK-Sim](https://ci.appveyor.com/project/open-systems-pharmacology-ci/pk-sim/builds/49532883/tests) +* [MoBi](https://ci.appveyor.com/project/open-systems-pharmacology-ci/mobi/builds/49532885/tests) +* [Installation Validator](https://ci.appveyor.com/project/open-systems-pharmacology-ci/installationvalidator/builds/49502608/tests) +* [OSPSuite.Core](https://ci.appveyor.com/project/open-systems-pharmacology-ci/ospsuite-core/builds/49449092/tests) * OSPSuite.SimModel * [Windows](https://ci.appveyor.com/project/open-systems-pharmacology-ci/ospsuite-simmodel/builds/45143194/job/hc7ib82c2yci6xja/tests) * [Linux (Ubuntu 18.04)](https://ci.appveyor.com/project/open-systems-pharmacology-ci/ospsuite-simmodel/builds/45143194/job/0ljw5ow7utjt47vp/tests) diff --git a/versions.json b/versions.json index 99f09c9..5d3a16e 100644 --- a/versions.json +++ b/versions.json @@ -1,14 +1,14 @@ [ { "name": "PK-Sim", - "version": "11.2" + "version": "11.3" }, { "name": "MoBi", - "version": "11.2" + "version": "11.3" }, { "name": "BuildingBlockTemplates", - "version": "1.1" + "version": "1.2" } ] diff --git a/versions.xml b/versions.xml index 2abc384..40fefaf 100644 --- a/versions.xml +++ b/versions.xml @@ -1,9 +1,9 @@ - 11.2 + 11.3 - 11.2 + 11.3