User Tools

Site Tools


start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
start [2018/06/22 14:31]
127.0.0.1 external edit
start [2019/01/25 15:29] (current)
bp [Implementation]
Line 5: Line 5:
 MuPIF is modular, object-oriented integration platform allowing to create complex, distributed,​ multiphysics simulation workflows across the scales and processing chains by combining existing simulation tools. MuPIF uses Python 3.5 standards and is independent on operating system (Linux, UNIX, Windows, Mac, ...). MuPIF is modular, object-oriented integration platform allowing to create complex, distributed,​ multiphysics simulation workflows across the scales and processing chains by combining existing simulation tools. MuPIF uses Python 3.5 standards and is independent on operating system (Linux, UNIX, Windows, Mac, ...).
 [[https://​twitter.com/​@ComposelectorH|{{ :​wiki:​images:​twitter-bird.png?​50|}}]] [[https://​twitter.com/​@ComposelectorH|{{ :​wiki:​images:​twitter-bird.png?​50|}}]]
 +
 +
  
 ===== Framework Design ===== ===== Framework Design =====
-A reliable multiscale/​multiphysics numerical modeling requires including all relevant physical phenomena along the process chain, typically involving multiple scales, and the combination of knowledge from multiple fields. A pragmatic approach lies in combining existing tools, The approach followed in MuPIF is based on an system of distributed,​ interacting components designed to solve given problem. The individual components represent entities ​in the problem domain, including individual simulation packages, high level data, but also the workflows. The abstract classes are introduced ​for all entities in the model space, defining common interfaces that needs to be implemented by any derived class, representing particular implementation of specific component. Such interface concept allows using any derived class on a very abstract level, using common services defined by abstract class, without being concerned with the implementation details of an individual software component. This essentially allows to manipulate all models, data, and workflows using standardized interfaces. Moreover, as the simulation data are represented by objects as well, the platform is independent on particular data format(s), as the simulation data (such as microstructures,​ fields and properties) ​can be manipulated using the same abstract ​interface. Therefore, the focus on services ​is provided by objects (object interfaces) and not on underlying data itselfThe abstraction ​allows to treat local as well as remote objects using the same interface making the platform naturally distributed. ​  +A reliable multiscale/​multiphysics numerical modeling requires including all relevant physical phenomena along the process chain, typically involving multiple scales, and the combination of knowledge from multiple fields. A pragmatic approach lies in combining existing tools, The approach followed in MuPIF is based on an system of distributed,​ interacting components designed to solve given problem. The individual components represent ​different ​entities, including individual simulation packages ​and simulation workflows, high level data, external databases, etc. The top-level ​abstract classes are introduced ​covering ​all entities in the model space, defining common interfaces that need to be implemented by any derived class, representing particular implementation of specific component. Such interface concept allows using any derived class on a very abstract level, using common services defined by abstract class, without being concerned with the implementation details of an individual software component. This essentially allows to manipulate all models, data, and workflows using standardized interfaces. Moreover, as the complex ​simulation data are represented by objects as well, the platform is independent on particular data format(s), as they can be manipulated using same abstract ​interfaces. Therefore, the focus is on services provided by objects (object interfaces) and not on underlying ​object'​s ​data. In addition, the distributed design ​allows to treat local as well as remote objects using the same interface making the platform naturally distributed. ​  
-{{ :​wiki:​images:​mupif-map.png?direct&​400|MuPIF Features}}+{{ :​wiki:​images:​mwg_full.gif?nolink|}}
  
 Even though the platform can be used locally on a single computer orchestrating installed applications,​ the real strength of the MMP platform is its distributed design, allowing to execute simulation scenarios involving remote applications. MuPIF provides a transparent distributed object system, which takes care of the network communication between the objects when they are distributed over different machines on the network. One can just call a method on a remote object as if it were a local object – the use of remote objects is (almost) transparent. This is achieved by using the concept of proxies representing remote objects, which forward the calls to the remote objects and pass the results back to the calling code. In this way, there is no difference between simulation script for local or distributed case, except for the initialization,​ where, instead of creating local object, one has to connect to the remote object. ​ Even though the platform can be used locally on a single computer orchestrating installed applications,​ the real strength of the MMP platform is its distributed design, allowing to execute simulation scenarios involving remote applications. MuPIF provides a transparent distributed object system, which takes care of the network communication between the objects when they are distributed over different machines on the network. One can just call a method on a remote object as if it were a local object – the use of remote objects is (almost) transparent. This is achieved by using the concept of proxies representing remote objects, which forward the calls to the remote objects and pass the results back to the calling code. In this way, there is no difference between simulation script for local or distributed case, except for the initialization,​ where, instead of creating local object, one has to connect to the remote object. ​
Line 15: Line 17:
  
 ===== Implementation ===== ===== Implementation =====
-Rather than writing programs, the Python language ​will be extended by modules, representing interfaces to existing codeswith specific functionality. The emphasis ​will be on building infrastructure to facilitate the implementation of multi-physic and multi-level simulations. The high-level language serves as a “glue” to tie the modules or components together, to create specialized application. Python language provides the flexibility,​ interactivity,​ and extensibility needed for such an approach, thanks to its concise and pseudocode-like syntax, modularity and object-oriented design, introspection and self documentation capability, and the availability of a Numerics extension allowing the efficient storage and manipulation of large amounts of numerical data. The application interface can be conveniently realized by wrapping application code. The process of wrapping code can be automated to a fair extent using [[http://​www.swig.org/​|SWIG]],​ [[http://​www.boost.org|Boost]],​ or similar tools, which can generate wrapper code for several languages. This approach also allows a single source version of the component code to be maintained. ​+Rather than writing programs, the Python language ​is extended by modules, representing interfaces to existing codes and data structures ​with specific functionality. The emphasis ​is on building infrastructure to facilitate the implementation of multi-physic and multi-level simulations. The high-level language serves as a “glue” to tie the modules or components together, to create specialized application. Python language provides the flexibility,​ interactivity,​ and extensibility needed for such an approach, thanks to its concise and pseudocode-like syntax, modularity and object-oriented design, introspection and self documentation capability, and the availability of a Numerics extension allowing the efficient storage and manipulation of large amounts of numerical data. The application interface can be conveniently realized by wrapping application code. The process of wrapping code can be automated to a fair extent using [[http://​www.swig.org/​|SWIG]],​ [[http://​www.boost.org|Boost]],​ or similar tools, which can generate wrapper code for several languages. This approach also allows a single source version of the component code to be maintained.  
 +The simulation workflows are implemented as Python scripts built on top of MuPIF. The graphical workflow editor is available to make the workflow implementation more accessible and convenient.
  
 ====== Documentation ====== ====== Documentation ======
Line 56: Line 59:
  
 ====== Resources ====== ====== Resources ======
-  * [[https://www.dropbox.com/sh/judps2lshqnvup8/​AAAeOo4Pa6g5rOHfr5PLCXcJa?​dl=0|MuPIF Graphical Workflow Editor]], which creates ​ MuPIF workflow models based on a MuPIF workflow metamodel, ​generates Python ​scripts from MuPIF workflow models, and can run MuPIF Python scripts and monitor their executions+  * [[https://github.com/mupif/mupif-workflow-generator|MuPIF Graphical Workflow Editor]], which provides graphical environment to compose simulation workflows and generates ​executable representation of simulation workflows in Python. ​
 ===== Related tools ===== ===== Related tools =====
   * Python Programming Language, [[http://​www.python.org/​]].   * Python Programming Language, [[http://​www.python.org/​]].
Line 66: Line 69:
   * B. Patzak, V. Smilauer, and G. Pacquaut, presentation & paper “Design of a Multiscale Modelling Platform” at the 15 th International Conference on Civil, Structural, and Environmental Engineering Computing, 1st - 4th of September 2015, Prague (Czech Republic).   * B. Patzak, V. Smilauer, and G. Pacquaut, presentation & paper “Design of a Multiscale Modelling Platform” at the 15 th International Conference on Civil, Structural, and Environmental Engineering Computing, 1st - 4th of September 2015, Prague (Czech Republic).
   * B. Patzák, V. Šmilauer, M. Apel, R. Altenfeld, L. Thielen, A. Lankhorst, [[http://​congress.cimne.com/​icme2016/​admin/​files/​filepaper/​p67.pdf|Multi-Physics Integration Framework MuPIF – design, operation and application to simulate CIGS thin film growth for photovoltaics]],​ 2nd International Workshop on Software Solutions for ICME, April 2016, Barcelona, Spain. ​   * B. Patzák, V. Šmilauer, M. Apel, R. Altenfeld, L. Thielen, A. Lankhorst, [[http://​congress.cimne.com/​icme2016/​admin/​files/​filepaper/​p67.pdf|Multi-Physics Integration Framework MuPIF – design, operation and application to simulate CIGS thin film growth for photovoltaics]],​ 2nd International Workshop on Software Solutions for ICME, April 2016, Barcelona, Spain. ​
 +   * B. Patzák, V. Šmilauer and M. Horák. MuPIF: Multi-Physics Integration Platform. 6th European Conference on Computational Mechanics (ECCM 6), Glasgow, 2018. 
 +   * S. Belouettar, C. Kavka, B. Patzák, H. Koelman, G. Rauchs, G. Giunta, A. Madeo, S. Pricl, S. et al. Integration of material and process modelling in a business decision support system: Case of COMPOSELECTOR H2020 project. Composite Structures, 204, 778-790, 2018.
 ===== Projects using MuPIF===== ===== Projects using MuPIF=====
   * MuPIF used as modeling platform in H2020 [[http://​composelector.net|Composelector]] project   * MuPIF used as modeling platform in H2020 [[http://​composelector.net|Composelector]] project
start.1529670701.txt.gz · Last modified: 2018/06/22 14:31 by 127.0.0.1