As raised by #307, we should add better documentation of the distributions you can select for inputs to a problem.

This issue that surfaced from conversation with @henrymoss .

If you wanted to do parallel evaluations of your objective, you might be able to do that with Emukit, but it isn't obvious how to get started. A good tutorial would be nice to help people out.

If I build SUNDIALS as given here and encoded as a nix derivation thus

{ stdenv
, cmake
, fetchurl
, openmpi
, llvmPackages
, python
, liblapack
, gfortran
, lapackSupport ? true }:

let liblapackShared = liblapack.override {
  shared = true;
};
    openmp = llvmPackages.openmp;

in stdenv.

Describe the bug
If eps_r is shape (N,) then the fields solved are shape (N,1)

Either:

• disallow 1-D eps_r arrays
  Or:
• keep track of eps_r shape and reshape the fields to match.

Any help in developing the following essential unit operations would be greatly appreciated:

• Compressor
• Turbine
• Fenske-Gilliland-Underwood shortcut column (added 3/22/2020)
• Rigorous heat exchanger for heat integration (added 6/6/2020)
• Multi-component distillation models (preferably MESH equation based)
• Kinetic fermentation models
• ~Centrifuge modeled by liquid-liquid equi

Hi all,

Can we add the FEM formulation that we use for solving the incompressible and variable-density (low-Mach) Navier-Stokes equations to the docs somewhere?

I did a cursory search on the website/doxygen documentation - but couldn't find it.

Currently, the representation is kind of hard to work with. Maybe we should have a solution type that stores sensitivities as a matrix, and stores the ODE solution separately, e.g.

struct ODELocalSensitivitySolution{S<:AbstractODESolution,D<:AbstractMatrix}
  sol::T
  sen::D
end

In ode_export, symbolic comparison should be used instead of string comparison (see #1060):
https://github.com/ICB-DCM/AMICI/blob/77dd58a3b92d43b1e0895c49a2f835c5c1181c2e/python/amici/ode_export.py#L2170
This is currently not possible, as some model quantities do not pass symbolics, but strings (e.g., dwdx).. One should find out, which routines pass string and make them pass symbolics, then cha

One thing that would make the generated API documentation more readable is to move the "Detailed Description" to the top of the page. This can be done by providing a layout file (https://stackoverflow.com/questions/19831837/documenting-with-doxygen-put-details-on-top).

It would also be useful to provide some consistent guidelines for documenting all classes and work towards them.

• http://www.

I have some suggestions on how to make an actual documentation for OpenCossan (yes again 😄) since now the Wiki is pretty much outdated (at least for development) and the internal Matlab documentation is horrible to use.

I will prepare an example of what I have in mind and present it at the first day of the Cossanthon.

We should have automatic unit tests to run in addition to the simple CI builds to ensure builds perform as expected.

From the Dakota docs, either step_vector or final_point can be chosen as a parameter for a vector parameter study. Currently, only final_point has been implemented.