Serveur d'exploration sur le cobalt au Maghreb

Attention, ce site est en cours de développement !
Attention, site généré par des moyens informatiques à partir de corpus bruts.
Les informations ne sont donc pas validées.

Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry

Identifieur interne : 000103 ( Pmc/Corpus ); précédent : 000102; suivant : 000104

Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry

Auteurs : Junaid Arshad ; Alexander Hoffmann ; Sandra Gesing ; Richard Grunzke ; Jens Krüger ; Tamas Kiss ; Sonja Herres-Pawlis ; Gabor Terstyanszky

Source :

RBID : PMC:5073744

Abstract

Background

In Quantum Chemistry, many tasks are reoccurring frequently, e.g. geometry optimizations, benchmarking series etc. Here, workflows can help to reduce the time of manual job definition and output extraction. These workflows are executed on computing infrastructures and may require large computing and data resources. Scientific workflows hide these infrastructures and the resources needed to run them. It requires significant efforts and specific expertise to design, implement and test these workflows.

Significance

Many of these workflows are complex and monolithic entities that can be used for particular scientific experiments. Hence, their modification is not straightforward and it makes almost impossible to share them. To address these issues we propose developing atomic workflows and embedding them in meta-workflows. Atomic workflows deliver a well-defined research domain specific function. Publishing workflows in repositories enables workflow sharing inside and/or among scientific communities. We formally specify atomic and meta-workflows in order to define data structures to be used in repositories for uploading and sharing them. Additionally, we present a formal description focused at orchestration of atomic workflows into meta-workflows.

Conclusions

We investigated the operations that represent basic functionalities in Quantum Chemistry, developed the relevant atomic workflows and combined them into meta-workflows. Having these workflows we defined the structure of the Quantum Chemistry workflow library and uploaded these workflows in the SHIWA Workflow Repository.

Meta-workflows and embedded workflows in the template representation

Electronic supplementary material

The online version of this article (doi:10.1186/s13321-016-0169-8) contains supplementary material, which is available to authorized users.


Url:
DOI: 10.1186/s13321-016-0169-8
PubMed: 27818709
PubMed Central: 5073744

Links to Exploration step

PMC:5073744

Le document en format XML

