| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| start [2018/12/13 15:20] – [Related Publications] bp | start [2019/01/25 15:29] – [Implementation] bp |
|---|
| 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 itself. The 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. |
| |
| ===== Implementation ===== | ===== Implementation ===== |
| Rather than writing programs, the Python language will be extended by modules, representing interfaces to existing codes, with 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 ====== |
| |
| ====== 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/]]. |
