Skip to main content

Simulation framework application facilitating simulation of interconnected models

Project description

USAGE

Environment

You will have to set up the following environment variabl:

export CMAKE_PREFIX_PATH="${installation_directory}/lib/cmake/modena/

for example:

export CMAKE_PREFIX_PATH="/usr/local/lib/python3.8/dist-packages/modena/lib/cmake/modena/"

External dependencies

You need R to have access to Design of Experiments:

in order

apt-get install -y automake libltdl-dev libltdl7 mongodb python3-scipy python3-rpy2 python3-blessings r-base r-base-dev build-essential swig cmake systemd

R -e "install.packages('lhs', repos='https://cran.ma.imperial.ac.uk/', lib=.libPaths()[1], dependencies=TRUE)"

pip3 install -U Jinja2

R -e "install.packages('nlmrt', repos='https://cran.ma.imperial.ac.uk/', lib=.libPaths()[1], dependencies=TRUE)"

Workflows

You need to have mongodb running - service mongodb start

Workflows have to be defined by the user

MoDeNa in Brief

A software Framework for MOdelling of morphology DEvelopment of micro- and NAnostructures

The MoDeNa project aims at developing, demonstrating and assessing an easy-to-use multi-scale software framework application under an open-source licensing scheme that delivers models with feasible computational loads for process and product design of complex materials. The concept of MoDeNa is an interconnected multi-scale software framework. Four scales will be linked together by this framework namely the nano-, micro-, meso-, and macroscale. As application cases we consider polyurethane foams (PU), which are excellent examples of a large turnover product produced in a variety of qualities and of which the properties are the result of designing and controlling the material structure on all levels of scale, from the molecule to the final product.

Multi-scale coupling requires the exchange of information between software instances developed for specific scales in a consistent way. In order to achieve this, generating consistent representations for models and data is necessary. The information exchange is governed by protocols and may occur in two ways, namely:

  • "forward mapping" (passing information from the microscopic to the macroscopic scale in upward direction)

  • "backward mapping" (passing information from the macroscopic to the microscopic scale in downward direction)

"Forward mapping" is relatively straightforward, while "backward mapping" inevitably requires iteration since changing the operating conditions at the fine level changes the feedback to the coarse level. "Backward mapping" can be realised by "two-way coupling" or by "fitting surrogate models". The first approach usually requires exchange of large amounts of data during runtime that may be expensive either due to the complexity of the data exchange or the computational cost associated with executing the microscopic-scale simulation. In such cases, replacing the microscopic-scale simulation with a surrogate model presents the only viable alternative. This operation inherently constitutes a transfer of data across scales and MoDeNa is unique in that it focuses on this approach.

A typical operation sequence starts a macroscopic-scale simulation which instantiates one or more surrogate models. When the validity of a model is violated, a design of experiment operation is triggered. It creates inputs for a set of microscopic-scale simulations. When all experiments are finished, the parameter estimation component is invoked which updates the model parameters. Next, the macroscopic-scale simulation is restarted. It should be noted, that the MoDeNa software framework supports application and model dependencies across multiple scales.

The MoDeNa framework handles the communication across scales through recipes and adapters. Recipes perform simulations by executing applications (in-house codes or external software packages such as FOAM, Materials Studio, PC-Saft) for a given set of inputs. Adapters handle the communication with the MoDeNa software framework. Both, recipes and adapters are application specific. Adapters exist as outgoing and incoming adapters. Outgoing adapters are relatively straight forward in that they perform a mapping operation (such as averaging) and communicate the results. The averaging process may have to be started and performed within the application (e.g. for time averaging). However, the results can usually be submitted in a separate process after the simulation is finished. Incoming adapters are more complicated since they usually require to embed surrogate models within the applications.

The software framework consists of an orchestrator, a database and a interface library. The orchestrator is based on FireWorks and constitutes the backbone of the software framework in that it schedules simulations as well as design of experiments & parameter estimation operations which make up the work-flow of the overall simulation. It is very much like a dynamic work-flow engine, in which the different applications are "orchestrated" to obtain information, analyse and pass it to the other operations. The NoSQL database MongoDB is used to store the state of the work-flow as well as the surrogate models together with associated data such as model parameters, data used for parameter estimation, and meta-data.

The interface library consists of two parts: A high-level python module providing access to the database as well as design of experiments and regression analysis capabilities by building on MongoEngine and R, respectively. The second part is a low-level library providing unified access to the surrogate models. This component is written in C to ensure interoperability across platforms and target applications while providing the computationally efficient model execution required by the applications. The library is loaded as a shared library by the macroscopic-scale applications or as a native python extension by the high-level python module ensuring that all components instantiate identical model implementations. Complex operations such as database access are referred back to the high-level python module using call-back mechanisms.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

modena-0.0.2.tar.gz (198.9 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

modena-0.0.2-py3-none-any.whl (209.3 kB view details)

Uploaded Python 3

File details

Details for the file modena-0.0.2.tar.gz.

File metadata

  • Download URL: modena-0.0.2.tar.gz
  • Upload date:
  • Size: 198.9 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.1 CPython/3.8.10

File hashes

Hashes for modena-0.0.2.tar.gz
Algorithm Hash digest
SHA256 da9af67645689e464dd1ba3a33409abd4f425ddccf35385429dc58c79a989de2
MD5 8f88784774c91b8f20e2c12d047baae1
BLAKE2b-256 cca3d32ee9ad823261cc981489e0c40c73f0fdecbb34106a3d5d148e2a1faecf

See more details on using hashes here.

File details

Details for the file modena-0.0.2-py3-none-any.whl.

File metadata

  • Download URL: modena-0.0.2-py3-none-any.whl
  • Upload date:
  • Size: 209.3 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.1 CPython/3.8.10

File hashes

Hashes for modena-0.0.2-py3-none-any.whl
Algorithm Hash digest
SHA256 6b0da97c27c0fbe364a174c9d1a6be8223904d464a7901902170a5c5dd526027
MD5 6d04d22b99bbb77b59a9f8eb3add0f1a
BLAKE2b-256 f0416db87d1b0fb435a0967bcf8791cc6e7208a2a50fa4bee83d8e8b8ee47962

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page