Speaker
Description
URL(s) for further info
http://insilicolab.cyfronet.pl/
Wider impact and conclusions
Three production science gateways based on the InSilicoLab framework already operate for scientific communities – for the Computational Chemistry domain and for two different branches of Astrophysics – the simulation of and observations with Cherenkov Telescope Array (for the CTA project) and for Magneto-Hydrodynamics simulations.
There is also an on-going work on another three portals – two for Bioinformatics communities and one for Geophysics.
An important asset of the InSilicoLab framework is that the individual gateways may be developed also by the scientists themselves, given that they have some programming experience. We were able to prove that with the example of the gateway for Magneto-Hydrodynamics simulations, which was developed by one of the simulation codes author.
Description of work
While designing each InSilicoLab portal, maximum stress is always put on the utility of the tool. This means user-friendliness but, even more importantly, serving real scientific problems. In this sense, such a portal cannot be generic – suitable to solving all scientific computational problems. Instead, it has to be suited to solve a specific problem or a family of problems, in the way the scientists understand best. To achieve that, the portal has to be built by observing the ways the target group of scientists work, and spotting the common problems they face, ensuring that the solution that is built is as close to the actual research as possible.
At the same time, the InSilicoLab framework offers a basis and tools for the development of each gateway, including the layer of communication with the distributed computing infrastructures, so that the development required to set up a new gateway is limited to only one layer – the one closest to the user.
The framework architecture is composed of three layers: Domain Layer, Mediation Layer and Resource Access Layer.
The Domain Layer is responsible for interactions with the user, its objects come from the language of the user’s domain of science. The Resource Access Layer, on the other hand, communicates with the computation and storage resources, and thus, have to use the language of the distributed infrastructure. The middle layer – Mediation Layer – acts as a translator between the domain objects and processes and the infrastructure-specific commands.
Such pattern enables the framework to be generic – the two lower layers create a fixed basis, while the Domain Layer changes for each scientific domain.
