ViroLab Virtual Laboratory

Entire manual table of contents.

Powered by GridSpace.

The demo of the system used in the ViroLab project is available at http://gs.cyfronet.pl. But note that the GridSpace technology presented there is now being replaced by a new version GridSpace2. To see the demo of this new version please go to https://gs2.cyfronet.pl/.

Visit us on http://dice.cyfronet.pl.

What is this page about?

The Virtual laboratory is a set of integrated components that, used together, form a distributed and collaborative space for science. Multiple, geographically-dispersed laboratories and institutes use the virtual laboratory to plan, and perform experiments as well as share their results. The term experiment in this context means a so-called in-silico experiment - that is, a process that combines data and computations in order to obtain new knowledge on the subject of an experiment.

Here we introduce a virtual laboratory that is built for the ViroLab Project. In this scope the laboratory is prepared to support virologists, epidemiologists and clinicians investigating the HIV virus and the possibilities of treating HIV-positive patients. Although the ViroLab Virtual Laboratory is being built specifically for this domain of science, the conceptual solutions and the technology developed could be reused for other domains.

Below you will find information about different aspects of the laboratory: who uses it and for what purpose, what are its components, how the integration is provided and so forth. These introductory pages are intended to convey the most general and most important information, however further on (should you wish to) you will also be able to see a far more detailed and technical view of the ViroLab Virtual Laboratory.

Quick shortcuts
Demonstrations
ExperimentPlanning
ExperimentUse
ResultsManagement
VirtualLabArchitecture

On the bottom of this page you may find our contact information. If you have any further questions, please do not hesitate to ask us directly. We are open for any remarks regarding this page or the technology we build and provide as well as any possibilities of collaboration. In particular, if you feel this kind of virtual laboratory could be of use in your domain of science, contact us directly and we will be happy to discuss possibilities of cooperation.

Experiment pipeline and classes of users

The central idea behind any virtual laboratory is an (in-silico) experiment.

Experiment is a process that combines together data with a set of activities that act on that data in order to yield experiment results. The substrate data required for an experiment may be obtained from multiple resources in various possible forms. The activities may be manual, semi-manual or fully automatic, depending on their nature. No definite restrictions are imposed on the level of complexity of such an experiment: it might be as simple as listing data inside some remote database, or much more complex, such as a set of simulators combined together to obtain some insight into complex phenomena. Moreover, the experiments are not required to involve just a single, local machine – in fact, the power of the virtual laboratory comes from combining multiple distributed resources, dispersed over various geographical locations.

The purpose of the laboratory we present is to support collaborative work of all the people who are effectively involved in any stage of the experimentation process. For our purpose, we refer to this process as the experiment pipeline. Below is a section that explains our view of the subject.

Experiment pipeline

Experiment pipeline
Figure 1. The generic, simplest version of the experiment pipeline.

Figure 1 presents the simplest picture of the experiment pipeline. First of all, one has to decide what an experiment is about and how it should proceed. The part of the pipeline concerning design of the future experiment process is called experiment planning. During that phase the user has to decide upon the main subject of the planned experiment, its intended results and the means by which these results should be obtained. Such a detailed description of the experiment results in experiment execution (the middle part of the process). During this phase the user performs the experiment according to the plan developed at the planning stage, using all the resources provided to that user within the virtual laboratory. The usual outcome of such execution is the result of the experiment. Since the result itself is of the highest importance for the user, special attention is given to it in the last phase of the pipeline, called result management. Here the outcome of the experiment may be evaluated, described and stored. Given the strong collaboration aspect of a virtual laboratory, the results can also be shared among the users of the laboratory. This stage concludes a single experiment pipeline run.

It should be stressed that no single part of this pipeline has to be a one-off activity. It is very probable, and in fact expected, that various stages will be repeated in order to achieve the correct effect or desired quality. The idea of iterative experiment process and feedback between different phases of the pipeline will be presented in the following sections.

Defined classes of users

As the virtual laboratory is meant to combine together people of various levels of expertise, we define two main classes of users who take part in the experiment pipeline. Their descriptions are provided here, while another class of users (sharing a common phase in the experiment pipeline) will be introduced later on.

Experiment developer is a person who designs experiments in a specific domain (like e.g. virology). First of all, this means that the person is skillful enough to design and denote the way an experiment should proceed. Apart from technical skills, the developer also possesses a certain level of domain-related knowledge to understand the nature of the processes the experiment should model – otherwise, the designed experiments will never be valid. However, it is usually not required for a developer to fully comprehend all the data and results of a specific experiment, provided there is appropriate expert (scientist) assistance available to evaluate the developer’s work. This assistance provides initial requirements and descriptions of the desired experiment, and also feedback on the developed experiment. The developer uses dedicated tools to – among others – search for available data sources, combine them with suitable computational activities and present the results in an appropriate form. The aim of the virtual laboratory is to give experiment developers a set of powerful tools making their task easier, while at the same time not constraining their skill and creativity in any way. If you wish to explore the developer’s part of these manual pages, please visit the ExperimentPlanning section. The Architecture technical section could also be of interest to you.