<record>
<TEI>
<teiHeader>
<fileDesc>
<titleStmt>
<title xml:lang="en">Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry</title>
<author>
<name sortKey="Arshad, Junaid" sort="Arshad, Junaid" uniqKey="Arshad J" first="Junaid" last="Arshad">Junaid Arshad</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Hoffmann, Alexander" sort="Hoffmann, Alexander" uniqKey="Hoffmann A" first="Alexander" last="Hoffmann">Alexander Hoffmann</name>
<affiliation>
<nlm:aff id="Aff2">Institut für Anorganische Chemie, Lehrstuhl für Bioanorganische Chemie, RWTH Aachen University, Landoltweg 1, 52074 Aachen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Gesing, Sandra" sort="Gesing, Sandra" uniqKey="Gesing S" first="Sandra" last="Gesing">Sandra Gesing</name>
<affiliation>
<nlm:aff id="Aff3">University of Notre Dame, 123 Information Technology Center, Notre Dame, IN 46556 USA</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Grunzke, Richard" sort="Grunzke, Richard" uniqKey="Grunzke R" first="Richard" last="Grunzke">Richard Grunzke</name>
<affiliation>
<nlm:aff id="Aff4">Center for Information Services and High Performance Computing, Technische Universität Dresden, Zellescher Weg 12-14, 01062 Dresden, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Kruger, Jens" sort="Kruger, Jens" uniqKey="Kruger J" first="Jens" last="Krüger">Jens Krüger</name>
<affiliation>
<nlm:aff id="Aff5">Applied Bioinformatics Tübingen, University of Tübingen, Sand 14, 72076 Tübingen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Kiss, Tamas" sort="Kiss, Tamas" uniqKey="Kiss T" first="Tamas" last="Kiss">Tamas Kiss</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Herres Pawlis, Sonja" sort="Herres Pawlis, Sonja" uniqKey="Herres Pawlis S" first="Sonja" last="Herres-Pawlis">Sonja Herres-Pawlis</name>
<affiliation>
<nlm:aff id="Aff2">Institut für Anorganische Chemie, Lehrstuhl für Bioanorganische Chemie, RWTH Aachen University, Landoltweg 1, 52074 Aachen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Terstyanszky, Gabor" sort="Terstyanszky, Gabor" uniqKey="Terstyanszky G" first="Gabor" last="Terstyanszky">Gabor Terstyanszky</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
</titleStmt>
<publicationStmt>
<idno type="wicri:source">PMC</idno>
<idno type="pmid">27818709</idno>
<idno type="pmc">5073744</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC5073744</idno>
<idno type="RBID">PMC:5073744</idno>
<idno type="doi">10.1186/s13321-016-0169-8</idno>
<date when="2016">2016</date>
<idno type="wicri:Area/Pmc/Corpus">000103</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000103</idno>
</publicationStmt>
<sourceDesc>
<biblStruct>
<analytic>
<title xml:lang="en" level="a" type="main">Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry</title>
<author>
<name sortKey="Arshad, Junaid" sort="Arshad, Junaid" uniqKey="Arshad J" first="Junaid" last="Arshad">Junaid Arshad</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Hoffmann, Alexander" sort="Hoffmann, Alexander" uniqKey="Hoffmann A" first="Alexander" last="Hoffmann">Alexander Hoffmann</name>
<affiliation>
<nlm:aff id="Aff2">Institut für Anorganische Chemie, Lehrstuhl für Bioanorganische Chemie, RWTH Aachen University, Landoltweg 1, 52074 Aachen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Gesing, Sandra" sort="Gesing, Sandra" uniqKey="Gesing S" first="Sandra" last="Gesing">Sandra Gesing</name>
<affiliation>
<nlm:aff id="Aff3">University of Notre Dame, 123 Information Technology Center, Notre Dame, IN 46556 USA</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Grunzke, Richard" sort="Grunzke, Richard" uniqKey="Grunzke R" first="Richard" last="Grunzke">Richard Grunzke</name>
<affiliation>
<nlm:aff id="Aff4">Center for Information Services and High Performance Computing, Technische Universität Dresden, Zellescher Weg 12-14, 01062 Dresden, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Kruger, Jens" sort="Kruger, Jens" uniqKey="Kruger J" first="Jens" last="Krüger">Jens Krüger</name>
<affiliation>
<nlm:aff id="Aff5">Applied Bioinformatics Tübingen, University of Tübingen, Sand 14, 72076 Tübingen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Kiss, Tamas" sort="Kiss, Tamas" uniqKey="Kiss T" first="Tamas" last="Kiss">Tamas Kiss</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Herres Pawlis, Sonja" sort="Herres Pawlis, Sonja" uniqKey="Herres Pawlis S" first="Sonja" last="Herres-Pawlis">Sonja Herres-Pawlis</name>
<affiliation>
<nlm:aff id="Aff2">Institut für Anorganische Chemie, Lehrstuhl für Bioanorganische Chemie, RWTH Aachen University, Landoltweg 1, 52074 Aachen, Germany</nlm:aff>
</affiliation>
</author>
<author>
<name sortKey="Terstyanszky, Gabor" sort="Terstyanszky, Gabor" uniqKey="Terstyanszky G" first="Gabor" last="Terstyanszky">Gabor Terstyanszky</name>
<affiliation>
<nlm:aff id="Aff1">Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</nlm:aff>
</affiliation>
</author>
</analytic>
<series>
<title level="j">Journal of Cheminformatics</title>
<idno type="eISSN">1758-2946</idno>
<imprint>
<date when="2016">2016</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc>
<textClass></textClass>
</profileDesc>
</teiHeader>
<front>
<div type="abstract" xml:lang="en">
<sec>
<title>Background</title>
<p>In Quantum Chemistry, many tasks are reoccurring frequently, e.g. geometry optimizations, benchmarking series etc. Here, workflows can help to reduce the time of manual job definition and output extraction. These workflows are executed on computing infrastructures and may require large computing and data resources. Scientific workflows hide these infrastructures and the resources needed to run them. It requires significant efforts and specific expertise to design, implement and test these workflows.</p>
</sec>
<sec>
<title>Significance</title>
<p>Many of these workflows are complex and monolithic entities that can be used for particular scientific experiments. Hence, their modification is not straightforward and it makes almost impossible to share them. To address these issues we propose developing atomic workflows and embedding them in meta-workflows. Atomic workflows deliver a well-defined research domain specific function. Publishing workflows in repositories enables workflow sharing inside and/or among scientific communities. We formally specify atomic and meta-workflows in order to define data structures to be used in repositories for uploading and sharing them. Additionally, we present a formal description focused at orchestration of atomic workflows into meta-workflows.</p>
</sec>
<sec>
<title>Conclusions</title>
<p>We investigated the operations that represent basic functionalities in Quantum Chemistry, developed the relevant atomic workflows and combined them into meta-workflows. Having these workflows we defined the structure of the Quantum Chemistry workflow library and uploaded these workflows in the SHIWA Workflow Repository.
<fig position="anchor" id="Figa">
<label>Graphical Abstract</label>
<caption>
<p>Meta-workflows and embedded workflows in the template representation</p>
</caption>
<graphic position="anchor" xlink:href="13321_2016_169_Figa_HTML" id="MO1"></graphic>
</fig>
</p>
</sec>
<sec>
<title>Electronic supplementary material</title>
<p>The online version of this article (doi:10.1186/s13321-016-0169-8) contains supplementary material, which is available to authorized users.</p>
</sec>
</div>
</front>
<back>
<div1 type="bibliography">
<listBibl>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Castelli, G" uniqKey="Castelli G">G Castelli</name>
</author>
<author>
<name sortKey="Taffoni, G" uniqKey="Taffoni G">G Taffoni</name>
</author>
<author>
<name sortKey="Sciacca, E" uniqKey="Sciacca E">E Sciacca</name>
</author>
<author>
<name sortKey="Becciani, U" uniqKey="Becciani U">U Becciani</name>
</author>
<author>
<name sortKey="Costa, A" uniqKey="Costa A">A Costa</name>
</author>
<author>
<name sortKey="Krokos, M" uniqKey="Krokos M">M Krokos</name>
</author>
<author>
<name sortKey="Pasian, F" uniqKey="Pasian F">F Pasian</name>
</author>
<author>
<name sortKey="Vuerli, C" uniqKey="Vuerli C">C Vuerli</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Korkhov, V" uniqKey="Korkhov V">V Korkhov</name>
</author>
<author>
<name sortKey="Krefting, D" uniqKey="Krefting D">D Krefting</name>
</author>
<author>
<name sortKey="Motagnat, J" uniqKey="Motagnat J">J Motagnat</name>
</author>
<author>
<name sortKey="Olabarriaga, Sd" uniqKey="Olabarriaga S">SD Olabarriaga</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Kacsuk, P" uniqKey="Kacsuk P">P Kacsuk</name>
</author>
<author>
<name sortKey="Terstyanszky, G" uniqKey="Terstyanszky G">G Terstyanszky</name>
</author>
<author>
<name sortKey="Balasko, A" uniqKey="Balasko A">A Balasko</name>
</author>
<author>
<name sortKey="Karoczkai, K" uniqKey="Karoczkai K">K Karoczkai</name>
</author>
<author>
<name sortKey="Farkas, Z" uniqKey="Farkas Z">Z Farkas</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Taylor, Ij" uniqKey="Taylor I">IJ Taylor</name>
</author>
<author>
<name sortKey="Deelman, E" uniqKey="Deelman E">E Deelman</name>
</author>
<author>
<name sortKey="Gannon, Db" uniqKey="Gannon D">DB Gannon</name>
</author>
<author>
<name sortKey="Sheilds, M" uniqKey="Sheilds M">M Sheilds</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Abouelhoda, M" uniqKey="Abouelhoda M">M Abouelhoda</name>
</author>
<author>
<name sortKey="Issa, Sa" uniqKey="Issa S">SA Issa</name>
</author>
<author>
<name sortKey="Ghanem, M" uniqKey="Ghanem M">M Ghanem</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Garijo, D" uniqKey="Garijo D">D Garijo</name>
</author>
<author>
<name sortKey="Alper, P" uniqKey="Alper P">P Alper</name>
</author>
<author>
<name sortKey="Belhajjame, K" uniqKey="Belhajjame K">K Belhajjame</name>
</author>
<author>
<name sortKey="Corcho, O" uniqKey="Corcho O">O Corcho</name>
</author>
<author>
<name sortKey="Gil, Y" uniqKey="Gil Y">Y Gil</name>
</author>
<author>
<name sortKey="Goble, C" uniqKey="Goble C">C Goble</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="De Roure, D" uniqKey="De Roure D">D De Roure</name>
</author>
<author>
<name sortKey="Goble, C" uniqKey="Goble C">C Goble</name>
</author>
<author>
<name sortKey="Stevens, R" uniqKey="Stevens R">R Stevens</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Hildebrandt, Ak" uniqKey="Hildebrandt A">AK Hildebrandt</name>
</author>
<author>
<name sortKey="Stockel, D" uniqKey="Stockel D">D Stöckel</name>
</author>
<author>
<name sortKey="Fischer, Nm" uniqKey="Fischer N">NM Fischer</name>
</author>
<author>
<name sortKey="De La Garza, L" uniqKey="De La Garza L">L de la Garza</name>
</author>
<author>
<name sortKey="Kruger, J" uniqKey="Kruger J">J Krüger</name>
</author>
<author>
<name sortKey="Nickels, S" uniqKey="Nickels S">S Nickels</name>
</author>
<author>
<name sortKey="Rottig, M" uniqKey="Rottig M">M Röttig</name>
</author>
<author>
<name sortKey="Sch Rfe, C" uniqKey="Sch Rfe C">C Schärfe</name>
</author>
<author>
<name sortKey="Schumann, M" uniqKey="Schumann M">M Schumann</name>
</author>
<author>
<name sortKey="Thiel, P" uniqKey="Thiel P">P Thiel</name>
</author>
<author>
<name sortKey="Lenhof, Hp" uniqKey="Lenhof H">HP Lenhof</name>
</author>
<author>
<name sortKey="Kohlbacher, O" uniqKey="Kohlbacher O">O Kohlbacher</name>
</author>
<author>
<name sortKey="Hildebrandt, A" uniqKey="Hildebrandt A">A Hildebrandt</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Niehorster, O" uniqKey="Niehorster O">O Niehörster</name>
</author>
<author>
<name sortKey="Brinkmann, A" uniqKey="Brinkmann A">A Brinkmann</name>
</author>
<author>
<name sortKey="Keller, A" uniqKey="Keller A">A Keller</name>
</author>
<author>
<name sortKey="Kleineweber, C" uniqKey="Kleineweber C">C Kleineweber</name>
</author>
<author>
<name sortKey="Kruger, J" uniqKey="Kruger J">J Krüger</name>
</author>
<author>
<name sortKey="Simon, J" uniqKey="Simon J">J Simon</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Kruger, J" uniqKey="Kruger J">J Krüger</name>
</author>
<author>
<name sortKey="Grunzke, R" uniqKey="Grunzke R">R Grunzke</name>
</author>
<author>
<name sortKey="Gesing, S" uniqKey="Gesing S">S Gesing</name>
</author>
<author>
<name sortKey="Breuers, S" uniqKey="Breuers S">S Breuers</name>
</author>
<author>
<name sortKey="Brinkmann, A" uniqKey="Brinkmann A">A Brinkmann</name>
</author>
<author>
<name sortKey="De La Garza, L" uniqKey="De La Garza L">L de la Garza</name>
</author>
<author>
<name sortKey="Kohlbacher, O" uniqKey="Kohlbacher O">O Kohlbacher</name>
</author>
<author>
<name sortKey="Kruse, M" uniqKey="Kruse M">M Kruse</name>
</author>
<author>
<name sortKey="Nagel, We" uniqKey="Nagel W">WE Nagel</name>
</author>
<author>
<name sortKey="Packschies, L" uniqKey="Packschies L">L Packschies</name>
</author>
<author>
<name sortKey="Muller Pfefferkorn, R" uniqKey="Muller Pfefferkorn R">R Müller-Pfefferkorn</name>
</author>
<author>
<name sortKey="Sch Fer, P" uniqKey="Sch Fer P">P Schäfer</name>
</author>
<author>
<name sortKey="Sch Rfe, C" uniqKey="Sch Rfe C">C Schärfe</name>
</author>
<author>
<name sortKey="Steinke, T" uniqKey="Steinke T">T Steinke</name>
</author>
<author>
<name sortKey="Schlemmer, T" uniqKey="Schlemmer T">T Schlemmer</name>
</author>
<author>
<name sortKey="Warzecha, K" uniqKey="Warzecha K">K Warzecha</name>
</author>
<author>
<name sortKey="Zink, A" uniqKey="Zink A">A Zink</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Kertesz, A" uniqKey="Kertesz A">A Kertész</name>
</author>
<author>
<name sortKey="Sipos, G" uniqKey="Sipos G">G Sipos</name>
</author>
<author>
<name sortKey="Kacsuk, P" uniqKey="Kacsuk P">P Kacsuk</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Atkinson, M" uniqKey="Atkinson M">M Atkinson</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Blankenberg, D" uniqKey="Blankenberg D">D Blankenberg</name>
</author>
<author>
<name sortKey="Kuster, Gv" uniqKey="Kuster G">GV Kuster</name>
</author>
<author>
<name sortKey="Coraor, N" uniqKey="Coraor N">N Coraor</name>
</author>
<author>
<name sortKey="Ananda, G" uniqKey="Ananda G">G Ananda</name>
</author>
<author>
<name sortKey="Lazarus, R" uniqKey="Lazarus R">R Lazarus</name>
</author>
<author>
<name sortKey="Mangan, M" uniqKey="Mangan M">M Mangan</name>
</author>
<author>
<name sortKey="Nekrutenko, A" uniqKey="Nekrutenko A">A Nekrutenko</name>
</author>
<author>
<name sortKey="Taylor, J" uniqKey="Taylor J">J Taylor</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Lud Scher, B" uniqKey="Lud Scher B">B Ludäscher</name>
</author>
<author>
<name sortKey="Altintas, I" uniqKey="Altintas I">I Altintas</name>
</author>
<author>
<name sortKey="Berkley, C" uniqKey="Berkley C">C Berkley</name>
</author>
<author>
<name sortKey="Higgins, D" uniqKey="Higgins D">D Higgins</name>
</author>
<author>
<name sortKey="Jaeger, E" uniqKey="Jaeger E">E Jaeger</name>
</author>
<author>
<name sortKey="Jones, M" uniqKey="Jones M">M Jones</name>
</author>
<author>
<name sortKey="Lee, Ea" uniqKey="Lee E">EA Lee</name>
</author>
<author>
<name sortKey="Tao, J" uniqKey="Tao J">J Tao</name>
</author>
<author>
<name sortKey="Zhao, Y" uniqKey="Zhao Y">Y Zhao</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Beisken, S" uniqKey="Beisken S">S Beisken</name>
</author>
<author>
<name sortKey="Meinl, T" uniqKey="Meinl T">T Meinl</name>
</author>
<author>
<name sortKey="Wiswedel, B" uniqKey="Wiswedel B">B Wiswedel</name>
</author>
<author>
<name sortKey="De Figueiredo, L" uniqKey="De Figueiredo L">L de Figueiredo</name>
</author>
<author>
<name sortKey="Berthold, M" uniqKey="Berthold M">M Berthold</name>
</author>
<author>
<name sortKey="Steinbeck, C" uniqKey="Steinbeck C">C Steinbeck</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Deelman, E" uniqKey="Deelman E">E Deelman</name>
</author>
<author>
<name sortKey="Vahi, K" uniqKey="Vahi K">K Vahi</name>
</author>
<author>
<name sortKey="Juve, G" uniqKey="Juve G">G Juve</name>
</author>
<author>
<name sortKey="Rynge, M" uniqKey="Rynge M">M Rynge</name>
</author>
<author>
<name sortKey="Callaghan, S" uniqKey="Callaghan S">S Callaghan</name>
</author>
<author>
<name sortKey="Maechling, Pj" uniqKey="Maechling P">PJ Maechling</name>
</author>
<author>
<name sortKey="Mayani, R" uniqKey="Mayani R">R Mayani</name>
</author>
<author>
<name sortKey="Chen, W" uniqKey="Chen W">W Chen</name>
</author>
<author>
<name sortKey="Da Silva, Rf" uniqKey="Da Silva R">RF da Silva</name>
</author>
<author>
<name sortKey="Livny, M" uniqKey="Livny M">M Livny</name>
</author>
<author>
<name sortKey="Wenger, K" uniqKey="Wenger K">K Wenger</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Kacsuk, P" uniqKey="Kacsuk P">P Kacsuk</name>
</author>
<author>
<name sortKey="Farkas, Z" uniqKey="Farkas Z">Z Farkas</name>
</author>
<author>
<name sortKey="Kozlovszky, M" uniqKey="Kozlovszky M">M Kozlovszky</name>
</author>
<author>
<name sortKey="Hermann, G" uniqKey="Hermann G">G Hermann</name>
</author>
<author>
<name sortKey="Balasko, A" uniqKey="Balasko A">A Balasko</name>
</author>
<author>
<name sortKey="Karoczkai, K" uniqKey="Karoczkai K">K Karoczkai</name>
</author>
<author>
<name sortKey="Marton, I" uniqKey="Marton I">I Marton</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Kiss, T" uniqKey="Kiss T">T Kiss</name>
</author>
<author>
<name sortKey="Greenwell, P" uniqKey="Greenwell P">P Greenwell</name>
</author>
<author>
<name sortKey="Heindl, H" uniqKey="Heindl H">H Heindl</name>
</author>
<author>
<name sortKey="Terstyanszky, G" uniqKey="Terstyanszky G">G Terstyanszky</name>
</author>
<author>
<name sortKey="Weingarten, N" uniqKey="Weingarten N">N Weingarten</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Morris, Gm" uniqKey="Morris G">GM Morris</name>
</author>
<author>
<name sortKey="Goodsell, Ds" uniqKey="Goodsell D">DS Goodsell</name>
</author>
<author>
<name sortKey="Halliday, Rs" uniqKey="Halliday R">RS Halliday</name>
</author>
<author>
<name sortKey="Huey, R" uniqKey="Huey R">R Huey</name>
</author>
<author>
<name sortKey="Hart, We" uniqKey="Hart W">WE Hart</name>
</author>
<author>
<name sortKey="Belew, Rk" uniqKey="Belew R">RK Belew</name>
</author>
<author>
<name sortKey="Olson, Aj" uniqKey="Olson A">AJ Olson</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Trott, O" uniqKey="Trott O">O Trott</name>
</author>
<author>
<name sortKey="Olson, Aj" uniqKey="Olson A">AJ Olson</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Jacob, Cr" uniqKey="Jacob C">CR Jacob</name>
</author>
<author>
<name sortKey="Beyhan, Sm" uniqKey="Beyhan S">SM Beyhan</name>
</author>
<author>
<name sortKey="Bulo, Re" uniqKey="Bulo R">RE Bulo</name>
</author>
<author>
<name sortKey="Pereira Gomes, As" uniqKey="Pereira Gomes A">AS Pereira Gomes</name>
</author>
<author>
<name sortKey="Gotz, Aw" uniqKey="Gotz A">AW Götz</name>
</author>
<author>
<name sortKey="Kiewisch, K" uniqKey="Kiewisch K">K Kiewisch</name>
</author>
<author>
<name sortKey="Sikkema, J" uniqKey="Sikkema J">J Sikkema</name>
</author>
<author>
<name sortKey="Visscher, L" uniqKey="Visscher L">L Visscher</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Waller, Mp" uniqKey="Waller M">MP Waller</name>
</author>
<author>
<name sortKey="Dresselhaus, T" uniqKey="Dresselhaus T">T Dresselhaus</name>
</author>
<author>
<name sortKey="Yang, J" uniqKey="Yang J">J Yang</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Terstyanszky, G" uniqKey="Terstyanszky G">G Terstyanszky</name>
</author>
<author>
<name sortKey="Kukla, T" uniqKey="Kukla T">T Kukla</name>
</author>
<author>
<name sortKey="Kiss, T" uniqKey="Kiss T">T Kiss</name>
</author>
<author>
<name sortKey="Kacsuk, P" uniqKey="Kacsuk P">P Kacsuk</name>
</author>
<author>
<name sortKey="Balasko, A" uniqKey="Balasko A">A Balasko</name>
</author>
<author>
<name sortKey="Farkas, Z" uniqKey="Farkas Z">Z Farkas</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Frisch, Mj" uniqKey="Frisch M">MJ Frisch</name>
</author>
<author>
<name sortKey="Trucks, Gw" uniqKey="Trucks G">GW Trucks</name>
</author>
<author>
<name sortKey="Schlegel, Hb" uniqKey="Schlegel H">HB Schlegel</name>
</author>
<author>
<name sortKey="Scuseria, Ge" uniqKey="Scuseria G">GE Scuseria</name>
</author>
<author>
<name sortKey="Robb, Ma" uniqKey="Robb M">MA Robb</name>
</author>
<author>
<name sortKey="Cheeseman, Jr" uniqKey="Cheeseman J">JR Cheeseman</name>
</author>
<author>
<name sortKey="Scalmani, G" uniqKey="Scalmani G">G Scalmani</name>
</author>
<author>
<name sortKey="Barone, V" uniqKey="Barone V">V Barone</name>
</author>
<author>
<name sortKey="Mennucci, B" uniqKey="Mennucci B">B Mennucci</name>
</author>
<author>
<name sortKey="Petersson, Ga" uniqKey="Petersson G">GA Petersson</name>
</author>
<author>
<name sortKey="Nakatsuji, H" uniqKey="Nakatsuji H">H Nakatsuji</name>
</author>
<author>
<name sortKey="Caricato, M" uniqKey="Caricato M">M Caricato</name>
</author>
<author>
<name sortKey="Li, X" uniqKey="Li X">X Li</name>
</author>
<author>
<name sortKey="Hratchian, Hp" uniqKey="Hratchian H">HP Hratchian</name>
</author>
<author>
<name sortKey="Izmaylov, Af" uniqKey="Izmaylov A">AF Izmaylov</name>
</author>
<author>
<name sortKey="Bloino, J" uniqKey="Bloino J">J Bloino</name>
</author>
<author>
<name sortKey="Zheng, G" uniqKey="Zheng G">G Zheng</name>
</author>
<author>
<name sortKey="Sonnenberg, Jl" uniqKey="Sonnenberg J">JL Sonnenberg</name>
</author>
<author>
<name sortKey="Hada, M" uniqKey="Hada M">M Hada</name>
</author>
<author>
<name sortKey="Ehara, M" uniqKey="Ehara M">M Ehara</name>
</author>
<author>
<name sortKey="Toyota, K" uniqKey="Toyota K">K Toyota</name>
</author>
<author>
<name sortKey="Fukuda, R" uniqKey="Fukuda R">R Fukuda</name>
</author>
<author>
<name sortKey="Hasegawa, J" uniqKey="Hasegawa J">J Hasegawa</name>
</author>
<author>
<name sortKey="Ishida, M" uniqKey="Ishida M">M Ishida</name>
</author>
<author>
<name sortKey="Nakajima, T" uniqKey="Nakajima T">T Nakajima</name>
</author>
<author>
<name sortKey="Honda, Y" uniqKey="Honda Y">Y Honda</name>
</author>
<author>
<name sortKey="Kitao, O" uniqKey="Kitao O">O Kitao</name>
</author>
<author>
<name sortKey="Nakai, H" uniqKey="Nakai H">H Nakai</name>
</author>
<author>
<name sortKey="Vreven, T" uniqKey="Vreven T">T Vreven</name>
</author>
<author>
<name sortKey="Montgomery, Ja" uniqKey="Montgomery J">JA Montgomery</name>
</author>
<author>
<name sortKey="Peralta, Je" uniqKey="Peralta J">JE Peralta</name>
</author>
<author>
<name sortKey="Ogliaro, F" uniqKey="Ogliaro F">F Ogliaro</name>
</author>
<author>
<name sortKey="Bearpark, M" uniqKey="Bearpark M">M Bearpark</name>
</author>
<author>
<name sortKey="Heyd, Jj" uniqKey="Heyd J">JJ Heyd</name>
</author>
<author>
<name sortKey="Brothers, E" uniqKey="Brothers E">E Brothers</name>
</author>
<author>
<name sortKey="Kudin, Kn" uniqKey="Kudin K">KN Kudin</name>
</author>
<author>
<name sortKey="Staroverov, Vn" uniqKey="Staroverov V">VN Staroverov</name>
</author>
<author>
<name sortKey="Kobayashi, R" uniqKey="Kobayashi R">R Kobayashi</name>
</author>
<author>
<name sortKey="Normand, J" uniqKey="Normand J">J Normand</name>
</author>
<author>
<name sortKey="Raghavachari, K" uniqKey="Raghavachari K">K Raghavachari</name>
</author>
<author>
<name sortKey="Rendell, A" uniqKey="Rendell A">A Rendell</name>
</author>
<author>
<name sortKey="Burant, Jc" uniqKey="Burant J">JC Burant</name>
</author>
<author>
<name sortKey="Iyengar, Ss" uniqKey="Iyengar S">SS Iyengar</name>
</author>
<author>
<name sortKey="Tomasi, J" uniqKey="Tomasi J">J Tomasi</name>
</author>
<author>
<name sortKey="Cossi, M" uniqKey="Cossi M">M Cossi</name>
</author>
<author>
<name sortKey="Rega, N" uniqKey="Rega N">N Rega</name>
</author>
<author>
<name sortKey="Millam, Jm" uniqKey="Millam J">JM Millam</name>
</author>
<author>
<name sortKey="Klene, M" uniqKey="Klene M">M Klene</name>
</author>
<author>
<name sortKey="Knox, Je" uniqKey="Knox J">JE Knox</name>
</author>
<author>
<name sortKey="Cross, Jb" uniqKey="Cross J">JB Cross</name>
</author>
<author>
<name sortKey="Bakken, V" uniqKey="Bakken V">V Bakken</name>
</author>
<author>
<name sortKey="Adamo, C" uniqKey="Adamo C">C Adamo</name>
</author>
<author>
<name sortKey="Jaramillo, J" uniqKey="Jaramillo J">J Jaramillo</name>
</author>
<author>
<name sortKey="Gomperts, R" uniqKey="Gomperts R">R Gomperts</name>
</author>
<author>
<name sortKey="Stratmann, Re" uniqKey="Stratmann R">RE Stratmann</name>
</author>
<author>
<name sortKey="Yazyev, O" uniqKey="Yazyev O">O Yazyev</name>
</author>
<author>
<name sortKey="Austin, Aj" uniqKey="Austin A">AJ Austin</name>
</author>
<author>
<name sortKey="Cammi, R" uniqKey="Cammi R">R Cammi</name>
</author>
<author>
<name sortKey="Pomelli, C" uniqKey="Pomelli C">C Pomelli</name>
</author>
<author>
<name sortKey="Ochterski, Jw" uniqKey="Ochterski J">JW Ochterski</name>
</author>
<author>
<name sortKey="Martin, Rl" uniqKey="Martin R">RL Martin</name>
</author>
<author>
<name sortKey="Morokuma, K" uniqKey="Morokuma K">K Morokuma</name>
</author>
<author>
<name sortKey="Zakrzewski, Vg" uniqKey="Zakrzewski V">VG Zakrzewski</name>
</author>
<author>
<name sortKey="Voth, Ga" uniqKey="Voth G">GA Voth</name>
</author>
<author>
<name sortKey="Salvador, P" uniqKey="Salvador P">P Salvador</name>
</author>
<author>
<name sortKey="Dannenberg, Jj" uniqKey="Dannenberg J">JJ Dannenberg</name>
</author>
<author>
<name sortKey="Dapprich, S" uniqKey="Dapprich S">S Dapprich</name>
</author>
<author>
<name sortKey="Daniels, Ad" uniqKey="Daniels A">AD Daniels</name>
</author>
<author>
<name sortKey="Farkas, O" uniqKey="Farkas O">Ö Farkas</name>
</author>
<author>
<name sortKey="Foresman, Jb" uniqKey="Foresman J">JB Foresman</name>
</author>
<author>
<name sortKey="Ortiz, Jv" uniqKey="Ortiz J">JV Ortiz</name>
</author>
<author>
<name sortKey="Cioslowski, J" uniqKey="Cioslowski J">J Cioslowski</name>
</author>
<author>
<name sortKey="Fox, Dj" uniqKey="Fox D">DJ Fox</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Valiev, M" uniqKey="Valiev M">M Valiev</name>
</author>
<author>
<name sortKey="Bylaska, Ej" uniqKey="Bylaska E">EJ Bylaska</name>
</author>
<author>
<name sortKey="Govind, N" uniqKey="Govind N">N Govind</name>
</author>
<author>
<name sortKey="Kowalski, K" uniqKey="Kowalski K">K Kowalski</name>
</author>
<author>
<name sortKey="Straatsma, Tp" uniqKey="Straatsma T">TP Straatsma</name>
</author>
<author>
<name sortKey="Van Dam, Hjj" uniqKey="Van Dam H">HJJ Van Dam</name>
</author>
<author>
<name sortKey="Wang, D" uniqKey="Wang D">D Wang</name>
</author>
<author>
<name sortKey="Nieplocha, J" uniqKey="Nieplocha J">J Nieplocha</name>
</author>
<author>
<name sortKey="Apra, E" uniqKey="Apra E">E Apra</name>
</author>
<author>
<name sortKey="Windus, Tl" uniqKey="Windus T">TL Windus</name>
</author>
<author>
<name sortKey="De Jong, Wa" uniqKey="De Jong W">WA de Jong</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Glendening, Ed" uniqKey="Glendening E">ED Glendening</name>
</author>
<author>
<name sortKey="Landis, Cr" uniqKey="Landis C">CR Landis</name>
</author>
<author>
<name sortKey="Weinhold, F" uniqKey="Weinhold F">F Weinhold</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Grimme, S" uniqKey="Grimme S">S Grimme</name>
</author>
<author>
<name sortKey="Ehrlich, S" uniqKey="Ehrlich S">S Ehrlich</name>
</author>
<author>
<name sortKey="Goerigk, L" uniqKey="Goerigk L">L Goerigk</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Grimme, S" uniqKey="Grimme S">S Grimme</name>
</author>
<author>
<name sortKey="Anthony, J" uniqKey="Anthony J">J Anthony</name>
</author>
<author>
<name sortKey="Ehrlich, S" uniqKey="Ehrlich S">S Ehrlich</name>
</author>
<author>
<name sortKey="Krieg, H" uniqKey="Krieg H">H Krieg</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Hoffmann, A" uniqKey="Hoffmann A">A Hoffmann</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Hoffmann, A" uniqKey="Hoffmann A">A Hoffmann</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Jesser, A" uniqKey="Jesser A">A Jesser</name>
</author>
<author>
<name sortKey="Rohrmuller, M" uniqKey="Rohrmuller M">M Rohrmüller</name>
</author>
<author>
<name sortKey="Schmidt, Wg" uniqKey="Schmidt W">WG Schmidt</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Hoffmann, A" uniqKey="Hoffmann A">A Hoffmann</name>
</author>
<author>
<name sortKey="Rohrmuller, M" uniqKey="Rohrmuller M">M Rohrmüller</name>
</author>
<author>
<name sortKey="Jesser, A" uniqKey="Jesser A">A Jesser</name>
</author>
<author>
<name sortKey="Dos Santos, Vieira I" uniqKey="Dos Santos V">Vieira I dos Santos</name>
</author>
<author>
<name sortKey="Schmidt, Wg" uniqKey="Schmidt W">WG Schmidt</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Rohrmuller, M" uniqKey="Rohrmuller M">M Rohrmüller</name>
</author>
<author>
<name sortKey="Hoffmann, A" uniqKey="Hoffmann A">A Hoffmann</name>
</author>
<author>
<name sortKey="Thierfelder, C" uniqKey="Thierfelder C">C Thierfelder</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
<author>
<name sortKey="Schmidt, Wg" uniqKey="Schmidt W">WG Schmidt</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Neese, F" uniqKey="Neese F">F Neese</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Tsipis, Ac" uniqKey="Tsipis A">AC Tsipis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Matyjaszewski, K" uniqKey="Matyjaszewski K">K Matyjaszewski</name>
</author>
<author>
<name sortKey="Davis, Tp" uniqKey="Davis T">TP Davis</name>
</author>
</analytic>
</biblStruct>
<biblStruct>
<analytic>
<author>
<name sortKey="Hoffmann, A" uniqKey="Hoffmann A">A Hoffmann</name>
</author>
<author>
<name sortKey="Borner, J" uniqKey="Borner J">J Börner</name>
</author>
<author>
<name sortKey="Florke, U" uniqKey="Florke U">U Flörke</name>
</author>
<author>
<name sortKey="Herres Pawlis, S" uniqKey="Herres Pawlis S">S Herres-Pawlis</name>
</author>
</analytic>
</biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article">
<pmc-dir>properties open_access</pmc-dir>
<front>
<journal-meta>
<journal-id journal-id-type="nlm-ta">J Cheminform</journal-id>
<journal-id journal-id-type="iso-abbrev">J Cheminform</journal-id>
<journal-title-group>
<journal-title>Journal of Cheminformatics</journal-title>
</journal-title-group>
<issn pub-type="epub">1758-2946</issn>
<publisher>
<publisher-name>Springer International Publishing</publisher-name>
<publisher-loc>Cham</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="pmid">27818709</article-id>
<article-id pub-id-type="pmc">5073744</article-id>
<article-id pub-id-type="publisher-id">169</article-id>
<article-id pub-id-type="doi">10.1186/s13321-016-0169-8</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Methodology</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname>Arshad</surname>
<given-names>Junaid</given-names>
</name>
<address>
<email>rjarshad@gmail.com</email>
</address>
<xref ref-type="aff" rid="Aff1">1</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Hoffmann</surname>
<given-names>Alexander</given-names>
</name>
<address>
<email>alexander.hoffmann@ac.rwth-aachen.de</email>
</address>
<xref ref-type="aff" rid="Aff2">2</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Gesing</surname>
<given-names>Sandra</given-names>
</name>
<address>
<email>sandra.gesing@nd.edu</email>
</address>
<xref ref-type="aff" rid="Aff3">3</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Grunzke</surname>
<given-names>Richard</given-names>
</name>
<address>
<email>richard.grunzke@tu-dresden.de</email>
</address>
<xref ref-type="aff" rid="Aff4">4</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Krüger</surname>
<given-names>Jens</given-names>
</name>
<address>
<email>krueger@informatik.uni-tuebingen.de</email>
</address>
<xref ref-type="aff" rid="Aff5">5</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Kiss</surname>
<given-names>Tamas</given-names>
</name>
<address>
<email>T.Kiss@westminster.ac.uk</email>
</address>
<xref ref-type="aff" rid="Aff1">1</xref>
</contrib>
<contrib contrib-type="author" corresp="yes">
<contrib-id contrib-id-type="orcid">http://orcid.org/0000-0002-4354-4353</contrib-id>
<name>
<surname>Herres-Pawlis</surname>
<given-names>Sonja</given-names>
</name>
<address>
<email>sonja.herres-pawlis@ac.rwth-aachen.de</email>
</address>
<xref ref-type="aff" rid="Aff2">2</xref>
</contrib>
<contrib contrib-type="author" corresp="yes">
<name>
<surname>Terstyanszky</surname>
<given-names>Gabor</given-names>
</name>
<address>
<email>g.z.terstyanszky@westminster.ac.uk</email>
</address>
<xref ref-type="aff" rid="Aff1">1</xref>
</contrib>
<aff id="Aff1">
<label>1</label>
Centre for Parallel Computing, School of Computer Science, University of Westminster, 115 New Cavendish Street, London, W1W 6UW UK</aff>
<aff id="Aff2">
<label>2</label>
Institut für Anorganische Chemie, Lehrstuhl für Bioanorganische Chemie, RWTH Aachen University, Landoltweg 1, 52074 Aachen, Germany</aff>
<aff id="Aff3">
<label>3</label>
University of Notre Dame, 123 Information Technology Center, Notre Dame, IN 46556 USA</aff>
<aff id="Aff4">
<label>4</label>
Center for Information Services and High Performance Computing, Technische Universität Dresden, Zellescher Weg 12-14, 01062 Dresden, Germany</aff>
<aff id="Aff5">
<label>5</label>
Applied Bioinformatics Tübingen, University of Tübingen, Sand 14, 72076 Tübingen, Germany</aff>
</contrib-group>
<pub-date pub-type="epub">
<day>20</day>
<month>10</month>
<year>2016</year>
</pub-date>
<pub-date pub-type="pmc-release">
<day>20</day>
<month>10</month>
<year>2016</year>
</pub-date>
<pub-date pub-type="collection">
<year>2016</year>
</pub-date>
<volume>8</volume>
<elocation-id>58</elocation-id>
<history>
<date date-type="received">
<day>14</day>
<month>2</month>
<year>2016</year>
</date>
<date date-type="accepted">
<day>4</day>
<month>10</month>
<year>2016</year>
</date>
</history>
<permissions>
<copyright-statement>© The Author(s) 2016</copyright-statement>
<license license-type="OpenAccess">
<license-p>
<bold>Open Access</bold>
This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (
<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/4.0/">http://creativecommons.org/licenses/by/4.0/</ext-link>
), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made. The Creative Commons Public Domain Dedication waiver (
<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/publicdomain/zero/1.0/">http://creativecommons.org/publicdomain/zero/1.0/</ext-link>
) applies to the data made available in this article, unless otherwise stated.</license-p>
</license>
</permissions>
<abstract id="Abs1">
<sec>
<title>Background</title>
<p>In Quantum Chemistry, many tasks are reoccurring frequently, e.g. geometry optimizations, benchmarking series etc. Here, workflows can help to reduce the time of manual job definition and output extraction. These workflows are executed on computing infrastructures and may require large computing and data resources. Scientific workflows hide these infrastructures and the resources needed to run them. It requires significant efforts and specific expertise to design, implement and test these workflows.</p>
</sec>
<sec>
<title>Significance</title>
<p>Many of these workflows are complex and monolithic entities that can be used for particular scientific experiments. Hence, their modification is not straightforward and it makes almost impossible to share them. To address these issues we propose developing atomic workflows and embedding them in meta-workflows. Atomic workflows deliver a well-defined research domain specific function. Publishing workflows in repositories enables workflow sharing inside and/or among scientific communities. We formally specify atomic and meta-workflows in order to define data structures to be used in repositories for uploading and sharing them. Additionally, we present a formal description focused at orchestration of atomic workflows into meta-workflows.</p>
</sec>
<sec>
<title>Conclusions</title>
<p>We investigated the operations that represent basic functionalities in Quantum Chemistry, developed the relevant atomic workflows and combined them into meta-workflows. Having these workflows we defined the structure of the Quantum Chemistry workflow library and uploaded these workflows in the SHIWA Workflow Repository.
<fig position="anchor" id="Figa">
<label>Graphical Abstract</label>
<caption>
<p>Meta-workflows and embedded workflows in the template representation</p>
</caption>
<graphic position="anchor" xlink:href="13321_2016_169_Figa_HTML" id="MO1"></graphic>
</fig>
</p>
</sec>
<sec>
<title>Electronic supplementary material</title>
<p>The online version of this article (doi:10.1186/s13321-016-0169-8) contains supplementary material, which is available to authorized users.</p>
</sec>
</abstract>
<kwd-group xml:lang="en">
<title>Keywords</title>
<kwd>Scientific workflows</kwd>
<kwd>Workflow repository</kwd>
<kwd>Quantum chemistry</kwd>
<kwd>Meta-workflow</kwd>
<kwd>Atomic workflow</kwd>
</kwd-group>
<funding-group>
<award-group>
<funding-source>
<institution-wrap>
<institution-id institution-id-type="FundRef">http://dx.doi.org/10.13039/501100001659</institution-id>
<institution>Deutsche Forschungsgemeinschaft</institution>
</institution-wrap>
</funding-source>
<award-id>FOR1405</award-id>
<award-id>MASi (NA711/9-1)</award-id>
<principal-award-recipient>
<name>
<surname>Herres-Pawlis</surname>
<given-names>Sonja</given-names>
</name>
</principal-award-recipient>
</award-group>
<award-group>
<funding-source>
<institution-wrap>
<institution-id institution-id-type="FundRef">http://dx.doi.org/10.13039/501100004963</institution-id>
<institution>Seventh Framework Programme</institution>
</institution-wrap>
</funding-source>
<award-id>283481 (SCI-BUS)</award-id>
<award-id>no 312579 (ER-flow)</award-id>
</award-group>
</funding-group>
<custom-meta-group>
<custom-meta>
<meta-name>issue-copyright-statement</meta-name>
<meta-value>© The Author(s) 2016</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body>
<sec id="Sec1">
<title>Background</title>
<p>Scientific workflows represent complex computational experiments conducted by scientists focused at identifying and addressing scientific problems across diverse subject domains such as Quantum Chemistry simulations [
<xref ref-type="bibr" rid="CR1">1</xref>
], Astrophysics [
<xref ref-type="bibr" rid="CR2">2</xref>
], Heliophysics [
<xref ref-type="bibr" rid="CR3">3</xref>
] and Neuroimaging data analysis [
<xref ref-type="bibr" rid="CR4">4</xref>
]. Such experiments usually involve analysis of large volumes of data and typically they are executed in Distributed Computing Infrastructures (DCIs), such as clouds, clusters, supercomputers, etc. as demonstrated by [
<xref ref-type="bibr" rid="CR5">5</xref>
,
<xref ref-type="bibr" rid="CR6">6</xref>
]. Scientific workflows represent an abstraction that hides the complexity of the involved computing and data infrastructures. They are often composed of control and data flow statements and rules which perform the analysis required to achieve the intended experiment. A typical scientific workflow is composed of one or more distinct tasks (often termed as
<italic>jobs).</italic>
Each of these jobs performs a specific function and contributes to the overall goal of the workflow e.g., a single point energy, frequency calculation, etc. An interesting and emerging trend in workflow development is to orchestrate workflows from one or more sub-workflows, i.e. individual jobs may be workflows designed to achieve a specific function. Such composite workflows are termed as
<italic>meta</italic>
-
<italic>workflows</italic>
[
<xref ref-type="bibr" rid="CR7">7</xref>
<xref ref-type="bibr" rid="CR9">9</xref>
] and are envisaged to use existing workflows as components of the meta-workflow for improving their development and enabling their reusability. With respect to reusing multiple workflows to achieve a more complex task, terms such as
<italic>nested workflows</italic>
[
<xref ref-type="bibr" rid="CR10">10</xref>
] and
<italic>embedded workflows</italic>
[
<xref ref-type="bibr" rid="CR11">11</xref>
] have also been used. However, these refer to sub workflows that are collated to orchestrate meta-workflows. The development and use of meta-workflows is facilitated by repositories such as [
<xref ref-type="bibr" rid="CR12">12</xref>
<xref ref-type="bibr" rid="CR14">14</xref>
] which aim to store and share scientific workflows. The existence and flexibility of such repositories enables workflow sharing to wider scientific communities thereby facilitating development of meta-workflows to achieve modelling complex scientific problems via workflows. Meta-workflows engage complex orchestration of applications, which may span across multiple domains. For such complex workflows the workflow nodes represent a combination of jobs and sub-workflows, which can host multiple tasks within them. However, there remain challenges in achieving widespread workflow sharing as different workflow repositories may choose different approaches to describe workflows leading to problems in sharing workflows across repositories.</p>
<p>Computational Chemistry covers a broad range of scientific challenges and consequently a multitude of methods and algorithms have been developed over the past decades. They can be subdivided into several sub-domains including Quantum Chemistry (QC), Molecular Dynamics (MD) and Molecular Docking. Within each sub-domain simulation protocols have emerged which can be considered to be good practice within the field. These sub-domains strongly differ in theoretical approaches, simulation codes and workflows. For example in docking and Molecular Dynamics, workflows have some longer tradition [
<xref ref-type="bibr" rid="CR15">15</xref>
<xref ref-type="bibr" rid="CR17">17</xref>
] than in other sub-domains. Within the MoSGrid Science Gateway [
<xref ref-type="bibr" rid="CR18">18</xref>
], which has adopted the WS-PGRADE workflow system [
<xref ref-type="bibr" rid="CR19">19</xref>
], workflows have been used extensively especially in the Docking and Molecular Dynamics domain contributing to facilitated job submission and output analysis. The concept of complex meta-workflows has been recently introduced into the Quantum Chemistry sub-domain. These workflows consist of workflows with a basic set of operations that can be re-used in different complex workflows [
<xref ref-type="bibr" rid="CR1">1</xref>
].</p>
<p>Several production workflow systems have been developed in the last decade, which serve diverse user communities, follow different workflow concepts, support different workflow languages and are based on different workflow technologies. Examples are Dispel [
<xref ref-type="bibr" rid="CR20">20</xref>
], Galaxy [
<xref ref-type="bibr" rid="CR21">21</xref>
], Kepler [
<xref ref-type="bibr" rid="CR22">22</xref>
], KNIME [
<xref ref-type="bibr" rid="CR23">23</xref>
], Pegasus [
<xref ref-type="bibr" rid="CR24">24</xref>
], Swift [
<xref ref-type="bibr" rid="CR25">25</xref>
], Taverna [
<xref ref-type="bibr" rid="CR26">26</xref>
] and WS-PGRADE [
<xref ref-type="bibr" rid="CR27">27</xref>
]. While all enable scientific workflow management, Galaxy, Kepler, KNIME, Taverna, and WS-PGRADE are widely used in the Computational Chemistry community.</p>
<p>WS-PGRADE is a flexible web-based user interface of the gUSE scientific gateway framework. It is built on the Liferay portal framework [
<xref ref-type="bibr" rid="CR28">28</xref>
], which allows easily extending WS-PGRADE’s user interface for domain-specific features via so-called portlets and needs only installation on the server side while users can access all features via a web browser. WS-PGRADE offers workflow management features including editing, configuring, submitting and monitoring workflows plus a repository for storing workflows. This repository enables users to share workflows and to import or export workflows from and to other WS-PGRADE portals. Besides the workflow repository in WS-PGRADE, other related repositories have been implemented with complimentary features. The SCI-BUS Portlet Repository [
<xref ref-type="bibr" rid="CR29">29</xref>
] has been developed to share portlets and the available user interface features provided by such extensions. The SHIWA Workflow Repository [
<xref ref-type="bibr" rid="CR12">12</xref>
] follows a workflow-driven approach and allows sharing workflows between major workflow platforms such as Galaxy, Kepler, Pegasus, Taverna, WS-PGRADE, etc. There are several science gateways based on the gUSE framework in the Computational Chemistry community for example the MoSGrid portal [
<xref ref-type="bibr" rid="CR30">30</xref>
], the AutoDock Portal [
<xref ref-type="bibr" rid="CR31">31</xref>
] as well as the AMC Docking Gateway [
<xref ref-type="bibr" rid="CR32">32</xref>
]. As above mentioned, MoSGrid supports the following three domains: Docking, Molecular Dynamics (MD) and Quantum Chemistry (QC), while the AutoDock Portal and the AMC Docking Gateway are concerned with leveraging AutoDock [
<xref ref-type="bibr" rid="CR33">33</xref>
] or AutoDock Vina [
<xref ref-type="bibr" rid="CR34">34</xref>
], respectively, for the Docking community. The latter portals apply pre-configured workflows similar to MoSGrid, whereas MoSGrid additionally applies the meta-workflow concept.</p>
<p>The KNIME workbench supports also the meta-workflow concept and enables users to easily orchestrate Computational Chemistry workflows via basic workflows in its repository. While its user interface is very intuitive, it needs installation on the user side. The KNIME Web Portal, which relieves users from the local installation, also gives access to the repository but does not possess all the features of the workbench such as reporting tools directly.</p>
<p>Taverna follows a similar approach compared to the KNIME workbench and requires local installations on the user’s computers. Taverna workflows can be shared in a web-based environment via the social platform myExperiment [
<xref ref-type="bibr" rid="CR14">14</xref>
]. The meta-workflow concept is not supported directly in Taverna but via the web-based solution Tavaxy [
<xref ref-type="bibr" rid="CR7">7</xref>
]. This workflow system has been especially created to implement the meta-workflow concept via featuring to connect Taverna and Galaxy workflows with each other and submit them. Galaxy workflows can be additionally edited in Tavaxy, while Taverna workflows can be simply re-used but not changed. Galaxy as widely used portal in the biomedical community offers also a web-based repository for sharing workflows but lacks the support of the meta-workflow concept. Further workflow solutions tailored to the Computational Chemistry community include Kepler, PyADF [
<xref ref-type="bibr" rid="CR35">35</xref>
] and JACOB [
<xref ref-type="bibr" rid="CR36">36</xref>
]. They are highly flexible and apply cutting edge technologies such as RESTful APIs. While the meta-workflow concept is not directly supported out of the box, they can be extended to support it. Such solutions necessitate programming skills on the users’ side though.</p>
<p>Our focus here is to investigate the challenges encountered in developing and using complex meta-workflows. In particular, we make the following major contributions:
<list list-type="bullet">
<list-item>
<p>Formal definitions for atomic workflows have been formulated to facilitate their understanding and reuse by addressing challenges in workflow sharing</p>
</list-item>
<list-item>
<p>A template-based approach to create complex meta-workflows has been presented along with its formal representation</p>
</list-item>
<list-item>
<p>Use cases from quantum chemistry workflows have been included which represent successful demonstrations of the concepts and technologies presented herein.</p>
</list-item>
</list>
</p>
</sec>
<sec id="Sec2" sec-type="materials|methods">
<title>Methods</title>
<sec id="Sec3">
<title>Sharing scientific workflows</title>
<p>In [
<xref ref-type="bibr" rid="CR37">37</xref>
] a formal description of scientific workflows was presented to enable sharing workflows inside and among research communities. This formal description defines the data and meta-data structure of scientific workflows required to manage workflows, including their uploading, editing, searching and downloading, in workflow repositories. The formal description also provides extra supports for sharing workflows of different workflow systems and their combination into meta-workflows and executing them on different DCIs.</p>
</sec>
<sec id="Sec4">
<title>Atomic and compound workflows and their formal description</title>
<p>Scientific workflows are generally defined by four entities: abstract workflow, concrete workflow, workflow configuration and workflow engine. The abstract workflow specifies the functionality of the workflow. It defines the workflow structure as a workflow graph including its inputs and outputs, and its edges and nodes where nodes correspond to computational tasks and edges represent the control and/or data flow among nodes. It does not contain any executables, default input files and parameters needed to run the workflow. Abstract workflows may have multiple implementations defined by concrete workflows. The concrete workflow defines a workflow instance for a particular workflow engine. It delivers the functionality defined by the abstract workflow. It contains either data or references (via e.g., URLs) required to run the workflow on the associated workflow engine. Each concrete workflow has its own workflow configuration that contains parameters, references and files of the concrete workflow. Finally, the workflow engine identifies the workflow engine that executes the concrete workflow. Therefore, as described in [
<xref ref-type="bibr" rid="CR37">37</xref>
], a scientific workflow can be formally defined as
<disp-formula id="Equ1">
<label>1</label>
<alternatives>
<tex-math id="M1">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{WF}} = :\left\{ {{\text{WF}}_{\text{abs}} ,{\text{WF}}_{\text{cnr}} ,{\text{ WF}}_{\text{cnf}} ,{\text{ WF}}_{\text{eng}} } \right\} $$\end{document}</tex-math>
<mml:math id="M2" display="block">
<mml:mrow>
<mml:mtext>WF</mml:mtext>
<mml:mo>=</mml:mo>
<mml:mo>:</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mtext>abs</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mtext>cnr</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>WF</mml:mtext>
</mml:mrow>
<mml:mtext>cnf</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>WF</mml:mtext>
</mml:mrow>
<mml:mtext>eng</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ1.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where WF
<sub>abs</sub>
—abstract workflow, WF
<sub>cnr</sub>
—concrete workflow, WF
<sub>cnf</sub>
—workflow configuration, WF
<sub>eng</sub>
—workflow engine.</p>
<p>Workflows may orchestrate complex scientific experiments with a large number of workflow nodes. These workflows are monolithic entities supporting one particular experiment. If there is need to change a scientific experiment, workflow developers have to re-design and test the whole workflow again. It may require significant efforts in both resources and time. Analysing these workflows it can be concluded that they may contain a job or a set of jobs delivering a specific functionality that can be re-used in further scientific experiments. To support workflow sharing and re-usability we introduce the concept of atomic workflows to implement modularity within scientific workflows [
<xref ref-type="bibr" rid="CR13">13</xref>
,
<xref ref-type="bibr" rid="CR37">37</xref>
]. An atomic workflow is a special type of workflows, which is aimed to achieve a very specific objective delivering a specific function with a specific set of inputs and outputs. They contain only jobs i.e. they do not incorporate any further workflows. They represent a job or a set of jobs that can be re-used as part of more complex workflows. An example of such workflows can be a simple geometry optimization workflow in Computational Chemistry which can be re-used as part of a number of other possible workflows such as frequency calculation, time-dependent DFT, population analyses, etc. as demonstrated in [
<xref ref-type="bibr" rid="CR38">38</xref>
]. Since atomic workflows deliver a well-defined functionality we manage them at the abstract workflow level. To manage atomic workflows both the formal definition of abstract workflows and their data structure must be extended.</p>
<p>In [
<xref ref-type="bibr" rid="CR39">39</xref>
], we used
<italic>jobs</italic>
as a structure to represent the set of functions envisaged to be performed by a workflow. In abstract workflows
<italic>jobs</italic>
represent a set of functionalities while in concrete workflows they are the binaries that deliver these functionalities. Therefore,
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
<italic>(I</italic>
<sub>
<italic>h</italic>
</sub>
<italic>, O</italic>
<sub>
<italic>h</italic>
</sub>
<italic>)</italic>
<italic>jobs; h</italic>
 = 
