12.07.2015 Views

The Computational Materials Repository

The Computational Materials Repository

The Computational Materials Repository

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

3.3 System Components and Processes 57generic with a focus on electronic structure simulators. This has the advantagethat it can solve many different problems, but might not be optimal for some ofthem.<strong>The</strong> requirements for CMR were to aggregate, store, monitor, analyze, presentand share data from electronic structure simulators. Every of these requirementimposes its own challenges: aggregation requires that CMR can read the outputfrom different codes (3.3.4.1), storing must assure that the collected data canbe read also years later even if the original program is unavailable (3.3.3.2),monitoring should provide an almost instant view of the collected data, and theanalysis options must satisfy power users that prefer to work with programmableinterfaces (3.3.1.2) and casual users that favor more convenient access methods,like a web interface (3.3.1.3). Sharing can be performed through the interfaces(3.3.1) or by sending db-files.In order to be able to analyze data it was decided that the user should beallowed to enhance the data with custom fields, keywords, and attach scripts andrelevant files to provide more background information. Another challenge relatedto the analysis is the wish to be able to show what data was used to derivedresults (e.g. which calculations were involved when calculating the chemisorptionenergy). (2.7).In terms of usability CMR must not depend on not too many third-partyproducts and provide most of it’s functionality out of the box. For exampleCMR must run independently of a database and a web-server which is especiallyimportant when CMR is executed on a computer cluster or on a user’s computerwith limited access to resources or no database access.More important requirements are to be able to assure data consistency andprevent data loss, even if processes crash, errors occur or invalid data is tried tobe uploaded (3.3.4.2). Another important issue was to find ways to provide thedata with an acceptable delay.<strong>The</strong> biggest challenge though was to provide a system that is complete andprovides the expected functionality - or at least can be extended to provide it.This might seem trivial, but the way from a concept to a working implementationrequires to handle a lot of technicalities, special cases and technical limitations.3.3 System Components and Processes<strong>The</strong> data flow of an CMR installation for an institute was already briefly presentedin chapter 2. <strong>The</strong> focus in this section lies on providing more informationabout the components, show how they interact and explain their purpose. <strong>The</strong>data flow diagram in Fig. 3.1 highlights the three main type of components: theuser interfaces (blue) that are used to interact with the data, the repositories(purple), that store the data, and the db-files (red font) that are containers fortransferring and storing data. <strong>The</strong> arrows denote interactions/processes betweenthe components.<strong>The</strong> conversion (3.3.4.1)) to db-files (3.3.3.2) is a basic functionality of the

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!