Experiment user is any person who runs a previously prepared experiment in order to obtain results. The user may or may not be involved in the process of experiment preparation – in the latter case it is probable that (future) experiment users would support developers with their expert knowledge about the modeled phenomenon. The main objective of the experiment user is to obtain valuable results that answer important questions. The following chapters divide the experiment user class into specific subclasses of scientists and clinicians.

Layers of the virtual laboratory

Layers of virtual laboratory
Figure 2. Different layers of ViroLab Virtual Laboratory .

Before we go back to the detailed analysis of the experiment pipeline, let us take a look on the overall picture of the laboratory. Figure 2 shows in a conceptual way the various layers that constitute the virtual laboratory. While this layered cake type of visualization is rather abstract and the real architecture behind is far more complex (see VirtualLabArchitecture for details) it shows very well the separation of levels. In the upper part we have the set of users (with two classes introduced lately and another one explained later on). The users perform their tasks using a set of tools that are grouped in the interfaces part: there are dedicated tools for each group. The centerpiece of the architecture, the unified runtime system, is the part that allows these various users and their tools understand each other. What is more, this runtime layer server as a bridge to resources dispersed in the virtual laboratory: both data sources and computational services. Finally, these services run on physical equipment that are at their disposal (the last layer). There are multiple solution here that are supported by our virtual laboratory -- among others it supports also large Grid computing testbeds (currently the adapter to EGEE testbed through the LCG software is being added and soon we plan to work on potential addition of the support for DEISA resources as well).

As one may see in Figure 2, the virtual laboratory serves as a natural point of integration of various tools, modules, protocols and interfaces into a single virtual space, where various types of users are able to (collaboratively, if they like) perform their tasks.

More detailed view

For now, let us dwell a little bit on the experiment pipeline. Figure 1 explains only the main activities required -- for more detailed insight, we require the resources that are used in the process. In Figure 3 one may find the part of the previously described process concerning substrate/product information: what a specific phase requires and what it yields in the process.

Extended experiment pipeline
Figure 3. Design and use of experiment with substrates and products.

The person who develops the experiment requires some information on the resources needed to perform the future experiment. According to the definition, the experiment can involve both remote data sources and activities that need to be performed on the data in order to achieve the final result. Let us consider a simple example of an experiment that is meant to classify a set of patients into some illness classes. Here, the initial information we have at the beginning of the experiment pipeline is as follows:

  1. Main idea: given a set of patient data, assigning the most likely illness (from a set) to each patient
  2. Input data: we require certain reachable information on each patient (e.g. some measurements recorded on a hospital database)
  3. Activities: we also need a classifier resource, able to understand patient data and assign an illness class on the basis of this data (and, possibly, some previous training of the internal classification model)

As is depicted in Figure 3, the developer has to be aware of those requirements in order to design a valid experiment. However, the person ultimately needs the description of the data (e.g. its format, language, amount of data recorded) rather then the data itself - this is a very important distinction which we have to stress. For instance, in the example presented before, it can make a real difference, since patient data stored at a hospital is usually very confidential. However, provided the developer needs only the format of the data (and, perhaps, some toy example for testing purposes), it is possible that such an experiment could be developed by a person not even employed by the hospital. Given enough information regarding the data to be processed and the processing itself, the developer is capable of creating an experiment plan.

Experiment plan is a recipe that describes the process of certain experiment execution in the environment of the virtual laboratory. Physically, it is a set of files that, combined together, contain enough information for experiment users and their tools to proceed with (hopefully successful) experiment execution. The division of the plan into distinct parts is meant mainly to keep it well structured and easier to maintain by experiment developers. The exact structure and contents of each experiment plan are described in the developer’s section of this manual (see ExperimentPlanning). An important aspect of the virtualization part inside the laboratory is the fact that experiment plans are subject to storing, versioning, exchange, collaborative design and use etc. Experiment plans are the central focus of the virtual experimental space of the laboratory.

Once prepared, our experiment plan is ready to perform real classification (in this way we enter the second phase of the experiment pipeline). Now we need access to real data (the database of patients) and the classification unit. Please note that since the experiment user (in this case, the medical doctor who requires aid in illness classification) is a different person than the developer, their respective privileges may differ. Since the experiment is executed on behalf of its user, it is now able to access vital data about the patients (which constitute the experiment input data part of Figure 3). Furthermore, the virtual laboratory that actually (in a technical sense) runs the experiment plan, connects to a remote classification server to make it perform the required analysis. Figure 3 refers to this step in general as experiment process activition -- those are the main functional blocks that constitute the experiment.