<italic>1,…, k</italic>
where
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
represents the set of functions to be performed by a workflow. As an atomic workflow is envisaged to be focused on accomplishing a single specific function, this can be represented as
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
<italic>(I</italic>
<sub>
<italic>h</italic>
</sub>
<italic>, O</italic>
<sub>
<italic>h</italic>
</sub>
<italic>)</italic>
<italic>jobs; h</italic>
 = 
<italic>1</italic>
. As described above, this function is assumed to be generic enough to be re-used as part of more complex workflows. Now, the function
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
is expected to operate with a generic set of input
<italic>I,</italic>
which is envisaged to vary across application domains. Furthermore,
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
is expected to produce a specific set of outputs
<italic>O,</italic>
which can be consumed by other atomic workflows and/or jobs within a complex workflow. Within the context of the terminology used by workflow systems, the function
<italic>f</italic>
<sub>
<italic>h</italic>
</sub>
represents a ‘job’, which is envisaged to execute specific function as part of the overall workflow. We use the formalism presented in [
<xref ref-type="bibr" rid="CR37">37</xref>
], to further elaborate the inputs and outputs of the atomic workflows:</p>
<p>atomic workflow:
<disp-formula id="Equ2">
<label>2</label>
<alternatives>
<tex-math id="M3">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{WF}}_{\text{AT}} = : \, \left\{ {{\text{job}}\left( {{\text{f}}_{\text{h}} } \right)} \right\} $$\end{document}</tex-math>
<mml:math id="M4" display="block">
<mml:mrow>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mtext>AT</mml:mtext>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mo>:</mml:mo>
<mml:mspace width="0.166667em"></mml:mspace>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:mtext>job</mml:mtext>
<mml:mfenced close=")" open="(" separators="">
<mml:msub>
<mml:mtext>f</mml:mtext>
<mml:mtext>h</mml:mtext>
</mml:msub>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ2.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where h = 1;</p>
<p>job(f
<sub>h</sub>
) ∈
<italic>jobs</italic>
</p>
<p>inputs:
<disp-formula id="Equ3">
<label>3</label>
<alternatives>
<tex-math id="M5">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ I = \, \left\{ {{\text{I}}_{1} ,{\text{ I}}_{2} ,{\text{ I}}_{3} , \ldots ,{\text{I}}_{u} } \right\} $$\end{document}</tex-math>
<mml:math id="M6" display="block">
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:mo>=</mml:mo>
<mml:mspace width="0.166667em"></mml:mspace>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>I</mml:mtext>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>I</mml:mtext>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>I</mml:mtext>
</mml:mrow>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo></mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mtext>I</mml:mtext>
<mml:mi>u</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ3.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where I
<sub>i</sub>
—input for the workflow; i = 1,…, u</p>
<p>I
<sub>i</sub>
 = {input_id, input_description, input_data_type}</p>
