| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| start [2017/12/22 11:03] – [Documentation] smilauer | start [2018/12/14 20:59] – Added workflow editor demo 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 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. |
| {{ :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 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. |
| | |
| |
| ====== Documentation ====== | ====== Documentation ====== |
| * Developping custom simulation scenarios | * Developping custom simulation scenarios |
| * Practical session on platform usage | * Practical session on platform usage |
| The cost of the course is 200 EUR/person. Course will be held in Prague at the Czech Technical University. Minimum of 5 participants per course. | The cost of the course is 400 EUR/person. Course will be held in Prague at the Czech Technical University. Minimum of 5 participants per course. |
| ===== Authors & Credits ===== | ===== Authors & Credits ===== |
| Mupif developpers: | Mupif developpers: |
| |
| ====== 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/]]. |
| * 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 |