In the end, the experiment, successfully completed, should be able to provide experiment results. In the case of our sample experiment the result would be a table of patient-to-illness associations. Now, according to the generic experiment pipeline, the user who obtained that result may manage it any way he or she likes. The available options regarding the result management phase are covered in detail in another part of this manual (see the Results Management section).

Experiment result in its most general meaning covers anything that is produced in the course of experiment execution. It could consist of some textual information, a generated image or a movie, a URL link to further information—almost anything. While an experiment outcome may be difficult to quantify, such a quantification is usually useful for easier management of those results. There are no strict rules here—common sense of developers and users should be applied to decide what forms a separate result (for instance: a single image, a table of illness classifications, a file with a database table snapshot…) Since the result of an experiment is usually of the highest importance for the experiment user, the virtual laboratory devotes special attention to the management and post-experiment activities which act upon results (such as sharing, describing, storing etc.) The ResultsManagement section of this manual provides more information about the various possibilities involved.

Division of experiment users
Figure 4. Division of users.

Further on the classes of users

For the purpose of clarity we would like to introduce a distinction in the class of experiment users presented before. In the scope of the ViroLab virtual laboratory we distinguish two types of experiment users, called (for brevity's sake) scientists and clinicians (there may be many individuals combining together those two modes of use in their practice). Figure 4 shows a conceptual distinction between those two. The idea here is that scientists typically use specifically-tailored experiments, devoted to important areas of their science. The experiment plans they use tend to be dynamic -- answers obtained with the use of an experiment usually indicate what additions or alterations are needed in the experimental process to improve its results. This repeatable process of tuning requires a considerable amount of the researcher's time and is considered an important phase of scientific research.

On the other hand, there are people who require very specific, concrete experiments to be available to them every day. An example of such an experiment is the patent classification process described above. While the process of planning of such an experiment may take much time and require many iterations, once done, the user is usually content with it and the experiment becomes a part of everyday work of that user. The name clinicians is attributed to this class of users because the ViroLab project focuses on experiments that run every day to assist clinical virologists in their work.

While the purpose of use and the aim of obtained results differs, the underlaying mechanisms of experiment planning and execution remain the same. The ViroLab virtual laboratory is dedicated to support both modes of use. The additional arrows in Figure 4 between those two modes indicate different possible roads of experiment plan maturation. The experiment may be designed in a straightforward fashion, with daily clinical practice use in mind, or it could be first used in a scientific laboratory for obtaining research results and then, after some time, its use cases extended for clinical use (for instance, when pioneering measurements and indicators discovered by scientists are subsequently used in everyday healthcare provision to patients).

Where to go from here?

Having finished the general introduction to our virtual laboratory, we invite you to discover its functionality and ways of using it. The following tutorial is divided into parts which reflect the main activities involved in the experiment pipeline (explained at the beginning of this document):

Resources for experiment planning stage and developer tools Visit: ExperimentPlanning
Pages for scientists and anyone who wishes to use prepared experiments Visit: ExperimentUse
Pages for clinical virologists and users of prepared ViroLab applications Visit: ExperimentUse
Demonstrations of Virtual Lab Capabilities Visit: VirtualLabDemonstrations
Manuals for different forms of experiment result management Visit: ResultsManagement
Technical information on how the ViroLab virtual laboratory is built Visit: VirtualLabArchitecture

As you may have already discovered, we will use special colors and icons to denote sections of this manual which concern specific activities (and specific users) in the virtual laboratory -- look for a small badge in the top-left corner of each subpage. Some sections that are of common interest to various users groups will carry more then one badge. Nonetheless, even if you already know what type of information you are interested in, please visit other sections as well -- you may very well find some information that is both intriguing and useful to you.

If you have arrived at this point of the manual and you feel there is no class of activity defined that your use of the virtual laboratory could fall into, please contact us. It may well be that you have just discovered another interesting and valuable way of using our virtual laboratory that we haven't thought of. Use the contact information provided at the bottom of this page and let us discuss together what it would take to enable people like you to use and benefit from the solution we propose.

All this is interesting, tell me more!

Related publications

  • publications on the ViroLab virtual laboratory in general
    1. M. Bubak, T. Gubala, M. Malawski, M. Kasztelnik, T. Bartynski, P. Nowakowski; Virtual Laboratory in ViroLab Cracow Grid Workshop CGW'06 (poster presentation)
    2. P.M.A. Sloot, I. Altintas, M. Bubak, Ch.A. Boucher; From Molecule to Man: Decision Support in Individualized E-Health, IEEE Computer Society,vol 39, no.11, pp. 40-46, Nov., 2006
    3. M. Bubak, T. Gubala, M. Kasztelnik, M. Malawski, P. Nowakowski, P.M.A. Sloot; Collaborative Virtual Laboratory for e-Health, in P. Cunningham and M. Cunningham, editors, Expanding the Knowledge Economy: Issues, Applications, Case Studies, eChallenges e-2007 Conference Proceedings, pp. 537-544. IOS Press, Amsterdam, 2007.
    4. T. Gubala, B. Balis, M. Malawski, M. Kasztelnik, P. Nowakowski, M. Assel, D. Harezlak, T. Bartynski, J. Kocot, E. Ciepiela, D. Krol, J. Wach, M. Pelczar, W. Funika, M. Bubak; ViroLab Virtual Laboratory, in Cracow Grid Workshop 2007 Workshop Proceedings, pp. 35-40, ACC CYFRONET AGH 2008
    5. M. Kasztelnik, T. Gubala, M. Malawski, M. Bubak; Development and Execution of Collaborative Application on the ViroLab Virtual Laboratory, in Cracow Grid Workshop 2007 Workshop Proceedings, pp.41-46, ACC CYFRONET AGH 2008
    6. P.M.A. Sloot, A. Tirado-Ramos, M. Bubak: Multi-Science Decision Support for HIV Drug Resistance Treatment, in: P. Cunningham, M. Cunningham (Eds.): Expanding the Knowledge Economy: Issues, Applications, Case Studies, IOS Press, 2007, pp 597-606
    7. T. Gubala, M. Kasztelnik, M. Malawski, M. Bubak, Towards a System-Level Science Support. In: Bubak, M., Albada, G.D.v., Dongarra, J., Sloot, P.M.A. (Eds.), Proceedings ICCS 2008, Kraków, Poland, June 23-25, 2008, LNCS 5101, pp. 56-65, Springer 2008
    8. M. Bubak, T. Gubala, M. Malawski, B. Balis, W. Funika, T. Bartynski, E. Ciepiela, D. Harezlak, M. Kasztelnik, J. Kocot, D. Krol, P. Nowakowski, M. Pelczar, J. Wach, M. Assel, A. Tirado-Ramos: Virtual Laboratory for Development and Execution of Biomadical Collaborative Applications. S. Puuronen, M. Pechenizkiy, A. Tsymbal, D-J. Lee (eds) Proc. 21st IEEE International Symposium on Computer-Based Medical Systems, June 17-19, 2008, Jyvaskyla, Finland, p. 373 - 378, DOI 10.1109/CBMS.2008.47
    9. Marian Bubak et al., Virtual Laboratory for Collaborative Applications, In: M. Cannataro (Ed.) Handbook of Research on Computational Grid Technologies for Life Sciences, Biomedicine and Healthcare, Chapter 27, pp. 531-551, Information Science Reference, 2009, IGI Global
    10. P.M.A Sloot, Peter V. Coveney, G. Ertayalan, V. Mueller, C.A. Boucher, and M. Bubak: HIV decision Support: from Molecule to Man. Philosophical Transactions of the Royal Society A, vol 367, pp 2691 - 2703, 2009, doi:10.1098/rsta.2009.0043
    11. Matthias Assel, David van de Vijver, Pieter Libin, Kristof Theys, Daniel Harezlak, Breanndann O Nuallain, Piotr Nowakowski, Marian Bubak, Anne-Mieke Vandamme, Stijn Imbrechts, Raphael Sangeda, Tao Jiang, Dineke Frentz, and Peter Sloot: A Collaborative Environment Allowing Clinical Investigations on Integrated Biomedical Databases. In Tony Solomonides, Martin Hofmann-Apitius, Mathias Fredigmann, Sebastian Caludius Semler, Yannick Legre, and Mary Kratz: Healthgrid Research, Innovation and Business Case; Proceedings of HealthGrid 2009, Studies in Health Technology and Informatics, vol 147, IOS Press, ISSN 0926-9630, pp 51 -61
  • publications on specific parts of the virtual laboratory
    1. W. Funika, P. Pegiel; GScript Editor as a Part of the ViroLab Presentation Layer, Cracow Grid Workshop CGW'06 (poster presentation)
    2. T. Gubala, M. Bubak; GridSpace - Semantic Programming Environment for the Grid, 6-th International Conference on Parallel Processing and Applied Mathematics PPAM'2005, LNCS 3911, pp. 172-179, 2006
    3. M. Malawski, M. Bubak, M. Placek, D. Kurzyniec, V. Sunderam, Experiments with distributed component computing across Grid boundaries. In Proceedings of the HPC-GECO/CompFrame workshop in conjunction with HPDC 2006, Paris, 2006.
    4. T. Bartynski, M. Malawski, T. Gubala, M. Bubak; Universal Grid Client: Grid Operation Invoker, 7-th International Conference on Parallel Processing and Applied Mathematics PPAM'2007, LNCS 4967, Springer, 2008, pp. 1068-1077. presentation given at the conference is available here.
    5. T. Bartynski, M. Malawski, M. Bubak; Invocation of Grid Operations in the ViroLab Virtual Laboratory, in Cracow Grid Workshop 2007 Workshop Proceedings, pp.59-64, ACC CYFRONET AGH 2008
    6. E. Ciepiela, J. Kocot, T. Gubala, M. Malawski, M. Kasztelnik, M. Bubak; Virtual Laboratory Engine -- GridSpace Engine, in Cracow Grid Workshop 2007 Workshop Proceedings, pp.53-58, ACC CYFRONET AGH 2008
    7. M. Malawski, J. Kocot, E. Ciepiela, M. Bubak; Optimization of Application Execution in the ViroLab Virtual Laboratory, in Cracow Grid Workshop 2007 Workshop Proceedings, pp.65-70, ACC CYFRONET AGH 2008
    8. B. Balis, M. Bubak, M. Pelczar, J. Wach; Provenance Tracking and Querying in ViroLab, in Cracow Grid Workshop 2007 Workshop Proceedings, pp.71-76, ACC CYFRONET AGH 2008
    9. B. Balis, M. Bubak, J. Wach; User-Oriented Querying over Repositories of Data and Provenance. In G. Fox, K. Chiu, R. Buyya (Eds.), Third IEEE International Conference on e-Science and Grid Computing, e-Science 2007, Bangalore, India, pp. 77-84. IEEE Computer Society, 2007.
    10. B. Balis, M. Bubak, M. Pelczar; From Monitoring Data to Experiment Information -- Monitoring of Grid Scientific Workflows. In G. Fox, K. Chiu, R. Buyya (Eds.), Third IEEE International Conference on e-Science and Grid Computing, e-Science 2007, Bangalore, India, pp. 187-194. IEEE Computer Society, 2007.
    11. M. Malawski, T. Bartynski, M. Bubak; A Tool for Building Collaborative Applications by Invocation of Grid Operations. In: M. Bubak, G.D.v. Albada, J. Dongarra, P.M.A. Sloot (Eds.), Proceedings ICCS 2008, Kraków, Poland, LNCS 5103, pp. 243-252, Springer 2008
    12. W. Funika, D. Harezlak, D. Krol, M. Bubak; Environment for Collaborative Development and Execution of Virtual Laboratory Applications. In: M. Bubak, G.D.v. Albada, J. Dongarra, P.M.A. Sloot (Eds.), Proceedings ICCS 2008, Kraków, Poland, LNCS 5103, pp. 246-458, Springer 2008
    13. B. Kowalewski, M. Bubak, B. Balis; An Event-Based Approach to Reducing Coupling in Large-Scale Applications. In: M. Bubak, G.D.v. Albada, J. Dongarra, P.M.A. Sloot (Eds.), Proceedings ICCS 2008, Kraków, Poland, LNCS 5103, pp. 358-367, Springer 2008
    14. B. Balis, M. Bubak, M. Pelczar, J. Wach; Provenance Querying for End-Users: A Drug Resistance Case Study. In: M. Bubak, G.D.v. Albada, J. Dongarra, P.M.A. Sloot (Eds.), Proceedings ICCS 2008, Kraków, Poland, LNCS 5103, pp. 80-89, Springer 2008
    15. M. Assel, P. Nowakowski, Marian Bubak; Integrating and Accessing Medical Data Resources within the ViroLab Virtual Laboratory. In: M. Bubak, G.D.v. Albada, J. Dongarra, P.M.A. Sloot (Eds.), Proceedings ICCS 2008, Kraków, Poland, LNCS 5103, pp. 90-99, Springer 2008
    16. B. Balis, M. Bubak, M. Wegiel; LGF: A flexible framework for exposing legacy codes as services, Future Generation Computer Systems, Volume 24, Issue 7, July 2008, Elsevier, pp. 711-719
    17. B. Balis, M. Bubak, M. Pelczar, J. Wach; Provenance Tracking and Querying in the ViroLab Virtual Laboratory in Proceedings of the 8th IEEE International Symposium on Cluster Computing and the Grid 2008 (CCGRID), pp. 675-680, IEEE Computer Society 2008.
    18. B. Balis, M. Bubak: Monitoring infrastructure for Grid scientific workflows in 3rd Workshop on Workflows in Support of Large-Scale Science during SuperComputing 08 The International Conference for High Performance Computing, Networking, Storage and Analysis, November 2008 Austin, Texas, IEEE 2008
    19. B. Balis, M. Bubak: An ontology model for execution records of Grid scientific applications in 4th International Conference on Semantics, Knowledge and Grid SKG 2008, December 2008, Beijing, China, pp. 34-41, IEEE 2008, ISBN 978-0-7695-3401-5
    20. T. Gubala, M. Bubak, P.M.A. Sloot; Semantic Integration of Collaborative Research Environments, In: M. Cannataro (Ed.) Handbook of Research on Computational Grid Technologies for Life Sciences, Biomedicine and Healthcare, Chapter 26, pp. 514-530, Information Science Reference, 2009, IGI Global
    21. B. Balis, M. Bubak, M. Pelczar, J. Wach; Provenance Tracking and End-User Oriented Query Construction, In: M. Cannataro (Ed.) Handbook of Research on Computational Grid Technologies for Life Sciences, Biomedicine and Healthcare, Chapter 4, pp. 60-75, Information Science Reference, 2009, IGI Global
    22. Michal Dyrda, Maciej Malawski, Marian Bubak, Syed Naqvi, "Providing security for MOCCA component environment," Parallel and Distributed Processing Symposium, International, pp. 1-7, 2009 IEEE International Symposium on Parallel&Distributed Processing, 2009.http://doi.ieeecomputersociety.org/10.1109/IPDPS.2009.5161082
    23. M. Malawski, T. Bartynski, and M. Bubak, "Invocation of operations from script-based grid applications," Future Generation Computer Systems, Volume 26, Issue 1, January 2010, Pages 138-146. Available: http://dx.doi.org/10.1016/j.future.2009.05.012
    24. Jan Meizner, Maciej Malawski, Eryk Ciepiela, Marek Kasztelnik, Daniel Harezlak, Piotr Nowakowski, Dariusz Krol, Tomasz Gubała, Włodzimierz Funika, Marian Bubak, Tomasz Mikołajczyk, Paweł Płaszczak, Krzysztof Wilk, and Matthias Assel: "ViroLab Security and Virtual Organization Infrastructure" in: Y. Dou, R. Gruber, and J. Joller (Eds.): APPT 2009, Advanced Parallel Processing Technologies 8th International Symposium, APPT 2009, Rapperswil, Switzerland, August 24-25, 2009 Proceedings, LNCS 5737, pp. 230–245, Springer-Verlag Berlin Heidelberg 2009
    25. Eryk Ciepiela, Maciej Malawski and Marian Bubak: CompTalks Meta-Model and Framework for Application-Level Interaction Protocols, 2nd International Workshop on Real Time Online Interactive Applications on the Grid (ROIA 2009) in conjunction with Euro-Par 2009, to be published in Lecture Notes in Computer Science, Springer, 2009
    26. Wlodzimierz Funika, Dennis Caromel, Pawel Koperek and M. Kupisz. Towards semantic-based monitoring of ProActive distributed applications. Accepted for CoreGRID 2009 Workshop in conjunction with EuroPar 2009, August 24, 2009, Delft, Netherlands

Master of Science Theses related to ViroLab

  1. Optimization of Grid Application Execution, Joanna Kocot, Iwona Ryszka; Master of Science Thesis supervised by Marian Bubak; reviewed by dr Katarzyna Rycerz; AGH University of Science and Technology, June 2007, Krakow, Poland; (presentation)
  2. Monitoring of Component-Based Applications, Eryk Ciepiela; Master of Science Thesis supervised by Marian Bubak; reviewed by dr Dominik Radziszowski; AGH University of Science and Technology, June 2007, Krakow, Poland; (presentation)
  3. Remote execution of delegated operations with support for automatic selection among multiple communication protocols, Tomasz Bartyński; Master of Science Thesis supervised by Marian Bubak; reviewed by dr Dawid Kurzyniec; AGH University of Science and Technology, February 2008, Krakow, Poland;(presentation)
  4. Security in Component Grid Systems, Michal Dyrda; Master of Science Thesis supervised by Marian Bubak; reviewed by dr Dawid Kurzyniec; AGH University of Science and Technology, June 2008, Krakow, Poland; (presentation)
  5. Collection and Storage of Provenance Data, Jakub Wach; Master of Science Thesis supervised by Marian Bubak; reviewed by dr Dawid Kurzyniec, AGH University of Science and Technology, July 2008, Krakow, Poland; (presentation)
  6. Recording application executions enriched with domain semantics of computations and data, Michal Pelczar, Master of Science Thesis supervised by Marian Bubak; reviewed by dr Maciej Zygmunt; AGH University of Science and Technology, October 2008, Krakow, Poland; (presentation)
  7. Bioinformatics Applications in the Virtual Laboratory, Tomasz Jadczyk, Master of Science Thesis supervised by Marian Bubak; reviewed by prof. Irena Roterman and dr Monika Piwowar; AGH University of Science and Technology, September 2009, Krakow, Poland; (presentation)
  8. Optimization of application execution in virtual laboratory, Mikołaj Baranowski, Master of Science Thesis supervised by Marian Bubak; AGH University of Science and Technology, September 2009, Krakow, Poland;
  9. Environment for management of experiments on the grid, Paweł Charkowski, Master of Science Thesis supervised by Marian Bubak; reviewed by dr Mariusz Sterzel; AGH University of Science and Technology, September 2009, Krakow, Poland; (presentation)
  10. Security in Virtual Laboratory System, Jan Meizner, Master of Science Thesis supervised by Marian Bubak; reviewed by dr Dawid Kurzyniec; AGH University of Science and Technology, September 2009, Krakow, Poland; (presentation)
  11. Data source registration in the Virtual Laboratory, Marek Pomocka, Master of Science Thesis supervised by Marian Bubak; reviewed by dr Piotr Gronek; AGH University of Science and Technology, October 2009, Krakow, Poland;

Virtual Laboratory leaflets and posters

  1. The ViroLab Virtual Laboratory leaflet (June 2008)
  2. Development and Execution of Collaborative Applications poster (June 2008)
  3. The Developer and User Interfaces to the ViroLab Virtual Laboratory poster (June 2008)
  4. GridSpace Engine poster (June 2008)
  5. Invocation of Grid Operations in the ViroLab Virtual Laboratory poster (June 2008)
  6. Optimization of Application Execution in the ViroLab Virtual Laboratory poster (June 2008)
  7. Provenance Tracking and End-User Oriented Query Construction poster (June 2008)
  8. ViroLab Virtual Laboratory presentation made for the Grid computing course at UvA (July 2008)
  9. ViroLab Data Access Services poster (October 2008)
  10. Bioinformatics Applications in the Virtual Laboratory poster (October 2009)

Virtual Laboratory movies

  1. Virus analysis
  2. Executing protein folding experiment using Experiment Management Interface

Old

  1. Virus analysis
  2. Executing echo experiment from the command line
  3. Executing protein folding experiment from the command line
  4. Executing protein folding experiment using Experiment Management Interface
  5. Adding new Grid Object, implementations and instances
  6. Interaction between end user and the developer
  7. Releasing a new experiment

Virtual Laboratory tutorials

  1. Environment for Collaborative e-Science Applications: CGW08 Tutorial

Related webpages

  1. Official ViroLab webpage: http://www.virolab.org/

Related past presentations

  1. ViroLab Virtual Laboratory for Infectious Diseases: Case Study, presented at EGEE Industry Day in Bratislava, September 2007
  2. ViroLab Virtual Laboratory presented at Cracow Grid Workshop, October 2007
  3. Web 2.0: Technology and Possibilities, presented at Cracow Grid Seminar, November 2007
  4. Web Approach to Scientific Experiments, presented at EGEE Computational Chemistry Workshop in Paris, December 2007
  5. Provenance Tracking and Querying in the ViroLab Virtual Laboratory presented at CCGrid'2008 May 19-22, 2008, Lyon, France
  6. Collective Semantics workshop at ESWC 2008: June 01-05, 2008, Tenerife, Spain, presented poster about Semantically enhanced webspace for scientific collaboration
  7. Virtual Laboratory for Development and Execution of Biomedical Collaborative Applications presented at Computer-Based Medical Systems conference (CBMS'2008) in Jyväskylä, Finland, June 2008
  8. International Conference on Computational Science (ICCS'2008): June 23-25, 2008, Kraków, Poland
  9. Building collaborative applications for system-level science presented at High Performance Computing and GRIDS (HPC Cetraro): June 30 - July 4, 2008, Cetraro, Italy
  10. GridSpace in Virtual Laboratory Talk given by Maciej Malawski at University of Innsbruck, June 27, 2008.
  11. Marian's presentation at Workshop Abstractions for Distributed Systems, EuroPar 2008, 26-29 August, Las Palmas de Gran Canaria, 2008
  12. Talk given by Piotr Nowakowski at the University of Amsterdam, September 26, 2008.
  13. Environment for Collaborative e-Science Applications hands-on tutorial at the Cracow Grid Workshop 2008, Oct 13-15, 2008, Krakow, Poland
  14. Computer Modelling and Simulation for Improving Human Health - a demonstration about the ViroLab Virtual Laboratory at the ICT-BIO 2008 event, Brussels, Belgium, 23-24.10.2008
  15. Small demonstration stand about Virtual Laboratory and its applications during the CYFRONET Open Days, Krakow, Poland, 27.10.2008
  16. An Ontology Model for Execution Records of Grid Scientific Applications presented at the [SKG 2008 Conference], Beijing, China, 3-5.12.
  17. Demo team was present at 2nd Conference of the High Performance Computers' Users, 12-13 March 2009, Zakopane, Poland
  18. Keynote entitled Environments for Collaborative Applications: An Answer to Computational Science Challenges?, given at ICCS 2009, Baton Rouge, Louisiana, U.S.A., May 25-27, 2009
  19. Marian Bubak was present and was distributing hand-outs during Information Day on Objective 1.2 "Internet of Services, Software and Virtualisation", 8-10 June 2009, Brussels, Belgium
  20. A live demonstration stand at Int. Symposium on High Performance Distributed Computing 2009, 11-13 June 2009, Munich, Germany
  21. Marian Bubak was present and was distributing hand-outs during Information Event on the 7th Call for proposals under the e-Infrastructures Activity of the "Capacities" Specific Programme, 17-19 June 2009, Brussels, Belgium
  22. Cyfronet team representatives attended the 31st International Conference on Information Technology Interfaces, 22-25 June 2009, Dubrovnik, Croatia
  23. Presentation of the work titled A Collaborative Environment Allowing Clinical Investigations on Integrated Biomedical Databases was given at the HealthGrid 2009 Conference, June 28 - July 1 2009, Berlin, Germany
  24. Presentation given by Maciej Malawski and Tomasz Bartynski at University College London, July 2009 GridSpace as a Platform for ViroLab Virtual Laboratory
  25. Presentation given by Maciej Malawski at University of Amsterdam, November 2009 GridSpace - Environment for Programming and Running Complex Applications on the Grid

Events where we'll be present

  1. A presentation titled ViroLab Security and Virtual Organization Infrastructure will be given at the 8th international Conference on Advanced Parallel Processing Technologies, 24-25 August 2009, Rapperswil, Switzerland
  2. Representatives of the team will be present at Euro-Par 2009 Conference 25-28 August, Delft, The Netherlands

The Team

Contact:

  1. For the Virtual Laboratory development team, please make sure to send a message both to:
    1. Tomasz Gubała, gubala (AT) science (DOT) uva (DOT) nl
    2. Maciej Malawski, malawski (AT) agh (DOT) edu (DOT) pl
  2. For authors of this web pages: Tomasz Gubała, gubala (AT) science (DOT) uva (DOT) nl
  3. For administrator of this website: Daniel Harężlak, d.harezlak (AT) cyfronet (DOT) pl

Below is a long list (in alphabetical order) of current and past developers and contributors of the ViroLab Virtual Laboratory. Herewith the authors of this manual would like to thank all those (mentioned or not mentioned due to the erroneous human memory) who have invested effort and took part in the design and the realization of this software.

Designers and developers (ACC CYFRONET AGH, Krakow):

Bartosz Baliś Tomasz Bartyński Marian Bubak Eryk Ciepela
Michał Dyrda Włodzimierz Funika Krzysztof Goj Tomasz Gubała
Daniel Harężlak Tomasz Jadczyk Marek Kasztelnik Joanna Kocot
Paweł Koperek Dariusz Król Bartosz Łabno Maciej Malawski
Jan Meizner Piotr Nowakowski Michał Pelczar Piotr Pęgiel
Iwona Ryszka Tomasz Szymczyszyn Jakub Wach

Designers and developers (HLRS, Stuttgart):

Matthias Assel Tao Jiang Bettina Krammer Aenne Loehden
Stefan Wesner

Designers and developers (Gridwise Tech., Krakow):

Paweł Jarosz Stanisław Kulczycki Tomasz Mikołajczyk Paweł Płaszczak
Kuba Rozkwitalski Krzysztof Wilk

Designers and developers (UvA, Amsterdam):

Bui Quoc Chinh Derek Groen Breanndán Ó Nualláin Kaustubh Patil
Peter Sloot Alfredo Tirado

A large part of the software being described on those pages is developed as a part of (or is strongly based on) the GridSpace platform.

Acknowledgments:

This work has been made possible through the support of the European Commission Virolab Project Grant 027446

Organizations that perform the development of the described components of the virtual laboratory and the creation of this website:

Academic Computer Centre CYFRONET Akademii Górniczo-Hutniczej

Organizations that perform the development of other elements of the virtual laboratory and that also contributed information to that website:

High Performance Computing Center of the University of Stuttgart
GridwiseTech
Section Computational Science of the University of Amsterdam

Organizations that we cooperate with in the ViroLab Project and that influence the development of the laboratory:

Rega Institute for Medical Research, Katholieke Universiteit Leuven, Belgium
Universitair Medisch Centrum Utrecht, The Netherlands
Centre for Computational Science, University College London, United Kingdom
Universita Cattolica del Sacro Cuore, Rome, Italy
Fundacio irsiCaixa, Hospital Universitari Germans Trias i Pujol, Badalona, Spain
Università degli Studi di Brescia, Italy
Eötvös Loránd University, Budapest, Hungary
Virology Education, Utrecht, the Netherlands