<p>outputs:
<disp-formula id="Equ4">
<label>4</label>
<alternatives>
<tex-math id="M7">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ O \, = \left\{ {{\text{O}}_{1} ,{\text{ O}}_{2} ,{\text{ O}}_{3} , \ldots,{\text{ O}}_{v} } \right\} $$\end{document}</tex-math>
<mml:math id="M8" display="block">
<mml:mrow>
<mml:mi>O</mml:mi>
<mml:mspace width="0.166667em"></mml:mspace>
<mml:mo>=</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>O</mml:mtext>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>O</mml:mtext>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>O</mml:mtext>
</mml:mrow>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo></mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>O</mml:mtext>
</mml:mrow>
<mml:mi>v</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ4.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where O
<sub>j</sub>
—output for the workflow; j = 1,…, v, O
<sub>j</sub>
 = {output_id, output_description, output_data_type}</p>
<p>Having the formal description of the atomic workflows and their functionality at the abstract workflow level we extended the data and meta-data structure of abstract workflows. (See in Table 
<xref rid="Tab1" ref-type="table">1</xref>
) These data structures enable publishing atomic workflows in workflow repositories, for example in the SHIWA Workflow Repository [
<xref ref-type="bibr" rid="CR12">12</xref>
]. As a result, atomic workflows can be searched and found in these repositories enabling workflow developers to embed atomic workflows with the required functionality in meta-workflows.
<table-wrap id="Tab1">
<label>Table 1</label>
<caption>
<p>Data structure of the atomic workflow’s functionality in the repository</p>
</caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left">Element</th>
<th align="left">Sub-element</th>
<th align="left">Sub-sub-element</th>
<th align="left">Data type</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Functionality</td>
<td align="left"></td>
<td align="left"></td>
<td align="left">Ontology vocabulary</td>
</tr>
<tr>
<td align="left">Input(s)</td>
<td align="left">input 1</td>
<td align="left">input_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input_description</td>
<td align="left">Plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input data type</td>
<td align="left">Data type</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">input 2</td>
<td align="left">input_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input_description</td>
<td align="left">plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input data type</td>
<td align="left">Data type</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">input…</td>
<td align="left"></td>
<td align="left"></td>
</tr>
<tr>
<td align="left"></td>
<td align="left">input u</td>
<td align="left">input_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input_description</td>
<td align="left">Plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">input data type</td>
<td align="left">Data type</td>
</tr>
<tr>
<td align="left">Output(s)</td>
<td align="left">output 1</td>
<td align="left">output_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output_description</td>
<td align="left">Plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output data type</td>
<td align="left">Data type</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">output 2</td>
<td align="left">output_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output_description</td>
<td align="left">Plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output data type</td>
<td align="left">Data type</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">output
<italic></italic>
</td>
<td align="left"></td>
<td align="left"></td>
</tr>
<tr>
<td align="left"></td>
<td align="left">output v</td>
<td align="left">output_id</td>
<td align="left">Integer</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output_description</td>
<td align="left">Plain text</td>
</tr>
<tr>
<td align="left"></td>
<td align="left"></td>
<td align="left">output data type</td>
<td align="left">Data type</td>
</tr>
</tbody>
</table>
</table-wrap>
</p>
</sec>
<sec id="Sec5">
<title>Workflow libraries and atomic workflows</title>
<p>Scientific workflows represent valuable knowledge incorporating verified methods to perform specific experiments. Within this context, sharing workflows to establish and improve collaborations facilitates advancement of scientific knowledge. Workflow repositories and libraries have a profound role in achieving this objective by providing the enabling environment. To support workflow sharing we recommend creating a workflow library of atomic workflows for a specific research area, a domain, and it may have multiple sub-domains. Defining a workflow library follows a top-down approach, i.e. first the domain is identified, next, the sub-domains are defined and finally, the functionality of atomic workflows specified.
<disp-formula id="Equ5">
<label>5</label>
<alternatives>
<tex-math id="M9">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{SUB}}\_{\text{DOMAIN}}_{k} \in {\text{DOMAIN}} $$\end{document}</tex-math>
<mml:math id="M10" display="block">
<mml:mrow>
<mml:mtext>SUB</mml:mtext>
<mml:mi>_</mml:mi>
<mml:msub>
<mml:mtext>DOMAIN</mml:mtext>
<mml:mi>k</mml:mi>
</mml:msub>
<mml:mo></mml:mo>
<mml:mtext>DOMAIN</mml:mtext>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ5.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where k = 1,…, w
<disp-formula id="Equ6">
<label>6</label>
<alternatives>
<tex-math id="M11">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{WF}}_{{{\text{AT}}({\text{l}})}} \in {\text{SUB}}\_{\text{DOMAIN}}_{\text{k}} $$\end{document}</tex-math>
<mml:math id="M12" display="block">
<mml:mrow>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mrow>
<mml:mtext>AT</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mtext>l</mml:mtext>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:msub>
<mml:mo></mml:mo>
<mml:mtext>SUB</mml:mtext>
<mml:mi>_</mml:mi>
<mml:msub>
<mml:mtext>DOMAIN</mml:mtext>
<mml:mtext>k</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ6.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where l = 1,…, y</p>
<p>Being familiar with a particular research domain, researchers can identify the relevant sub-domains and define the functionality of workflow library of each sub-domain.</p>
</sec>
<sec id="Sec6">
<title>Meta-workflows and their formal description</title>
<p>Complex workflows, also called meta-workflows, may contain jobs and workflows. We call workflows included in meta-workflows embedded workflows. We consider atomic workflows as a sub-set of embedded workflows.
<disp-formula id="Equ7">
<label>7</label>
<alternatives>
<tex-math id="M13">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{M}{-}\text{WF}} = :\left\{ {{\text{J}}_{1} \ldots .{\text{J}}_{{{\text{m}} + {\text{n}}}} } \right\} = \left\{ {{\text{J}}_{{{\text{WF}}1}} \ldots {\text{J}}_{\text{WFm}} ,\;{\text{WF}}_{{{\text{EM}}1}} \ldots {\text{WF}}_{\text{EMn}} ,} \right\} $$\end{document}</tex-math>
<mml:math id="M14" display="block">
<mml:mrow>
<mml:mrow>
<mml:mtext>M</mml:mtext>
<mml:mo>-</mml:mo>
<mml:mtext>WF</mml:mtext>
</mml:mrow>
<mml:mo>=</mml:mo>
<mml:mo>:</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo></mml:mo>
<mml:mo>.</mml:mo>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mrow>
<mml:mtext>m</mml:mtext>
<mml:mo>+</mml:mo>
<mml:mtext>n</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mfenced>
<mml:mo>=</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mrow>
<mml:mtext>WF</mml:mtext>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo></mml:mo>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mtext>WFm</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mspace width="0.277778em"></mml:mspace>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mrow>
<mml:mtext>EM</mml:mtext>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo></mml:mo>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mtext>EMn</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ7.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where J
<sub>WFm</sub>
—workflow job m = 1,…, z, WF
<sub>EMn</sub>
—embedded workflow n = 1,
<italic></italic>
, y, WF
<sub>AT</sub>
∈ WF
<sub>EM</sub>
</p>
<p>To support workflow sharing we propose to incorporate atomic workflows as embedded workflows in meta-workflows to achieve more complex functionalities with less development efforts. In Fig. 
<xref rid="Fig1" ref-type="fig">1</xref>
the meta-workflow contains three jobs (N1, N2 and N3) and one embedded atomic workflow with node CN1 and CN2.
<fig id="Fig1">
<label>Fig. 1</label>
<caption>
<p>Example for a meta-workflow</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig1_HTML" id="MO9"></graphic>
</fig>
</p>
<p>As part of our efforts in [
<xref ref-type="bibr" rid="CR39">39</xref>
], we identified different types of meta-workflows along with their formal definitions. These definitions are envisioned to make a significant contribution in supporting workflow developers to design new workflows by enabling them to comprehend the attributes and semantics of each type of meta-workflow. The different meta-workflow types are listed below with respective graphical representations from WS-PGRADE in Fig. 
<xref rid="Fig2" ref-type="fig">2</xref>
a–d representing all workflow nodes as jobs that could be either workflow jobs or embedded workflows according to Eq. 
<xref rid="Equ7" ref-type="">7</xref>
. Details of each of these can be found in [
<xref ref-type="bibr" rid="CR39">39</xref>
].
<fig id="Fig2">
<label>Fig. 2</label>
<caption>
<p>
<bold>a</bold>
Single job meta-workflow;
<bold>b</bold>
linear multi-job meta-workflow;
<bold>c</bold>
Parallel multi-job meta-workflow;
<bold>d</bold>
parameter sweep meta-workflow</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig2_HTML" id="MO10"></graphic>
</fig>
<list list-type="order">
<list-item>
<p>
<italic>Single job meta</italic>
-
<italic>workflow (Fig.</italic>
 
<xref rid="Fig2" ref-type="fig">2</xref>
<italic>a):</italic>
This is a special type of meta-workflow with a single job workflow. The job representing this workflow can be a simple job or an embedded workflow.</p>
</list-item>
<list-item>
<p>
<italic>Linear multi</italic>
-
<italic>job meta</italic>
-
<italic>workflow (Fig.</italic>
 
<xref rid="Fig2" ref-type="fig">
<italic>2</italic>
</xref>
<italic>b):</italic>
This is a pipeline of multiple jobs in the native workflow system where any (or even all) of these jobs can be non-native workflows. The execution of each job depends on the receipt of inputs from previous jobs.</p>
</list-item>
<list-item>
<p>
<italic>Parallel multi</italic>
-
<italic>job meta</italic>
-
<italic>workflow (Fig.</italic>
 
<xref rid="Fig2" ref-type="fig">2</xref>
<italic>c):</italic>
This is a workflow in the native workflow system that includes parallel branches. One or more of these branches can include one or more non-native workflows.</p>
</list-item>
<list-item>
<p>
<italic>Parameter sweep meta</italic>
-
<italic>workflow (Fig.</italic>
 
<xref rid="Fig2" ref-type="fig">2</xref>
<italic>d):</italic>
The parameter sweep meta-workflow has a generator job which produces a number of inputs each to be consumed by a worker job. The collector job then aggregates the outputs of all the worker jobs and prepares the final output.</p>
</list-item>
</list>
</p>
<p>Considering that there could be multiple level of workflow embedding in meta-workflows we introduce
<italic>p</italic>
as the depth to describe it.
<disp-formula id="Equ8">
<label>8</label>
<alternatives>
<tex-math id="M15">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{M}}^{\text{p}}{-}{\text{WF}} = :\left\{ {{\text{J}}_{{{\text{WF}}1}} \ldots {\text{J}}_{\text{WFm}} ,\;{\text{WF}}_{{{\text{EM}}1}}^{{{\text{q}}1}} \ldots {\text{WF}}_{\text{EMn}}^{\text{qn}} ,} \right\} $$\end{document}</tex-math>
<mml:math id="M16" display="block">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mtext>M</mml:mtext>
</mml:mrow>
<mml:mtext>p</mml:mtext>
</mml:msup>
<mml:mo>-</mml:mo>
<mml:mtext>WF</mml:mtext>
<mml:mo>=</mml:mo>
<mml:mo>:</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mrow>
<mml:mtext>WF</mml:mtext>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo></mml:mo>
<mml:msub>
<mml:mtext>J</mml:mtext>
<mml:mtext>WFm</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mspace width="0.277778em"></mml:mspace>
<mml:msubsup>
<mml:mtext>WF</mml:mtext>
<mml:mrow>
<mml:mrow>
<mml:mtext>EM</mml:mtext>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mrow>
<mml:mrow>
<mml:mtext>q</mml:mtext>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:mo></mml:mo>
<mml:msubsup>
<mml:mtext>WF</mml:mtext>
<mml:mrow>
<mml:mtext>EMn</mml:mtext>
</mml:mrow>
<mml:mtext>qn</mml:mtext>
</mml:msubsup>
<mml:mo>,</mml:mo>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ8.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
where p—depth of the meta-workflow p = MAX{q
<sub>1</sub>
,…, q
<sub>n</sub>
}, q—depth of the embedded workflow q = 1, …, n</p>
<p>Figure 
<xref rid="Fig3" ref-type="fig">3</xref>
presents a meta-workflow of depth 2. It combines an atomic workflow Job(AWF1), a meta-workflow Job(MWF1) and an embedded workflow Job(EWF1).
<fig id="Fig3">
<label>Fig. 3</label>
<caption>
<p>Meta-workflow of depth 2</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig3_HTML" id="MO12"></graphic>
</fig>
</p>
</sec>
</sec>
<sec id="Sec7">
<title>Results and discussion</title>
<sec id="Sec8">
<title>Creating meta-workflows using atomic workflows</title>
<p>Two leading approaches for meta-workflow creation are the template-based approach to construct meta-workflows containing embedded workflows of the same workflow system and the black box based approach to develop meta-workflows incorporating embedded workflows of different workflow systems. Since we will use only WS-PGRADE workflows to outline how the Computational Chemistry community identifies and develops atomic workflows and constructs meta-workflows we will only describe the template based approach.</p>
</sec>
<sec id="Sec9">
<title>Template based meta-workflow development</title>
<p>The template-based approach is focused at enabling re-use of existing workflows as embedded atomic workflows whilst allowing some degree of freedom for their customization. This approach introduces the concept of a
<italic>template,</italic>
which describes the default configuration of an embedded workflow. This configuration includes a number of parameters such as the input and output, data required for processing and the executables consequently serving as a prototype for use of the workflow. The template also controls the customization allowed for a workflow being shared. For instance, a workflow developer may allow customization of the data type of the input but restrict the number of input ports allowed for the workflow. This approach, therefore, offers more flexibility to a workflow developer in creating atomic workflows for sharing across different scientific disciplines without making the process cumbersome for the end user. Figures 
<xref rid="Fig4" ref-type="fig">4</xref>
and
<xref rid="Fig5" ref-type="fig">5</xref>
presents a graphical representation of the template based approach for meta-workflow creation.
<fig id="Fig4">
<label>Fig. 4</label>
<caption>
<p>Template based approach for meta-workflow creation</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig4_HTML" id="MO13"></graphic>
</fig>
<fig id="Fig5">
<label>Fig. 5</label>
<caption>
<p>Template based meta-workflow creation</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig5_HTML" id="MO14"></graphic>
</fig>
</p>
<p>In order to formally describe the template based approach, we use the basic definition of the workflow given in (Eq. 
<xref rid="Equ1" ref-type="">1</xref>
). In the context of the template based approach, we define a
<italic>template</italic>
to encompass the configuration of a workflow as
<disp-formula id="Equ9">
<label>9</label>
<alternatives>
<tex-math id="M17">\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$ {\text{WF}}_{\text{temp}} = :\left\{ {{\text{in}}\_{\text{port}},{\text{ out}}\_{\text{port}},{\text{ target}}\_{\text{DCI}},{\text{ executable}}} \right\} $$\end{document}</tex-math>
<mml:math id="M18" display="block">
<mml:mrow>
<mml:msub>
<mml:mtext>WF</mml:mtext>
<mml:mtext>temp</mml:mtext>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mo>:</mml:mo>
<mml:mfenced close="}" open="{" separators="">
<mml:mrow>
<mml:mtext>in</mml:mtext>
<mml:mi>_</mml:mi>
<mml:mtext>port</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>out</mml:mtext>
</mml:mrow>
<mml:mi>_</mml:mi>
<mml:mtext>port</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>target</mml:mtext>
</mml:mrow>
<mml:mi>_</mml:mi>
<mml:mtext>DCI</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mrow>
<mml:mspace width="0.333333em"></mml:mspace>
<mml:mtext>executable</mml:mtext>
</mml:mrow>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<graphic xlink:href="13321_2016_169_Article_Equ9.gif" position="anchor"></graphic>
</alternatives>
</disp-formula>
</p>
<p>Furthermore, as defined in Eq. 
<xref rid="Equ7" ref-type="">7</xref>
a meta-workflow is composed of multiple embedded workflows and multiple jobs. Therefore,
<list list-type="bullet">
<list-item>
<p>WF_EM—set of embedded workflows for a meta-workflow, and</p>
</list-item>
<list-item>
<p>WF_ID—unique ID for the workflow</p>
</list-item>
<list-item>
<p>F_ID—unique ID for the workflow</p>
</list-item>
</list>
</p>
<p>The template-based approach has been implemented with the gUSE/WS-PGRADE science gateway technology as part of the ER-flow project [
<xref ref-type="bibr" rid="CR40">40</xref>
]. In the current implementation, the first stage involves preparation of atomic workflows by the workflow developer. This includes defining the workflow graph, implementation of a concrete workflow with the defined workflow graph and building a template based on this implementation. This is followed by creation of an implementation for the concrete sub-workflow using the template. The creation of meta-workflow includes importing these sub-workflows shared via SHIWA Repository and configuring the required parameters such as the DCI where the workflow is intended to be processed, the executable and the data to be processed by the workflow.</p>
</sec>
<sec id="Sec10">
<title>Quantum chemistry simulations</title>
<p>Quantum chemistry (QC) simulations deal with the electronic structure of molecules. An important task in quantum chemistry is the evaluation of the accuracy in describing specific molecular structures. Hence, lots of efforts are made in bench-marking studies with variation of functional and basis set in combination with solvent models and empirical dispersion correction. The job definition is always quite similar representing an ideal basis for the use of workflows. In a rather simple workflow, a given geometry can be calculated with a set of functionals and basis sets. The key geometric parameters are parsed and collected in tables afterwards, enabling direct comparison of the accuracy of the used methods. Another use case would be the study of a complex potential hypersurface by varying one or several geometric parameters. Then, a set of similar jobs has to be submitted to DCIs with the same functional and basis set but varying coordinates. Both types of workflows are independent of the quantum chemical code. Further post-processing can cover the addition of a solvent model, calculation of charges and frequencies, formatting of checkpoint files and definition of new job files for subsequent time-dependent DFT calculations. Quantum Chemistry workflows were primarily implemented in MoSGrid for Gaussian [
<xref ref-type="bibr" rid="CR41">41</xref>
] and NWChem [
<xref ref-type="bibr" rid="CR42">42</xref>
]. Both codes are used by novice and experienced users. Aiming at novice users, MoSGrid provides tutorials in the QC portlet on how to construct and submit a job and basic workflows are ready to use [
<xref ref-type="bibr" rid="CR18">18</xref>
]. For experienced users, more complex workflows are available or can be assembled by themselves via the workflow portlet.</p>
</sec>
<sec id="Sec11">
<title>Atomic operations versus atomic workflows in computational chemistry</title>
<p>Input is mostly the experimental structure obtained from single crystal X-ray diffraction analysis. The most fundamental step of every QC calculation is the geometry optimization where a converged wave function is calculated and the atomic positions are varied until all forces in the system come to a minimum. Afterwards, the frequency calculation checks whether a geometry represents a true minimum and delivers infrared frequencies of the compound. When dealing with systems containing metals, a very good accordance with the experimental structure is achieved when only 0.01 Å deviation in the chemical bond lengths is found. In many cases, the experimental optical properties of a given molecule must be compared to and explained by theoretical analysis. This is performed by time-dependent DFT calculations (TD-DFT) where the response of the wave function of the compound to an external periodic field (e.g. light) is simulated. More information about the electronic structure can be obtained by population analyses and charge calculations, e.g. by using natural bond orbitals (NBO) analysis [
<xref ref-type="bibr" rid="CR43">43</xref>
]. These types of analyses allow to dissect the electron distribution and assign it to atoms in order to obtain partial charges, charge-transfer energies, hybridisation of atoms etc.</p>
<p>Previously, in QC, the calculation in gas phase was standard but today, to obtain a realistic description, solvent models are commonly applied. In explicit models, the single solvent molecules are modelled which leads to enormous computational effort as the number of particles in the simulation system increases exponentially. In implicit models, the solvents are simplified by their radius and their dielectric constant describing the continuum around the molecule of interest. The different approaches represent the compromise between best accuracy (explicit models) and highest speed (implicit models). Hence, every solvent has a specific set of parameters. Special attention has to be paid to the solvent description when changing the QC code or even only the version of the used code, as the implementations of solvent models vary. At the next level, dispersive interactions between molecules and parts of molecules must be described correctly. Dispersive interactions (London forces) are rather weak but they can change the relative energies between conformers since attractive forces between unipolar parts of molecules can affect the position of substituents. The dispersion model after Grimme adds pairwise interaction energies (DFT-D) to model possible contacts [
<xref ref-type="bibr" rid="CR44">44</xref>
,
<xref ref-type="bibr" rid="CR45">45</xref>
]. It is highly important to understand the influences of different solvent and dispersion models on the structures, frequencies and energies of transition metal complexes because an accurateness of <0.1 kcal/mol is needed for a reasonable reaction mechanism prediction. Both enhancements can be added to all types of calculations described above.</p>
<p>Hence, candidates for atomic workflows are the following ones:
<list list-type="bullet">
<list-item>
<p>geometry optimization</p>
</list-item>
<list-item>
<p>frequency analysis</p>
</list-item>
<list-item>
<p>time-dependent calculation</p>
</list-item>
<list-item>
<p>population analysis</p>
</list-item>
<list-item>
<p>charge calculation</p>
</list-item>
</list>
</p>
</sec>
<sec id="Sec12">
<title>Quantum chemistry workflows</title>
<p>To evaluate how to use the atomic and meta-workflow concept in Quantum Chemistry, we identified several use cases. In this section, we present some of them in order to provide useful examples considering the current trends in Quantum Chemistry. Whenever similar job types of different molecules or different job types for the same molecule are to be submitted, a workflow can be an efficient and practical solution.</p>
</sec>
<sec id="Sec13">
<title>Spectroscopic analysis</title>
<p>In this context, a highly interesting use case is the so-called spectroscopic analysis (Fig. 
<xref rid="Fig6" ref-type="fig">6</xref>
). After a first geometry optimization of the selected molecule several further simulations such as frequency analysis, time dependent calculation, population analysis and solvent analysis are performed using the optimized coordinates. These simulations can be further divided into smaller tasks, such as the input file generation by a so-called
<italic>job generator</italic>
, then the job submission to the DCI and the calculation by the QC code, which produces the corresponding output. Input and output files are graphically represented by rhombs whereas jobs are rounded boxes.
<fig id="Fig6">
<label>Fig. 6</label>
<caption>
<p>Spectroscopic analysis
<italic>Spec_Analy M</italic>
-
<italic>WF</italic>
meta-workflow (
<italic>top left</italic>
molecular structure, bottom from
<italic>left</italic>
to
<italic>right</italic>
: Raman spectrum, UV/Vis spectrum, lowest unoccupied orbital)</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig6_HTML" id="MO16"></graphic>
</fig>
</p>
<p>To create a spectroscopic analysis meta-workflow (
<italic>Spec_Analy M</italic>
-
<italic>WF</italic>
) first, we defined the structure of the meta-workflow. Next, we identified the atomic workflows i.e. small operations or tasks that can be re-used in other meta-workflows. The first atomic workflow (
<italic>Opt WF</italic>
) runs a simple geometry optimization. The subsequent atomic workflows have a similar structure but they provide different functionalities. They contain a converter script that extracts the output geometry from the optimization output and combines it with blank input files (i.e. just lacking input coordinates) with the corresponding keywords for frequency calculations (
<italic>Freq WF</italic>
), time-dependent DFT calculations giving UV/Vis spectra (
<italic>TD WF</italic>
), population analyses (
<italic>Pop WF</italic>
) and subsequent calculations in solvents (
<italic>Solv WF</italic>
). All these atomic workflows, shown in Fig. 
<xref rid="Fig4" ref-type="fig">6</xref>
are highly valuable since they can be re-used in other QC meta-workflows.</p>
<p>With regard to a real-life system as depicted in Fig. 
<xref rid="Fig6" ref-type="fig">6</xref>
, the spectroscopic analysis has to tackle issues such as antiferromagnetic coupling between copper atoms, correct description of the coordination sphere and multiple conformations of the whole molecule. [
<xref ref-type="bibr" rid="CR46">46</xref>
,
<xref ref-type="bibr" rid="CR47">47</xref>
] Methodologically, density functional theory is most appropriate here due to size of the system and investigated questions.</p>
<p>Hence, the spectroscopic analysis meta-workflow needs to be performed several times for an array of functionals and basis sets which have to be tested for the ultimate structural and optical description with respect to experimental data. Now, this meta-workflow can be combined into a spectroscopic benchmarking meta
<sup>2</sup>
-workflow (
<italic>Spec</italic>
-
<italic>Bench M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
). Figure 
<xref rid="Fig7" ref-type="fig">7</xref>
shows four spectroscopic analysis meta-workflows which are combined after performing a basic optimization. This basic optimization atomic workflow (
<italic>Basic Opt WF</italic>
) runs a pre-optimization step, which saves calculation time in all subsequent optimizations included in the spectroscopic workflows (Spec1 WF…Spec4WF). The
<italic>Basic Opt WF</italic>
can for example use a smaller basis set. Here, the
<italic>Opt WF</italic>
from Fig. 
<xref rid="Fig6" ref-type="fig">6</xref>
can be re-used. The
<italic>Spec</italic>
-
<italic>Bench M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
saves a lot of time in this application.
<fig id="Fig7">
<label>Fig. 7</label>
<caption>
<p>
<italic>Spec_Bench M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
spectroscopic benchmarking meta-workflow</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig7_HTML" id="MO17"></graphic>
</fig>
</p>
<p>After execution of the spectroscopic benchmarking meta-workflow, the user collects and analyses the data. These steps should still be performed manually since the outputs are rather diverse. But the largest benefit of using meta-workflows is that it decreases the overall workload of defining all input job files, extracting geometry data after the pre-optimization step and others, as a result it saves a lot of the researchers´ time.</p>
</sec>
<sec id="Sec14">
<title>Optical benchmarking</title>
<p>The TD-DFT calculations can be highly dependent on the selection of the functional. Hence, an optical benchmarking may be needed to investigate the influence of the functional on the prediction of the optical transitions. Charge-transfer transitions are very sensitive towards the choice of the functional [
<xref ref-type="bibr" rid="CR48">48</xref>
<xref ref-type="bibr" rid="CR52">52</xref>
] and the results can largely deviate from the experimental spectrum. Hence, for a new transition metal system, one always needs to perform a so-called optical benchmarking and find a suited functional to describe measured spectra correctly. After optimizing the structure, different functionals, such as GGAs, meta-GGAs, hybrid-GGAs can be used to evaluate the functional dependency of the optical transitions (Fig. 
<xref rid="Fig8" ref-type="fig">8</xref>
). In detail, this might be B3LYP, PW91, TPSSh, PBE, to name just a few.
<fig id="Fig8">
<label>Fig. 8</label>
<caption>
<p>
<italic>Opt_Bench M</italic>
-
<italic>WF</italic>
optical benchmarking meta-workflow with five atomic workflows yielding theoretical UV/Vis spectra</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig8_HTML" id="MO18"></graphic>
</fig>
</p>
<p>Each TD calculation can be implemented as a separate atomic workflow. See atomic workflows in Fig. 
<xref rid="Fig8" ref-type="fig">8</xref>
:
<italic>TD</italic>
-
<italic>B3LYP WF, TD</italic>
-
<italic>PW91 WF, TD</italic>
-
<italic>TPSSh</italic>
-
<italic>WF, TD</italic>
-
<italic>PBE WF</italic>
. They run different time-dependent DFTs (TD-DFT). Having these atomic workflows and the
<italic>Opt WF</italic>
we have created the
<italic>Opt</italic>
-
<italic>Bench M</italic>
-
<italic>WF</italic>
meta-workflow. The strength of this concept lies in the re-usability of the TD atomic workflows which have been tested successfully and collected in the MoSGrid Repository. Moreover, for every step, metadata is annotated and stored facilitating the organization of the computational chemists work. In principle, this optical benchmarking meta-workflow can be conceptualized in a broader way when more functionals are required to describe a complicated electronic behaviour [
<xref ref-type="bibr" rid="CR48">48</xref>
<xref ref-type="bibr" rid="CR50">50</xref>
].</p>
</sec>
<sec id="Sec15">
<title>Structural benchmarking</title>
<p>Functionals also influence the structural details of molecules. Hence, a benchmarking for the structural influence (Fig. 
<xref rid="Fig9" ref-type="fig">9</xref>
) can include variation of the functional and of the basis set. To perform this benchmarking we can create a meta-workflow (
<italic>Geo_Opt M</italic>
-
<italic>WF</italic>
) with different types of optimization runs. The basis set is indicated by “2z” and “3z” which denotes the quality of the basis set. Larger basis sets give better agreement with experimental structural information but the calculation time can increase to such an extent that the calculation might no longer be feasible when dealing with molecules of more than 200 atoms. To run structural benchmarking a combination of a particular function and the quality of the basis set can be implemented as atomic workflows, for example:
<italic>B3LYP</italic>
-
<italic>2 WF, B3LYP</italic>
-
<italic>3 WF, TPSSh</italic>
-
<italic>2 WF, TPSSh</italic>
-
<italic>3 WF</italic>
, etc. (See in Fig. 
<xref rid="Fig9" ref-type="fig">9</xref>
).
<fig id="Fig9">
<label>Fig. 9</label>
<caption>
<p>
<italic>Geo_Opt M</italic>
-
<italic>WF</italic>
small structural benchmarking meta-workflow</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig9_HTML" id="MO19"></graphic>
</fig>
</p>
<p>Further, this meta-workflow can easily be extended with post-optimization steps using dispersion correction or solvent models (Fig. 
<xref rid="Fig10" ref-type="fig">10</xref>
) in a meta
<sup>2</sup>
-workflow (
<italic>Struc_Bench M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
). These steps can be implemented by B3LYP and TPSSh atomic workflows that run the dispersion corrections and solvent models.
<fig id="Fig10">
<label>Fig. 10</label>
<caption>
<p>
<italic>Struc_Bench M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
structural benchmarking meta
<sup>2</sup>
-workflow using dispersion and solvent models</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig10_HTML" id="MO20"></graphic>
</fig>
</p>
<p>Taking into account, that the chemist finally needs the frequencies of desired molecules, frequency and optimization tasks should be combined together with the options of dispersion and solvent models. Right in Fig. 
<xref rid="Fig11" ref-type="fig">11</xref>
there is a three-layer meta-workflow (
<italic>Freq_Disp_Opt M</italic>
-
<italic>WF</italic>
) that incorporates four atomic workflows. First, the geometry of the selected molecule is optimized by the
<italic>Opt WF</italic>
atomic workflow. Next, two atomic workflows are executed in parallel calculating the vibrational properties of the molecule by the
<italic>Freq WF</italic>
atomic workflow and the optimized molecule is re-optimized using dispersion by the
<italic>OptDisp WF</italic>
atomic workflow. Finally, the corresponding frequencies of the re-optimized molecule are calculated by the
<italic>FreqDisp WF</italic>
atomic workflow.
<fig id="Fig11">
<label>Fig. 11</label>
<caption>
<p>Left:
<italic>Struc_Opt M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
meta
<sup>2</sup>
-workflow for frequency optimization in dispersion and solvent, right:
<italic>Freq_Disp_Opt M</italic>
-
<italic>WF</italic>
meta-workflow for frequency optimization in dispersion</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig11_HTML" id="MO21"></graphic>
</fig>
</p>
<p>The
<italic>Freq_Disp_Opt M</italic>
-
<italic>WF</italic>
meta-workflow runs a simulation in gas phase. It can be combined with the
<italic>Freq_Solv Opt M</italic>
-
<italic>WF</italic>
meta-workflow to run a simulation in a common solvent as polarizable continuum model into a meta
<sup>2</sup>
-workflow. The
<italic>Struc_Opt M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
meta workflow saves a lot of time of manual job definition and result analysis, easily up to a factor of 10 in terms of the researchers working time.</p>
</sec>
<sec id="Sec16">
<title>Inorganic polymerization catalysis</title>
<p>Since QC is applied in all fields of chemistry, we searched for a use case from catalysis in order to demonstrate the wide applicability of the concept. In modern controlled polymerization techniques such as atom transfer radical polymerization (ATRP) [
<xref ref-type="bibr" rid="CR53">53</xref>
], the control over redox properties is crucial for the polymerization control. In this use case, we are interested in the relative ratio of an equilibrium between different copper guanidine complexes which can interchange electrons and halide atoms. Hence, we have two slightly differing ligands, TMGqu and DMEGqu [
<xref ref-type="bibr" rid="CR54">54</xref>
], which stabilise copper(I) and copper(II) complexes. As equilibrium with the equilibrium constant K
<sub>iso</sub>
, we can write the atom transfer reaction as described in Fig. 
<xref rid="Fig12" ref-type="fig">12</xref>
. We start with experimental structures of the four complexes. So, the whole equilibrium workflow is performed for each structure.
<fig id="Fig12">
<label>Fig. 12</label>
<caption>
<p>Equilibrium between copper(I) and (II) complexes with guanidine–quinoline ligands and the structures of these complexes</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig12_HTML" id="MO22"></graphic>
</fig>
</p>
<p>To describe the equilibrium we developed the
<italic>Equil_Calc WF</italic>
meta-workflow with a three-layer structure as depicted in Fig. 
<xref rid="Fig13" ref-type="fig">13</xref>
. There are three atomic workflows to run the QC code at the bottom layer (or first layer). The
<italic>Opt WF</italic>
atomic workflow processes the
<italic>input file</italic>
(of the experimental structure) produced by the
<italic>Job Creator</italic>
from the experimental structure and generates an optimization input file within this atomic workflow. The optimized structure is parsed by the job creator of the
<italic>Freq</italic>
-
<italic>0</italic>
 
<italic>K WF</italic>
and
<italic>Freq</italic>
-
<italic>400</italic>
 
<italic>K WF</italic>
atomic workflow to create two parallel frequency files (Fig. 
<xref rid="Fig13" ref-type="fig">13</xref>
). Normally, the standard frequency calculations are performed at 0 K but in this equilibrium case, experimental conditions at 400 K shall be considered as well. These two atomic workflows run in parallel. This meta-workflow represents the second layer of the simulation.
<fig id="Fig13">
<label>Fig. 13</label>
<caption>
<p>
<italic>Equil_Calc M</italic>
-
<italic>WF</italic>
meta-workflow with three atomic workflows</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig13_HTML" id="MO23"></graphic>
</fig>
</p>
<p>As this type of calculations has to be performed in different solvents (acetonitrile = MeCN and xylene) as well as with and without dispersion, the meta-workflow has to be performed four times in parallel inside the
<italic>Equil_Solv_M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
meta workflow given in Fig. 
<xref rid="Fig14" ref-type="fig">14</xref>
. This meta-workflow represents the third layer of the simulation incorporating the
<italic>Opt plus 2freq M</italic>
-
<italic>WF</italic>
meta-workflows. The result of this meta-workflow is a table containing the energies, enthalpies and free energies parsed out of the result files of the eight frequency jobs, since every single meta-workflow produces two frequency output files. This table contains basically the results for one complex.
<fig id="Fig14">
<label>Fig. 14</label>
<caption>
<p>
<italic>Equil_Solv M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
meta
<sup>2</sup>
workflow</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig14_HTML" id="MO24"></graphic>
</fig>
</p>
<p>After completing the
<italic>Equil_Solv M</italic>
<sup>
<italic>2</italic>
</sup>
-
<italic>WF</italic>
meta
<sup>2</sup>
-workflow the user can summarize the resulting tables and calculate the relative energies yielding the desired K
<sub>iso</sub>
value. This could be included into
<italic>the Equi_Energ M</italic>
<sup>
<italic>3</italic>
</sup>
-
<italic>WF</italic>
meta-workflow at the fourth workflow layer (Fig. 
<xref rid="Fig15" ref-type="fig">15</xref>
). In principle, one should also evaluate the functional influence because different density functionals treat electron correlation differently yielding different results here. This would even add a fifth layer.</p>
<p>In the daily chemical computational work, we have found that every layer adds efficiency with a factor of around 2–3 as time-consuming job definition, structure extraction and data collection are considerably facilitated. This factor can be calculated by the following example: the manual definition of one job takes 3 min. So, the embedded workflow in Fig. 
<xref rid="Fig13" ref-type="fig">13</xref>
would need 9 min and the meta-workflow in Fig. 
<xref rid="Fig14" ref-type="fig">14</xref>
four times more, 36 min. The highest level WF would then add up to 144 min of job definition time in manual mode. The data extraction time can be assumed to the same amount; hence, we end up with approximately 280 min for one run of the jobs summarized in Fig. 
<xref rid="Fig15" ref-type="fig">15</xref>
. In fact, the corresponding workflow needs to be defined and tested, but since the embedded workflows are very similar the meta-workflow system saves time, such that the whole workflow definition needs 3–4 h. But then, it can be performed several times and re-used in itself or by its building blocks. Thereby, we estimate the efficiency factor to 2–3.
<fig id="Fig15">
<label>Fig. 15</label>
<caption>
<p>
<italic>Equil_Energ M</italic>
<sup>
<italic>3</italic>
</sup>
-
<italic>WF</italic>
meta
<sup>3</sup>
workflow defined for each complex and analysed into a single table</p>
</caption>
<graphic xlink:href="13321_2016_169_Fig15_HTML" id="MO25"></graphic>
</fig>
</p>
</sec>
<sec id="Sec17">
<title>Workflow libraries in quantum chemistry simulations</title>
<p>In the ER-flow project [
<xref ref-type="bibr" rid="CR40">40</xref>
] the Computational Chemistry community developed 26 atomic workflows and 12 meta-workflows, presented in Additional file
<xref rid="MOESM1" ref-type="media">1</xref>
: Table S1–S6, to run optical and structural benchmarking, spectroscopic simulations and investigations on inorganic polymerization catalysts experiments. Considering these workflows we created the Quantum Chemistry workflow library with five sub-libraries (Table 
<xref rid="Tab2" ref-type="table">2</xref>
).
<table-wrap id="Tab2">
<label>Table 2</label>
<caption>
<p>Structure of the quantum chemistry workflow library</p>
</caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left">Workflow library</th>
<th align="left">Sub-libraries</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">DOMAIN—quantum chemistry</td>
<td align="left">SUB-DOMAIN
<sub>1</sub>
—basic operations</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">SUB-DOMAIN
<sub>2</sub>
—spectroscopic analysis</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">SUB-DOMAIN
<sub>3</sub>
—optical benchmarking</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">SUB-DOMAIN
<sub>4</sub>
—structural benchmarking</td>
</tr>
<tr>
<td align="left"></td>
<td align="left">SUB-DOMAIN
<sub>5</sub>
—inorganic polymerization catalysis</td>
</tr>
</tbody>
</table>
</table-wrap>
</p>
<p>Table 
<xref rid="Tab3" ref-type="table">3</xref>
presents the basic operations sub-library. It contains the atomic workflows that implement basic Quantum Chemistry operations and can be used in scientific experiments of different sub-domains in QC. These atomic workflows are highlighted in bold in Additional file
<xref rid="MOESM1" ref-type="media">1</xref>
: Table S1–S6. For example the
<italic>Opt WF</italic>
atomic workflows is incorporated in the
<italic>Spect_Analy M</italic>
-
<italic>WF, Opt_Bench M</italic>
-
<italic>WF, Freq_Opt M_WF</italic>
and
<italic>Equil_Calc M</italic>
-
<italic>WF</italic>
meta-workflow, while the
<italic>Freq WF</italic>
atomic workflow in the
<italic>Spec_Analy</italic>
_ and
<italic>Freq_Opt M</italic>
-
<italic>WF</italic>
meta-workflow.
<table-wrap id="Tab3">
<label>Table 3</label>
<caption>
<p>Atomic workflows of the basic operations sub-library</p>
</caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left">Atomic workflows</th>
<th align="left">Functionality</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Opt WF</td>
<td align="left">Geometry optimization</td>
</tr>
<tr>
<td align="left">Basic Opt WF</td>
<td align="left">Geometry optimization with small basis set</td>
</tr>
<tr>
<td align="left">Freq WF</td>
<td align="left">Frequency calculation</td>
</tr>
<tr>
<td align="left">TD WF</td>
<td align="left">Time-dependent DFT calculation</td>
</tr>
<tr>
<td align="left">Pop WF</td>
<td align="left">Population analysis</td>
</tr>
<tr>
<td align="left">Solv WF</td>
<td align="left">Optimization in solvent</td>
</tr>
</tbody>
</table>
</table-wrap>
</p>
<p>The other four sub-libraries contain atomic workflows that deliver operations specific to a particular Quantum Chemistry sub-domain, for example optical benchmarking, structural benchmarking, etc. These atomic workflows are listed in Additional file
<xref rid="MOESM1" ref-type="media">1</xref>
: Table S1–S6.</p>
</sec>
</sec>
<sec id="Sec18">
<title>Conclusions and further works</title>
<p>Herein, we have shown that re-occurring tasks in Quantum Chemistry scientific experiments can be facilitated by re-using and sharing workflows. We introduce and formally describe the concept of the atomic workflow. Atomic workflows represent basic operations for example optimization, frequency calculation, population analysis, etc. in Quantum Chemistry. Since these operations are performed in multiple scientific experiments they can be shared among these experiments. We also propose to build workflow libraries that manage and publish atomic workflows. Workflow libraries are domain specific, i.e. each scientific domain may have its own workflow library with several sub-domains. Having atomic workflows researchers can combine them into complex workflows called meta-workflows. We propose to use atomic workflows as building blocks for complex meta
<sup>n</sup>
-workflows. We extend the existing formal description of meta-workflows to support sharing atomic workflows incorporating them into meta-workflows. The Quantum Chemistry uses among others the WS-PGRADE workflow systems to create workflows and run scientific workflows through science gateways such as the MoSGrid Portal and the SHIWA Portal. We developed and formalized a template based approach to create WS-PGRADE meta-workflows to incorporate atomic workflows. Chemists, who become acquainted to workflows, can apply this technology to scientific problems. The work of dissecting a chemical theoretical problem into basic operations and defining the relevant atomic workflows is illustrated by spectroscopic analysis, optical and structural benchmarking and inorganic polymerization catalysis analysis workflows. We have created and uploaded 26 atomic workflows into the Quantum Chemistry workflow library that contains five sub-domains. We incorporated these atomic workflows into 12 meta-workflows. Considering developing atomic workflows and incorporating them into meta-workflows we can conclude that the re-use of the atomic workflows significantly decreases the efforts and time needed for creating scientific experiments. As a result, it makes the research more efficient. In future work, we plan to apply this concept to more complex scientific experiments where input preparation and output parsing is more involved</p>
</sec>
<sec id="Sec19">
<title>Supporting Information</title>
<p>The Supporting Information contains details on the atomic and meta-workflows. </p>
</sec>
</body>
<back>
<app-group>
<app id="App1">
<sec id="Sec20">
<title>Additional file</title>
<p>
<media position="anchor" xlink:href="13321_2016_169_MOESM1_ESM.pdf" id="MOESM1">
<caption>
<p>
<bold>Additional file 1.</bold>
The supporting information contains details on the atomic and meta-workflows.</p>
</caption>
</media>
</p>
</sec>
</app>
</app-group>
<ack>
<title>Authors’ contributions</title>
<p>JA, TK and GT studied the abstract WS-PGRADE workflows. AH and SH-P described and implemented the chemical use-cases and RG, SG, GT and JK helped them to realise them as concrete meta-workflows. All authors read and approved the final manuscript.</p>
<sec id="FPar1">
<title>Acknowledgements</title>
<p>The authors would like to thank the BMBF (German Federal Ministry of Education and Research) for the opportunity to do research in the MoSGrid project (Reference 01IG09006). Furthermore, financial support by the Deutsche Forschungsgemeinschaft for FOR1405 and MASi (NA711/9-1) is gratefully acknowledged. The research leading to these results has partially been supported by the European Commission’s Seventh Framework Programme (FP7/2007-2013) under Grant agreement no 283481 (SCI-BUS) and no 312579 (ER-flow) and by the LSDMA project of the Helmholtz Association of German Research Centres. Special thanks are due to NGI-DE for managing the German Grid infrastructure. Furthermore, the authors would like to thank for the support by the XSEDE/PRACE Extended Collaborative Support projects (XSEDE is supported by National Science Foundation Grant Number ACI-1053575, PRACE is supported by the EU Grant Numbers RI-261557, RI-283493 and RI-312763).</p>
<p>Dedicated to Prof. Antonio Lagana on the occasion of his 70th birthday.</p>
</sec>
<sec id="FPar2">
<title>Competing interests</title>
<p>The authors declare that they have no competing interests.</p>
</sec>
</ack>
<ref-list id="Bib1">
<title>References</title>
<ref id="CR1">
<label>1.</label>
<mixed-citation publication-type="other">Herres-Pawlis S, Hoffmann A, Gesing S, Krüger J, Balasko A, Kacsuk P, Grunzke R, Birkenheuer G, Packschies L (2013) User-friendly workflows in quantum chemistry. In: Proceedings of CEUR workshop, vol 993, p 14</mixed-citation>
</ref>
<ref id="CR2">
<label>2.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Castelli</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Taffoni</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Sciacca</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Becciani</surname>
<given-names>U</given-names>
</name>
<name>
<surname>Costa</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Krokos</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Pasian</surname>
<given-names>F</given-names>
</name>
<name>
<surname>Vuerli</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>VO-compliant workflows and science gateways</article-title>
<source>Astron Comput</source>
<year>2015</year>
<volume>11</volume>
<fpage>102</fpage>
<lpage>108</lpage>
<pub-id pub-id-type="doi">10.1016/j.ascom.2015.02.006</pub-id>
</element-citation>
</ref>
<ref id="CR3">
<label>3.</label>
<mixed-citation publication-type="other">Pierantoni G, Carley E (2014) Metaworkflows and workflow interoperability for heliophysics. In: The proceedings of the 6th international workshop on science gateways, pp 79–84</mixed-citation>
</ref>
<ref id="CR4">
<label>4.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Korkhov</surname>
<given-names>V</given-names>
</name>
<name>
<surname>Krefting</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Motagnat</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Olabarriaga</surname>
<given-names>SD</given-names>
</name>
</person-group>
<article-title>SHIWA workflow interoperability solutions for neuroimaging data analysis</article-title>
<source>Stud Health Technol and Inf</source>
<year>2012</year>
<volume>175</volume>
<fpage>109</fpage>
<lpage>110</lpage>
</element-citation>
</ref>
<ref id="CR5">
<label>5.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kacsuk</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Terstyanszky</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Balasko</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Karoczkai</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Farkas</surname>
<given-names>Z</given-names>
</name>
</person-group>
<article-title>Executing multi-workflow simulations on a mixed grid/cloud infrastructure using the SHIWA and SCI-BUS technology</article-title>
<source>Cloud Comput Big Data</source>
<year>2013</year>
<volume>141</volume>
<fpage>141</fpage>
<lpage>160</lpage>
</element-citation>
</ref>
<ref id="CR6">
<label>6.</label>
<element-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Taylor</surname>
<given-names>IJ</given-names>
</name>
<name>
<surname>Deelman</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Gannon</surname>
<given-names>DB</given-names>
</name>
<name>
<surname>Sheilds</surname>
<given-names>M</given-names>
</name>
</person-group>
<source>Workflows for e-Science: scientific workflows for grids</source>
<year>2014</year>
<publisher-loc>New York</publisher-loc>
<publisher-name>Springer</publisher-name>
</element-citation>
</ref>
<ref id="CR7">
<label>7.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Abouelhoda</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Issa</surname>
<given-names>SA</given-names>
</name>
<name>
<surname>Ghanem</surname>
<given-names>M</given-names>
</name>
</person-group>
<article-title>Tavaxy: integrating taverna and galaxy workflows with cloud computing support</article-title>
<source>BMC Bioinform</source>
<year>2012</year>
<volume>4</volume>
<issue>13</issue>
<fpage>77</fpage>
<pub-id pub-id-type="doi">10.1186/1471-2105-13-77</pub-id>
</element-citation>
</ref>
<ref id="CR8">
<label>8.</label>
<mixed-citation publication-type="other">Korkhov V, Krefting D, Kukla T, Terstyanszky G, Caan M, Olabarriaga SD (2011) Exploring workflow interoperability tools for neuroimaging data analysis. In: The Proceedings of the 6th workshop on the workflows in support of large-scale science, Seattle, U.S., pp 87–96</mixed-citation>
</ref>
<ref id="CR9">
<label>9.</label>
<mixed-citation publication-type="other">Kranjc J, Podpecan V, Lavrac N (2012) Clowdflows: a cloud based scientific workflow platform. In: Flach PA, Bie TD, Cristianini N (eds) ECML/PKDD (2), series lecture notes in computer science, vol 7524, pp 816–819. Springer, New York</mixed-citation>
</ref>
<ref id="CR10">
<label>10.</label>
<mixed-citation publication-type="other">Turi D, Missier P, Goble C, De Roure D, Oinn T (2007) Taverna workflows: syntax and semantics. In: Third IEEE international conference on e-science and grid computing, 2007, pp 441–448</mixed-citation>
</ref>
<ref id="CR11">
<label>11.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Garijo</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Alper</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Belhajjame</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Corcho</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Gil</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Goble</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>Common motifs in scientific workflows: an empirical analysis</article-title>
<source>Future Gener Comput Sys</source>
<year>2014</year>
<volume>36</volume>
<fpage>338</fpage>
<lpage>351</lpage>
<pub-id pub-id-type="doi">10.1016/j.future.2013.09.018</pub-id>
</element-citation>
</ref>
<ref id="CR12">
<label>12.</label>
<mixed-citation publication-type="other">SHIWA SHaring Interoperable Workflows for Large-scale Scientific Simulations. Available DCIs.
<ext-link ext-link-type="uri" xlink:href="http://www.shiwa-workflow.eu/project">http://www.shiwa-workflow.eu/project</ext-link>
. 29th December 2015</mixed-citation>
</ref>
<ref id="CR13">
<label>13.</label>
<mixed-citation publication-type="other">Kranjc J, Podpecan V, Lavrac N (2013) Real-time data analysis in ClowdFlows. In The proceedings of the 2013 international conference on big data, Silicon Valley, CA, pp 15–22</mixed-citation>
</ref>
<ref id="CR14">
<label>14.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>De Roure</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Goble</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Stevens</surname>
<given-names>R</given-names>
</name>
</person-group>
<article-title>The design and realisation of the myexperiment virtual research environment for social sharing of workflows</article-title>
<source>Future Generation Comput Syst</source>
<year>2008</year>
<volume>25</volume>
<fpage>561</fpage>
<lpage>567</lpage>
<pub-id pub-id-type="doi">10.1016/j.future.2008.06.010</pub-id>
</element-citation>
</ref>
<ref id="CR15">
<label>15.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hildebrandt</surname>
<given-names>AK</given-names>
</name>
<name>
<surname>Stöckel</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Fischer</surname>
<given-names>NM</given-names>
</name>
<name>
<surname>de la Garza</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Krüger</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Nickels</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Röttig</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Schärfe</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Schumann</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Thiel</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Lenhof</surname>
<given-names>HP</given-names>
</name>
<name>
<surname>Kohlbacher</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Hildebrandt</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>Ballaxy: web services for structural bioinformatics</article-title>
<source>Bioinformatics</source>
<year>2014</year>
</element-citation>
</ref>
<ref id="CR16">
<label>16.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Niehörster</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Brinkmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Keller</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Kleineweber</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Krüger</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Simon</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Cost-aware and SLO-fulfilling software as a service</article-title>
<source>J Grid Comput</source>
<year>2012</year>
<volume>10</volume>
<issue>3</issue>
<fpage>553</fpage>
<lpage>577</lpage>
<pub-id pub-id-type="doi">10.1007/s10723-012-9230-7</pub-id>
</element-citation>
</ref>
<ref id="CR17">
<label>17.</label>
<mixed-citation publication-type="other">Niehörster O, Brinkmann A, Fels G, Krüger J, Simon J (2010) Enforcing SLAs in scientific clouds. In: The proceedings of the 12th IEEE international conference on cluster computing (Cluster2010), Heraklion, 2010</mixed-citation>
</ref>
<ref id="CR18">
<label>18.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Krüger</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Grunzke</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Gesing</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Breuers</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Brinkmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>de la Garza</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Kohlbacher</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Kruse</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Nagel</surname>
<given-names>WE</given-names>
</name>
<name>
<surname>Packschies</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Müller-Pfefferkorn</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Schäfer</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Schärfe</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Steinke</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Schlemmer</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Warzecha</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Zink</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>The MoSGrid science gateway—a complete solution for molecular simulations</article-title>
<source>J Chem Theory Comput</source>
<year>2014</year>
<volume>10</volume>
<issue>6</issue>
<fpage>2232</fpage>
<lpage>2245</lpage>
<pub-id pub-id-type="doi">10.1021/ct500159h</pub-id>
<pub-id pub-id-type="pmid">26580747</pub-id>
</element-citation>
</ref>
<ref id="CR19">
<label>19.</label>
<element-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Kertész</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Sipos</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Kacsuk</surname>
<given-names>P</given-names>
</name>
</person-group>
<person-group person-group-type="editor">
<name>
<surname>Lehner</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Meyer</surname>
<given-names>N</given-names>
</name>
<name>
<surname>Streit</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Stewart</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>Brokering multi-grid workflows in the P-GRADE portal</article-title>
<source>The proceedings of the Euro-Par 2006: parallel processing</source>
<year>2007</year>
<publisher-loc>Berlin</publisher-loc>
<publisher-name>Springer</publisher-name>
<fpage>138</fpage>
<lpage>149</lpage>
</element-citation>
</ref>
<ref id="CR20">
<label>20.</label>
<element-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Atkinson</surname>
<given-names>M</given-names>
</name>
</person-group>
<person-group person-group-type="editor">
<name>
<surname>Atkinson</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Baxter</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Brezany</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Corcho</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Galea</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Parsons</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Snelling</surname>
<given-names>D</given-names>
</name>
<name>
<surname>van Hemert</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Data-intensive thinking with DISPEL</article-title>
<source>The data bonanza: improving knowledge</source>
<year>2013</year>
<publisher-loc>New York</publisher-loc>
<publisher-name>Wiley</publisher-name>
<fpage>61</fpage>
<lpage>122</lpage>
</element-citation>
</ref>
<ref id="CR21">
<label>21.</label>
<element-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Blankenberg</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Kuster</surname>
<given-names>GV</given-names>
</name>
<name>
<surname>Coraor</surname>
<given-names>N</given-names>
</name>
<name>
<surname>Ananda</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Lazarus</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Mangan</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Nekrutenko</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Taylor</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Galaxy: a web-based genome analysis tool for experimentalists</article-title>
<source>Current protocols in molecular biology</source>
<year>2010</year>
<publisher-loc>New York</publisher-loc>
<publisher-name>Wiley</publisher-name>
</element-citation>
</ref>
<ref id="CR22">
<label>22.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Ludäscher</surname>
<given-names>B</given-names>
</name>
<name>
<surname>Altintas</surname>
<given-names>I</given-names>
</name>
<name>
<surname>Berkley</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Higgins</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Jaeger</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Jones</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Lee</surname>
<given-names>EA</given-names>
</name>
<name>
<surname>Tao</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Zhao</surname>
<given-names>Y</given-names>
</name>
</person-group>
<article-title>Scientific workflow management and the Kepler system</article-title>
<source>Proc Concurr Comput Pract Exp</source>
<year>2006</year>
<volume>18</volume>
<issue>10</issue>
<fpage>1039</fpage>
<lpage>1065</lpage>
<pub-id pub-id-type="doi">10.1002/cpe.994</pub-id>
</element-citation>
</ref>
<ref id="CR23">
<label>23.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Beisken</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Meinl</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Wiswedel</surname>
<given-names>B</given-names>
</name>
<name>
<surname>de Figueiredo</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Berthold</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Steinbeck</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>KNIME-CDK: workflow-driven cheminformatics</article-title>
<source>BMC Bioinform</source>
<year>2013</year>
<volume>14</volume>
<issue>1</issue>
<fpage>257</fpage>
<pub-id pub-id-type="doi">10.1186/1471-2105-14-257</pub-id>
</element-citation>
</ref>
<ref id="CR24">
<label>24.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Deelman</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Vahi</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Juve</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Rynge</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Callaghan</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Maechling</surname>
<given-names>PJ</given-names>
</name>
<name>
<surname>Mayani</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>W</given-names>
</name>
<name>
<surname>da Silva</surname>
<given-names>RF</given-names>
</name>
<name>
<surname>Livny</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Wenger</surname>
<given-names>K</given-names>
</name>
</person-group>
<article-title>Pegasus, a workflow management system for science automation</article-title>
<source>Future Gener Comput Syst</source>
<year>2015</year>
<volume>46</volume>
<fpage>17</fpage>
<lpage>35</lpage>
<pub-id pub-id-type="doi">10.1016/j.future.2014.10.008</pub-id>
</element-citation>
</ref>
<ref id="CR25">
<label>25.</label>
<mixed-citation publication-type="other">Wozniak J, Armstrong T, Wilde M, Katz D, Lusk E, Foster I (2013) Swift: large-scale application composition via distributed-memory dataflow processing. In: The proceedings of IEEE/ACM CCGRID’13, pp 95–102</mixed-citation>
</ref>
<ref id="CR26">
<label>26.</label>
<mixed-citation publication-type="other">Wolstencroft K, Haines R, Fellows D, Williams A, Withers D, Owen S, Soiland-Reyes S, Dunlop I, Nenadic A, Fisher P, Bhagat J, Belhajjame K, Bacall F, Hardisty A, Nieva de la Hidalga A, Balcazar Vargas AP, Sufi S, Goble C (2013) The Taverna workflow suite: designing and executing workflows of web services on the desktop, web or in the cloud. Nucleic Acids Res 41:W1, W557–W561</mixed-citation>
</ref>
<ref id="CR27">
<label>27.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kacsuk</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Farkas</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Kozlovszky</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Hermann</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Balasko</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Karoczkai</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Marton</surname>
<given-names>I</given-names>
</name>
</person-group>
<article-title>WS-PGRADE/gUSE generic DCI gateway framework for a large variety of user communities</article-title>
<source>J Grid Comput</source>
<year>2012</year>
<volume>10</volume>
<issue>4</issue>
<fpage>601</fpage>
<lpage>630</lpage>
<pub-id pub-id-type="doi">10.1007/s10723-012-9240-5</pub-id>
</element-citation>
</ref>
<ref id="CR28">
<label>28.</label>
<mixed-citation publication-type="other">Liferay, Enterprise Open Source Portal and Collaboration Software.
<ext-link ext-link-type="uri" xlink:href="http://www.liferay.com/">http://www.liferay.com/</ext-link>
. 29th December 2015</mixed-citation>
</ref>
<ref id="CR29">
<label>29.</label>
<mixed-citation publication-type="other">SCI-BUS Scientific Gateway Based User Support.
<ext-link ext-link-type="uri" xlink:href="http://www.sci-bus.eu/">http://www.sci-bus.eu/</ext-link>
. 29th December 2015</mixed-citation>
</ref>
<ref id="CR30">
<label>30.</label>
<mixed-citation publication-type="other">The MoSGrid Science Gateway available at:
<ext-link ext-link-type="uri" xlink:href="http://www.mosgrid.de">http://www.mosgrid.de</ext-link>
. 1st February 2016</mixed-citation>
</ref>
<ref id="CR31">
<label>31.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kiss</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Greenwell</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Heindl</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Terstyanszky</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Weingarten</surname>
<given-names>N</given-names>
</name>
</person-group>
<article-title>Parameter sweep workflows for modelling carbohydrate recognition</article-title>
<source>J Grid Comput</source>
<year>2010</year>
<volume>8</volume>
<issue>4</issue>
<fpage>587</fpage>
<lpage>601</lpage>
<pub-id pub-id-type="doi">10.1007/s10723-010-9166-8</pub-id>
</element-citation>
</ref>
<ref id="CR32">
<label>32.</label>
<mixed-citation publication-type="other">Jaghoori MM, Altena AJV, Bleijlevens B, Olabarriaga S (2014) A grid-enabled virtual screening gateway. In: The proceedings of the 6th international workshop on science gateways. 3–5 June 2014, Dublin</mixed-citation>
</ref>
<ref id="CR33">
<label>33.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Morris</surname>
<given-names>GM</given-names>
</name>
<name>
<surname>Goodsell</surname>
<given-names>DS</given-names>
</name>
<name>
<surname>Halliday</surname>
<given-names>RS</given-names>
</name>
<name>
<surname>Huey</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Hart</surname>
<given-names>WE</given-names>
</name>
<name>
<surname>Belew</surname>
<given-names>RK</given-names>
</name>
<name>
<surname>Olson</surname>
<given-names>AJ</given-names>
</name>
</person-group>
<article-title>Automated docking using a lamarckian genetic algorithm and empirical binding free energy function</article-title>
<source>J Comput Chem</source>
<year>1998</year>
<volume>19</volume>
<fpage>1639</fpage>
<lpage>1662</lpage>
<pub-id pub-id-type="doi">10.1002/(SICI)1096-987X(19981115)19:14<1639::AID-JCC10>3.0.CO;2-B</pub-id>
</element-citation>
</ref>
<ref id="CR34">
<label>34.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Trott</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Olson</surname>
<given-names>AJ</given-names>
</name>
</person-group>
<article-title>AutoDock Vina: improving the speed and accuracy of docking with a new scoring function, efficient optimization, and multithreading</article-title>
<source>J Comput Chem</source>
<year>2010</year>
<volume>31</volume>
<issue>2</issue>
<fpage>455</fpage>
<lpage>461</lpage>
<pub-id pub-id-type="pmid">19499576</pub-id>
</element-citation>
</ref>
<ref id="CR35">
<label>35.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Jacob</surname>
<given-names>CR</given-names>
</name>
<name>
<surname>Beyhan</surname>
<given-names>SM</given-names>
</name>
<name>
<surname>Bulo</surname>
<given-names>RE</given-names>
</name>
<name>
<surname>Pereira Gomes</surname>
<given-names>AS</given-names>
</name>
<name>
<surname>Götz</surname>
<given-names>AW</given-names>
</name>
<name>
<surname>Kiewisch</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Sikkema</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Visscher</surname>
<given-names>L</given-names>
</name>
</person-group>
<article-title>Software news and updates PyADF—a scripting framework for multiscale quantum chemistry</article-title>
<source>J Comput Chem</source>
<year>2011</year>
<volume>32</volume>
<fpage>2328</fpage>
<pub-id pub-id-type="doi">10.1002/jcc.21810</pub-id>
<pub-id pub-id-type="pmid">21541961</pub-id>
</element-citation>
</ref>
<ref id="CR36">
<label>36.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Waller</surname>
<given-names>MP</given-names>
</name>
<name>
<surname>Dresselhaus</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>JACOB: an enterprise framework for computational chemistry</article-title>
<source>J Comput Chem</source>
<year>2013</year>
<volume>34</volume>
<issue>16</issue>
<fpage>1420</fpage>
<pub-id pub-id-type="doi">10.1002/jcc.23272</pub-id>
<pub-id pub-id-type="pmid">23553271</pub-id>
</element-citation>
</ref>
<ref id="CR37">
<label>37.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Terstyanszky</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Kukla</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Kiss</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Kacsuk</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Balasko</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Farkas</surname>
<given-names>Z</given-names>
</name>
</person-group>
<article-title>Enabling scientific workflow sharing through coarse grained interoperability</article-title>
<source>Future Gener Comput Syst</source>
<year>2014</year>
<volume>37</volume>
<fpage>46</fpage>
<lpage>59</lpage>
<pub-id pub-id-type="doi">10.1016/j.future.2014.02.016</pub-id>
</element-citation>
</ref>
<ref id="CR38">
<label>38.</label>
<mixed-citation publication-type="other">Herres-Pawlis S, Hoffmann A, Grunzke R, Nagel WE, De La Garza L, Krüger J, Terstyansky G, Weingarten N, Gesing S (2014) Meta-metaworkflows for combining quantum chemistry and molecular dynamics in the MoSGrid science gateway. In: The 6th international workshop on science gateways, pp 73–78</mixed-citation>
</ref>
<ref id="CR39">
<label>39.</label>
<mixed-citation publication-type="other">Arshad J, Terstyanszky G, Tamas K, Weingarten N (2015) a definition and analysis of the role of meta-workflows in workflow interoperability. In: The proceedings of the 7th international workshop on science gateways, IWSG 2015, 03 June 2015 Budapest, Hungary</mixed-citation>
</ref>
<ref id="CR40">
<label>40.</label>
<mixed-citation publication-type="other">ER-flow, Building an European Research Community through Interoperable Workflows and Data.
<ext-link ext-link-type="uri" xlink:href="https://www.erflow.eu/">https://www.erflow.eu/</ext-link>
, 2015. 29th December 2015</mixed-citation>
</ref>
<ref id="CR41">
<label>41.</label>
<element-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Frisch</surname>
<given-names>MJ</given-names>
</name>
<name>
<surname>Trucks</surname>
<given-names>GW</given-names>
</name>
<name>
<surname>Schlegel</surname>
<given-names>HB</given-names>
</name>
<name>
<surname>Scuseria</surname>
<given-names>GE</given-names>
</name>
<name>
<surname>Robb</surname>
<given-names>MA</given-names>
</name>
<name>
<surname>Cheeseman</surname>
<given-names>JR</given-names>
</name>
<name>
<surname>Scalmani</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Barone</surname>
<given-names>V</given-names>
</name>
<name>
<surname>Mennucci</surname>
<given-names>B</given-names>
</name>
<name>
<surname>Petersson</surname>
<given-names>GA</given-names>
</name>
<name>
<surname>Nakatsuji</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Caricato</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>X</given-names>
</name>
<name>
<surname>Hratchian</surname>
<given-names>HP</given-names>
</name>
<name>
<surname>Izmaylov</surname>
<given-names>AF</given-names>
</name>
<name>
<surname>Bloino</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Zheng</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Sonnenberg</surname>
<given-names>JL</given-names>
</name>
<name>
<surname>Hada</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Ehara</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Toyota</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Fukuda</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Hasegawa</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Ishida</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Nakajima</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Honda</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Kitao</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Nakai</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Vreven</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Montgomery</surname>
<given-names>JA</given-names>
<suffix>Jr</suffix>
</name>
<name>
<surname>Peralta</surname>
<given-names>JE</given-names>
</name>
<name>
<surname>Ogliaro</surname>
<given-names>F</given-names>
</name>
<name>
<surname>Bearpark</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Heyd</surname>
<given-names>JJ</given-names>
</name>
<name>
<surname>Brothers</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Kudin</surname>
<given-names>KN</given-names>
</name>
<name>
<surname>Staroverov</surname>
<given-names>VN</given-names>
</name>
<name>
<surname>Kobayashi</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Normand</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Raghavachari</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Rendell</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Burant</surname>
<given-names>JC</given-names>
</name>
<name>
<surname>Iyengar</surname>
<given-names>SS</given-names>
</name>
<name>
<surname>Tomasi</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Cossi</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Rega</surname>
<given-names>N</given-names>
</name>
<name>
<surname>Millam</surname>
<given-names>JM</given-names>
</name>
<name>
<surname>Klene</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Knox</surname>
<given-names>JE</given-names>
</name>
<name>
<surname>Cross</surname>
<given-names>JB</given-names>
</name>
<name>
<surname>Bakken</surname>
<given-names>V</given-names>
</name>
<name>
<surname>Adamo</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Jaramillo</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Gomperts</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Stratmann</surname>
<given-names>RE</given-names>
</name>
<name>
<surname>Yazyev</surname>
<given-names>O</given-names>
</name>
<name>
<surname>Austin</surname>
<given-names>AJ</given-names>
</name>
<name>
<surname>Cammi</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Pomelli</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Ochterski</surname>
<given-names>JW</given-names>
</name>
<name>
<surname>Martin</surname>
<given-names>RL</given-names>
</name>
<name>
<surname>Morokuma</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Zakrzewski</surname>
<given-names>VG</given-names>
</name>
<name>
<surname>Voth</surname>
<given-names>GA</given-names>
</name>
<name>
<surname>Salvador</surname>
<given-names>P</given-names>
</name>
<name>
<surname>Dannenberg</surname>
<given-names>JJ</given-names>
</name>
<name>
<surname>Dapprich</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Daniels</surname>
<given-names>AD</given-names>
</name>
<name>
<surname>Farkas</surname>
<given-names>Ö</given-names>
</name>
<name>
<surname>Foresman</surname>
<given-names>JB</given-names>
</name>
<name>
<surname>Ortiz</surname>
<given-names>JV</given-names>
</name>
<name>
<surname>Cioslowski</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Fox</surname>
<given-names>DJ</given-names>
</name>
</person-group>
<source>Gaussian 09, revision D.01</source>
<year>2010</year>
<publisher-loc>Wallingford</publisher-loc>
<publisher-name>Gaussian, Inc.</publisher-name>
</element-citation>
</ref>
<ref id="CR42">
<label>42.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Valiev</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Bylaska</surname>
<given-names>EJ</given-names>
</name>
<name>
<surname>Govind</surname>
<given-names>N</given-names>
</name>
<name>
<surname>Kowalski</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Straatsma</surname>
<given-names>TP</given-names>
</name>
<name>
<surname>Van Dam</surname>
<given-names>HJJ</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Nieplocha</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Apra</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Windus</surname>
<given-names>TL</given-names>
</name>
<name>
<surname>de Jong</surname>
<given-names>WA</given-names>
</name>
</person-group>
<article-title>NWChem: a comprehensive and scalable open-source solution for large scale molecular simulations</article-title>
<source>Comput Phys Commun</source>
<year>2010</year>
<volume>181</volume>
<fpage>1477</fpage>
<pub-id pub-id-type="doi">10.1016/j.cpc.2010.04.018</pub-id>
</element-citation>
</ref>
<ref id="CR43">
<label>43.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Glendening</surname>
<given-names>ED</given-names>
</name>
<name>
<surname>Landis</surname>
<given-names>CR</given-names>
</name>
<name>
<surname>Weinhold</surname>
<given-names>F</given-names>
</name>
</person-group>
<article-title>NBO 6.0: natural bond orbital analysis program</article-title>
<source>J Comput Chem</source>
<year>2013</year>
<volume>34</volume>
<fpage>1429</fpage>
<lpage>1437</lpage>
<pub-id pub-id-type="doi">10.1002/jcc.23266</pub-id>
<pub-id pub-id-type="pmid">23483590</pub-id>
</element-citation>
</ref>
<ref id="CR44">
<label>44.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Grimme</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Ehrlich</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Goerigk</surname>
<given-names>L</given-names>
</name>
</person-group>
<article-title>Effect of the damping function in dispersion corrected density functional theory</article-title>
<source>J Comput Chem</source>
<year>2011</year>
<volume>32</volume>
<fpage>1456</fpage>
<pub-id pub-id-type="doi">10.1002/jcc.21759</pub-id>
<pub-id pub-id-type="pmid">21370243</pub-id>
</element-citation>
</ref>
<ref id="CR45">
<label>45.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Grimme</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Anthony</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Ehrlich</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Krieg</surname>
<given-names>H</given-names>
</name>
</person-group>
<article-title>A consistent and accurate ab initio parametrization of density functional dispersion correction (DFT-D) for the 94 elements H-Pu</article-title>
<source>J Chem Phys</source>
<year>2010</year>
<volume>132</volume>
<fpage>154104</fpage>
<pub-id pub-id-type="doi">10.1063/1.3382344</pub-id>
<pub-id pub-id-type="pmid">20423165</pub-id>
</element-citation>
</ref>
<ref id="CR46">
<label>46.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hoffmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Hiking on the potential energy surface of a functional tyrosinase model—implications of singlet, broken-symmetry and triplet description</article-title>
<source>Chem Commun</source>
<year>2014</year>
<volume>50</volume>
<fpage>403</fpage>
<lpage>405</lpage>
<pub-id pub-id-type="doi">10.1039/C3CC46893C</pub-id>
</element-citation>
</ref>
<ref id="CR47">
<label>47.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hoffmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Donor-driven conformational flexibility in a real-life catalytic dicopper(II) peroxo complex</article-title>
<source>Phys Chem Chem Phys</source>
<year>2016</year>
<volume>18</volume>
<fpage>6430</fpage>
<lpage>6440</lpage>
<pub-id pub-id-type="doi">10.1039/C5CP05009J</pub-id>
<pub-id pub-id-type="pmid">26688471</pub-id>
</element-citation>
</ref>
<ref id="CR48">
<label>48.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Jesser</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Rohrmüller</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Schmidt</surname>
<given-names>WG</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Geometrical and optical benchmarking of copper guanidine–quinoline complexes: insights from TD-DFT and many-body perturbation theory</article-title>
<source>J Comput Chem</source>
<year>2014</year>
<volume>35</volume>
<fpage>1</fpage>
<lpage>17</lpage>
<pub-id pub-id-type="doi">10.1002/jcc.23449</pub-id>
<pub-id pub-id-type="pmid">24122864</pub-id>
</element-citation>
</ref>
<ref id="CR49">
<label>49.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hoffmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Rohrmüller</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Jesser</surname>
<given-names>A</given-names>
</name>
<name>
<surname>dos Santos</surname>
<given-names>Vieira I</given-names>
</name>
<name>
<surname>Schmidt</surname>
<given-names>WG</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Geometrical and optical benchmarking of copper(II) guanidine–quinoline Complexes: insights from TD-DFT and many-body perturbation theory (part II)</article-title>
<source>J Comput Chem</source>
<year>2014</year>
<volume>35</volume>
<fpage>2146</fpage>
<lpage>2161</lpage>
<pub-id pub-id-type="doi">10.1002/jcc.23740</pub-id>
<pub-id pub-id-type="pmid">25255876</pub-id>
</element-citation>
</ref>
<ref id="CR50">
<label>50.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Rohrmüller</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Hoffmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Thierfelder</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Schmidt</surname>
<given-names>WG</given-names>
</name>
</person-group>
<article-title>The Cu
<sub>2</sub>
O
<sub>2</sub>
torture track for a real-life system: [Cu
<sub>2</sub>
(btmgp)
<sub>2</sub>
O
<sub>2</sub>
]
<sup>2+</sup>
oxo and peroxo species in density functional calculations</article-title>
<source>J Comput Chem</source>
<year>2015</year>
<volume>36</volume>
<fpage>1672</fpage>
<lpage>1685</lpage>
<pub-id pub-id-type="doi">10.1002/jcc.23983</pub-id>
<pub-id pub-id-type="pmid">26153244</pub-id>
</element-citation>
</ref>
<ref id="CR51">
<label>51.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Neese</surname>
<given-names>F</given-names>
</name>
</person-group>
<article-title>Prediction of molecular properties and molecular spectroscopy with density functional theory: from fundamental theory to exchange-coupling</article-title>
<source>Coord Chem Rev</source>
<year>2009</year>
<volume>253</volume>
<fpage>526</fpage>
<lpage>563</lpage>
<pub-id pub-id-type="doi">10.1016/j.ccr.2008.05.014</pub-id>
</element-citation>
</ref>
<ref id="CR52">
<label>52.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Tsipis</surname>
<given-names>AC</given-names>
</name>
</person-group>
<article-title>DFT flavor of coordination chemistry</article-title>
<source>Coord Chem Rev</source>
<year>2014</year>
<volume>272</volume>
<fpage>1</fpage>
<lpage>29</lpage>
<pub-id pub-id-type="doi">10.1016/j.ccr.2014.02.023</pub-id>
</element-citation>
</ref>
<ref id="CR53">
<label>53.</label>
<element-citation publication-type="book">
<person-group person-group-type="editor">
<name>
<surname>Matyjaszewski</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Davis</surname>
<given-names>TP</given-names>
</name>
</person-group>
<source>Handbook of radical polymerization</source>
<year>2002</year>
<publisher-loc>Hoboken</publisher-loc>
<publisher-name>Wiley</publisher-name>
</element-citation>
</ref>
<ref id="CR54">
<label>54.</label>
<element-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hoffmann</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Börner</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Flörke</surname>
<given-names>U</given-names>
</name>
<name>
<surname>Herres-Pawlis</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Synthesis and fluorescence properties of guanidine–pyridine hybridligands and structural characterisation of their mono- and bis(chelated) cobalt complexes</article-title>
<source>Inorg Chim Acta</source>
<year>2009</year>
<volume>362</volume>
<fpage>1185</fpage>
<lpage>1193</lpage>
<pub-id pub-id-type="doi">10.1016/j.ica.2008.06.002</pub-id>
</element-citation>
</ref>
</ref-list>
</back>
</pmc>
</record>

Pour manipuler ce document sous Unix (Dilib)

EXPLOR_STEP=$WICRI_ROOT/Wicri/Terre/explor/CobaltMaghrebV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000103 | SxmlIndent | more

Ou

HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000103 | SxmlIndent | more

Pour mettre un lien sur cette page dans le réseau Wicri

{{Explor lien
   |wiki=    Wicri/Terre
   |area=    CobaltMaghrebV1
   |flux=    Pmc
   |étape=   Corpus
   |type=    RBID
   |clé=     PMC:5073744
   |texte=   Multi-level meta-workflows: new concept for regularly occurring tasks in quantum chemistry
}}

Pour générer des pages wiki

HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i   -Sk "pubmed:27818709" \
       | HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd   \
       | NlmPubMed2Wicri -a CobaltMaghrebV1 

Wicri

This area was generated with Dilib version V0.6.32.
Data generation: Tue Nov 14 12:56:51 2017. Site generation: Mon Feb 12 07:59:49 2024