This specification defines the requirements of the Chemical Markup Language CompChem convention.
1. Introduction
1.1 Notational Conventions
1.2 Namespaces
1.3 Development
2. Applying the CompChem convention on CML module element
3. CompChem Concepts and Elements
3.1 JobList
3.2 Job
3.3 Model Initialization
3.4 Model Calculation
3.5 Model Finalization
3.6 Computing Environment
3.7 User Defined Concept
4. Data Structure with CML Elements
4.1 Molecule
4.2 z-Matrix
4.3 ParameterList
4.4 PropertyList
4.5 Parameter
4.6 Property
4.7 Units
4.8 Value container
4.8.1 Scalar
4.8.2 Array
4.8.3 Matrix
5. Adding Properties, Parameters and other objects
6. Recommended Properties and Parameters for CompChem
6.1 Recommended Properties for an environment module
6.1 Recommended Parameters and objects for an initalization module
6.1 Recommended Properties and objects for a finalization module
7. Example Files
A. References
B. Acknowledgements
The CompChem convention is used to specify computational chemistry documents. It is designed to capture the typical underlying processes of quantum calculations and their relationships in a well defined implicit semantic structure using Chemical Markup Language (CML).
This document describes the concepts which are introduced in CompChem, explains how to compose a CompChem document and illustrates it with examples. This document references and should be read in conjunction with the CompChem dictionary, which is a core part of the convention mechanism and defines the terms used within it.
The core concepts that make up CompChem are:
The CompChem convention also relies on the molecular convention or other RECOMMENDED molecular conventions which defines a set of constraints for storing to representations of molecules in CML. CompChem requires that any molecules e.g. in the input molecular geometry and the optimised geometry result conform to the molecular convention. The molecular convention is not explained here and the reader should consult the molecular convention specification for more information.
Except the few instances where they are expressly forbidden, the convention allows users to optionally include both other cml elements and attributes, and foreign namespaced elements and attributes. It is expected that in general tools will silently ignore the extra information because they will not be able to understand it. This also permits the conventions and dictionaries to be developed around working tools, and only updated at well-defined intervals.
The current recommendation for the development of more complex objects not already represented
within CML, are that they are expressed as a CML list
, with a dictRef
attribute that points to the relevant entry in the CompChem
dictionary. Examples of this are the current representations for
basis sets and DFT functionals.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119 ].
The terms "element", "attribute", "child" and "parent" in this document are to be interpreted as described in the W3C Recommendation for Extensible Markup Language (XML) [ W3C XML ].
The use of fonts is as follows:
this font
.dictRef
), are written in this font
.This specification uses the following namespaces and prefixes to indicate those namespaces:
Prefix | Namespace URI | Description |
---|---|---|
cml
|
http://www.xml-cml.org/schema
|
Chemical Markup Language elements |
convention
|
http://www.xml-cml.org/convention/
|
Standard Chemical Markup Language convention namespace |
compchem
|
http://www.xml-cml.org/dictionary/compchem/
|
CompChem Dictionary namespace |
xhtml
|
http://www.w3.org/1999/xhtml
|
XHTML |
dc
|
http://purl.org/dc/elements/1.1/
|
Dublin Core Metadata Element Set, Version 1.1 |
The conventions, the dictionaries and CML are ongoing efforts. This convention serves to document the procedures used in working software (such as Chempound), but is also intended as a discussion document and will be revised as its scope is extended and additional areas of computational chemistry are explored. We very much welcome the input from all members of the community (pracitioners, developers, teachers, students, etc.) so please feel free to contact us and get involved if this is of use to you in your work.
It is hoped that the convention in its current form is both broad enough in scope, and flexible enough to be extended to cover most areas of interest in computational chemistry. At the same time, there should be enough structure present that it is already possible to develop tools that rely on the convention and will not be broken by future updates - they may just not be able to take full advantages of the extensions. For example, the results of a job are always present in the finalization module. Tools can rely on finding the results they know about in this module (and new scalar, array and matrix properties that may appear can often be handled with no additional code). More complex objects (such as orbitals) will also appear in this module, but as the tool will not expect them, they can just be ignored.
The "human-readable" text for the conventions currently resides in the the bitbucket repository for the xml-cml.org website.
The rules that the convention texts describe are implemented in xslt within the cml validator, which is currently hosted on bitbucket. The rules defining the compchem convention, are implemented in the compchem-rules.xsl file. Any changes or updates to the convention generally requires editing BOTH files.
The reference software for generating CompChem convention compliant CML is currently the NWChem Jumbo Converters. These will parse a subset of the standard NWChem log files into CML, which can then be imported into Chempound. Documentation on the template parsing approach used in the jumbo coverters can be found on the Quixote Wiki.
The CompChem convention MUST be specified using the convention
attribute
on a module
element and the value MUST be a QName that represents the CompChem
convention, i.e. convention:compchem
. Such a module will be addressed as
a CompChem module or a CompChem module element in this convention. The
Example 1 shows the declarations of the namespaces and the convention for the CompChem module element.
Example 1: Minimal requirements for CompChem module element.
<module xmlns="http://www.xml-cml.org/schema" xmlns:convention="http://www.xml-cml.org/convention/" convention="convention:compchem"> <!-- body is omitted. --> </module>
A CompChem module MUST contain at least one jobList
module
element, e.g. <module dictRef="compchem:jobList" id="jobList-0000">
,
see Example 2.
A CompChem module MAY also contain any number of child elements in any namespace, see Example 2.
Example 2: CompChem module as root element and contains jobList
modules.
<?xml version="1.0" encoding="UTF-8" ?> <module xmlns="http://www.xml-cml.org/schema" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:compchem="http://www.xml-cml.org/dictionary/compchem/" xmlns:convention="http://www.xml-cml.org/convention/" convention="convention:compchem"> <module dictRef="compchem:jobList" id="jobList-0001"> <!-- 1st job list body is omitted. --> </module> <module dictRef="compchem:jobList" id="jobList-0002"> <!-- 2nd job list body is omitted. --> </module> <dc:creator>Weerapong Phadungsukanan</dc:creator> <dc:title>Geometry optimization for hydrocarbon species</dc:title> <dc:description>Consist of CH4 and CH3 molecules</dc:description> <dc:date>2011-03-25</dc:date> </module>
A quantum chemistry calculation is often comprised of a series of subtasks,
e.g. coarse optimisation -> fine optimisation -> NMR Spectrum Analysis; this is
because most quantum chemistry software packages are designed to be modularised and only
to perform a single task at a time. The jobList
concept is introduced to capture these
series of successive subtasks and links the information from one subtask to the next subtask.
A Joblist concept in CompChem is represented by a module
element with
a dictRef="compchem:jobList"
attribute on a module
element. Such a module will be addressed as a jobList
module or a jobList
module element in this convention.
A jobList
module is constructed according to the following rules:
jobList
module MUST be defined by a dictRef="compchem:jobList"
attribute on a module
element, e.g.
<module dictRef="compchem:jobList">
. This is shown in
Example 3.
jobList
module element MUST have an id
attribute specified
the value of which MUST be unique within the module specifying the compchem convention.
jobList
module element MUST contain at least one
job
module child element. (See Example 3.)
jobList
module element SHOULD have a title
attribute the
value of which MUST be a non-empty string specifying a human-readable title for the module.
jobList
module element MAY contain more than one child element in any namespace,
see Example 3.
Example 3: A jobList
module
<module dictRef="compchem:jobList" id="jobList-0000" > <module dictRef="compchem:job" title="Geometry optimization for hydrocarbon species"> <!-- job body is omitted. --> </module> <dc:date>2011-03-25</dc:date> </module>
A job
concept represents a computational job performed by quantum chemistry
software, e.g. geometry optimisation job, frequency analysis job.
The job
concept is the smallest unit which can fully describe a general
picture of computational modelling.
A job
consists of model parameters (3.3) and model
optimisations or calculations (3.4), model results
(3.5) and computing environments
(3.6). These four components are fundamental to
modelling in every field. However, a job
does not require all four components.
Only an initialization module with the model parameters is mandatory.
The job and calculation modules are effectively functionally identical, as many of the calculations within a job could be run as separate jobs themselves (e.g. a single-point calculation in an optimisation run could be submitted separately). A job serves to group one or more calculations into a logical unit of work; it can therefore be thought of as the unit of work that would be submitted to a computational resource. The main differences between jobs and calculations are that jobs may contain an envionment module, and cannot themselves contain other jobs, whereas calculations can be nested within other calculations to any degree.
A job
concept in CompChem is represented by a module
element with
a dictRef="compchem:job"
attribute on a module
element. Such a module will be addressed as a job
module or a job
module element in this convention.
A job
module is constructed according to the following rules:
job
module MUST be defined by a dictRef="compchem:job"
attribute on
a module
element, e.g.
<module dictRef="compchem:job">
. This is shown in
Example 4.
job
module element MUST have an id
attribute specified the value of
which must be unique within the module specifying the compchem convention.
job
module element MUST contain exactly one
initialization module child element.
job
module element MAY contain zero or more
calculation module child elements.
job
module element MAY contain no more than one
finalization module child element.
job
module element MAY contain no more than one
environment module element.
job
module element.
job
module element SHOULD have a title
attribute, the value of
which MUST be a non-empty string specifying a human-readable title for the module.
job
module element MAY also contain other child elements in any namespace,
see Example 4.
The only essential child element of a job module is an initialization module which represents a model input for a computational job, see Example 4.
Example 4: Minimal requirements for a job module
<module dictRef="compchem:job" id="job-0000" title="input for coarse geometry optimisation"> <module dictRef="compchem:initialization"> <!-- required init body is omitted. --> </module> </module>
Example 5: A job
module with multiple calculation steps
<module dictRef="compchem:job" id="job-0000" title="coarse geometry optimisation"> <module dictRef="compchem:initialization"> <!-- required init body is omitted. --> </module> <module dictRef="compchem:calculation"> <!-- required calculation body is omitted. --> </module> <module dictRef="compchem:calculation"> <!-- required calculation body is omitted. --> </module> <module dictRef="compchem:calculation"> <!-- required calculation body is omitted. --> </module> <module dictRef="compchem:finalization"> <!-- required final body is omitted. --> </module> </module>
Example 6: A job
module without calculation steps
<module dictRef="compchem:job" id="job-0000" title="coarse geometry optimisation"> <module dictRef="compchem:initialization"> <!-- required init body is omitted. --> </module> <module dictRef="compchem:finalization"> <!-- required final body is omitted. --> </module> </module>
The model initialization concept represents the model parameters and inputs for a computational job or calculation. The model parameters are one of the most important elements and exist in every modelling study. Therefore, this concept is a REQUIRED element in the CompChem convention. The module defines the job or calculation, so that it should be possible to reproduce the job or calculation based soley on the data in this module.
The model initialization concept in CompChem is represented by a module
element with a dictRef="compchem:initialization"
attribute on a
module
element. Such a module will
be addressed as an initialization
module or an initialization
module element in
this convention.
An initialization
module is constructed according to the following rules:
initialization
module MUST be defined by a dictRef="compchem:initialization"
attribute on a module
element, e.g.
<module dictRef="compchem:initialization">
(Example 7).
initialization
module element MUST NOT contain more than one
molecule child element. The molecule MUST specify a convention using the convention
attribute and the convention SHOULD be one of the
RECOMMENDED molecular conventions.
initialization
module element MUST NOT contain more than one
parameterList
element.
initialization
module element MAY contain any number of
CML list
elements. These are recommended for holding complex objects, such as
basis sets or
DFT functionals that cannot
be simply represented with scalars, arrays or matricies in the parameterList
.
initialization
module element MAY contain any number of
user defined module element.
initialization
module element MUST contain at least one
child of molecule
, parameterList
or user defined module element.
initialization
module element MAY contain more than one
child element in any namespace but MUST NOT contain a property
child element or a propertyList
child element, see Example 7.
Example 7: An initialization
module
<module dictRef="compchem:initialization"> <molecule convention="convention:molecular"> <!-- consult molecular convention or recommended molecular convention. --> </molecule> <parameterList> <!-- parameterList body is omitted. --> </parameterList> </module>
A model calculation
concept represents the computation, the optimisation or the iteration
processes for computational job. Almost any computational procedure is a calculation, and calculations
can be nested to any level. As an example, an SCF calculation consists of an initial guess calculation,
and a number of iterative calculations, the output of the final iteration constituting the results. An
SCF geometry optimisation process consists of multiple calculation steps, each of which consists of an
SCF calculation, followed by a gradient calculation.
Calculations can also inherit attributes from their parents, so for example, a basis set need not be contained within each SCF iteration calculation, as the parent calculation's basis set can be inherited by the iteration calculation.
The calculation
process may or may not be of interest to
some scientists; therefore, the model calculation
is an OPTIONAL information in CompChem.
A model calculation
concept in CompChem is represented by a module
element with a dictRef="compchem:calculation"
attribute on a
module
element. Such a module will
be addressed as an calculation
module or an calculation module element in
this convention.
A calculation
module are constructed according to the following rules:
calculation
module MUST be defined by a dictRef="compchem:calculation"
attribute on a module
element, i.e.
<module dictRef="compchem:calculation">
(Example 8).
calculation
module element MUST NOT contain more than
one molecule
child element. The molecule MUST specify a
convention using the convention
attribute and the convention SHOULD be
one of the
RECOMMENDED molecular conventions.
calculation
module element MUST contain exactly one
initialization module child element.
calculation
module element MAY contain zero or more
calculation module child elements, each of which must be a direct
descendent of the parent calculation.
calculation
module element MAY contain no more than one
finalization module child element.
calculation
module element MAY contain any number of
user defined module elements.
Example 8: CompChem Calculation module
<module dictRef="compchem:calculation"> <module dictRef="compchem:initialization"> <molecule convention="convention:molecular"> <!-- consult molecular convention or recommended molecular convention. --> </molecule> <parameterList> <!-- parameterList body is omitted. --> </parameterList> </module> <module dictRef="compchem:finalization"> <molecule convention="convention:molecular"> <!-- consult molecular convention or recommended molecular convention. --> </molecule> <propertyList> <!-- propertyList body is omitted. --> </propertyList> </module> </module>
A model finalization
concept represents the model outputs or results for a computational job.
In some cases, a CompChem module MAY only represent the model inputs and does not contain
any calculations, therefore, the model finalization is an OPTIONAL information in CompChem.
A job or calculation may produce any number of intermediate results, and even final results that are not necessarily of interest to most users or even software using the calculation. Any important and persistant results should be placed in the finalization module. This allows code developers complete freedom to structure the modules as they see fit, but any software that uses the convention knows to query the initialization module for information on the calculation, and the finalization module for any results.
As an example, for an SCF calculation, the finalization module should contain the calculated energies, together with information on the attained convergence (e.g. norm of the gradient) and the orbitals. For an SCF optimisation, it will contain the above, together with the final molecular coordinates and information on the geometry convergence criteria.
A model finalization
concept in CompChem is represented by a module
element with a dictRef="compchem:finalization"
attribute on a
module
element. Such a module will
be addressed as a finalization
module or a finalization
module element in this convention.
A finalization
module is constructed according to the following rules:
finalization
module MUST be defined by a dictRef="compchem:finalization"
attribute on a module
element, i.e.
<module dictRef="compchem:finalization">
(Example 9).
finalization
module element MUST NOT contain more than
one molecule
child element. The molecule MUST specify a
convention using the convention
attribute and the convention SHOULD be
one of the
RECOMMENDED molecular conventions.
finalization
module element MUST NOT contain more than
one propertyList
element.
finalization
module element MAY contain any number of
user defined module elements.
finalization
module element MUST contain at least one
molecule
child, propertyList
child or
user defined module element.
finalization
module element MAY contain more than one
child element in any namespace but MUST NOT contain a parameter
child element or a parameterList
child element, see Example 7.
Example 9: CompChem Final module
<module dictRef="compchem:final"> <molecule convention="convention:molecular"> <!-- consult molecular convention and molecule section below. --> </molecule> <propertyList> <!-- propertyList body is omitted. --> </propertyList> </module>
The computing environment
concept refers to a hardware platform, software application,
the operating system and any hardware and software configurations used in order to
run the job or computational task. The environment
also includes the metadata such as
machine id, username, starting and finishing date time, tools, compilers, IP, etc.
This information is not related to input and output of the model but is supplementary to the software application to run properly and may vary from machine to machine. Therefore, the computing environment is OPTIONAL element in the CompChem convention.
The computing environment
concept in CompChem is represented by a module
element with a dictRef="compchem:environment"
attribute on a
module
element. Such a module will
be addressed as an environment
module or an environment
module element in
this convention.
An environment
module is constructed according to the following rules:
environment
module MUST be defined by a dictRef="compchem:environment"
attribute on a module
element, i.e.
<module dictRef="compchem:environment">
(Example 10).
environment
module element MUST NOT contain more than
one propertyList
element.
environment
property
element MUST be a child of a propertyList
element, see XXX.
environment
module element MAY contain more than one child element in any
namespace including
any number of user defined module elements, see Example 10.
However, CompChem can only understand a particular set of concepts. The concepts that are well understood by
CompChem are RECOMMENDED in section XXX.
environment
module MUST contain at least one
child of parameterList
or userDefinedModule
elements.
environment
module element MAY contain more than one
child element in any namespace but MUST NOT contain a parameter
child element or a parameterList
child element, see Example 7.
Although CompChem allows an environment
module element to contain elements that represent the concept of parameters,
this is NOT RECOMMENDED.
Example 10: An environment
module
<module dictRef="compchem:environment"> <propertyList> <!-- propertyList body is omitted. --> </propertyList> </module>
CompChem allows users or authors to define their own concepts if the RECOMMENDED concepts above do not fit into their requirements.
A user defined concept in CompChem is represented by a module
element with a dictRef
attribute whose value points to an entry in a dictionary
that defines the concept, see Example 11. Such a module will be addressed as a user defined module or a user
defined module element in this convention.
Users are free to design any structure for a user defined module. However, it is RECOMMENDED to use existing structures or a structure that has a schema for validation.
Information in a user defined module cannot be guaranteed to be understandable by all processing software tools.
Example 11: A user defined module
<module dictRef="prefix:identifier"> </module>
CompChem has adopted a set of elements from CML to store the contents of the computational data. This section describes how CompChem constructs the data structure from these CML elements set.
NOTE: elements in the CML namespace (http://www.xml-cml.org/schema
) are denoted using the (arbitary) prefix cml:
.
CompChem uses cml:molecule
to store molecular geometry and coordinates. cml:molecule
specifications are defined in the molecular convention so the convention of the molecule
element MUST be specified using the convention
attribute with the value of convention:molecular
. Readers SHOULD consult the specifications of the molecular convention for more details.
In many quantum chemistry calculations, the coordinates of the atoms are represented using a z-Matrix coordinate system. CompChem adopta the z-Matrix concept from the CML schema. Z-Matrices and cartesian coordinates can be converted in both directions, but may differ in orientation and translation. There may be some conventions for ordering atoms in z-matrices which cannot be guaranteed.
CompChem uses cml:parameterList
to group the cml:parameter
(s). cml:parameterList
MUST have only cml:parameter
(s) as child element(s).
CompChem uses cml:propertyList
to group the cml:property
(s). cml:propertyList
MUST have only cml:property
(s) as child element(s).
CompChem uses cml:parameter
to represent the inputs of the quantum chemistry calculations.
A CML parameter is defined by cml:parameter
element and MUST have a reference to an entry in a dictionary which specifies the meaning of the parameter.
A parameter
MUST contain only
one of
the value containers given in section 4.8.
CompChem uses cml:property
to represent the concept of the outputs of the quantum chemistry calculations.
A CML property is defined by cml:property
element and MUST have a reference to an entry in a dictionary which specifies the meaning of the property.
A property
MUST contain only
one of
the value containers given in section 4.8.
Units are among the most important information in scientific data. All value containers, see section 4.8, MUST have units associated with them except for string or text values.
unit
attribute and the value MUST be the
QName
of an entry in a unit dictionary. The unit dictionary MUST be provided along with the CompChem
document if the unit entry used in the CompChem document does not exist in one of the
unit dictionaries on www.xml-cml.org.The unit dictionaries currently used within comp
CML provides elements to wrap many differrent types of mathematical, scientifical and computational values and variables, e.g. scalar, vector, matrix, array, etc., which will be addressed as value containers in the current context. In CompChem, we currently
only
allow the use of scalar
, array
and matrix
as value containers. This should be sufficient for many computational outputs. Other type of CML containers will be added later and may be built from combinations of primitive containers.
A CML scalar element in CompChem is used to hold scalar data, which can be a single value of dataType
integer, real, boolean, string or date.
In CompChem, a cml:scalar
MUST conform to the following rules :
cml:scalar
element and MUST conform to CML schema version 3.dataType
of scalar
is REQUIRED and MUST be specified using a dataType
attribute. The value of dataType
attribute MUST be
one of
xsd:string
, xsd:integer
or xsd:double
. TODO: Decide whether to include other types, e.g. xsd:date, [PMR not float/real] xsd:real, xsd:float
.
cml:scalar
MUST have units if the dataType
is either xsd:integer
or xsd:double
even if the units are unknown or dimensionless.cml:scalar
MUST NOT have unit and unit type if the dataType
is xsd:string
.
A CML array element in CompChem is used to hold a one dimensional array data structure of
only either
integer or real values, i.e. a collection of integer of real values where each element is identified by index. Thus, the data type of the CML Array MUST
only
be xsd:integer
or xsd:double
. It MUST also conform to the following rules :
cml:array
element and MUST conform to CML schema version 3.cml:array
is required and MUST be specified using the size
attribute with the minimum value of 1.cml:array
is REQUIRED and MUST be specified using the dataType
attribute. The value of dataType
attribute MUST be
one of
xsd:integer
or xsd:double
. TODO: Decide whether to include other types, e.g. xsd:real, xsd:float
. [NO, PMR]
cml:array
MUST have units even if they are dimensionless.
A CML Matrix element in CompChem is used to hold a two-dimensional rectangular matrix data structure of
only either
integer or real values. Thus, the data type of this value container MUST
only
be xsd:integer
or xsd:double
. It MUST also conform to the following rules :
cml:matrix
element and MUST conform to CML schema version 3.matrix
is required and MUST be specified using rows
and columns
attributes with the minimum values of 1. (In CML Schema, this value is xsd:nonNegativeInteger
which includes zero. Maybe this should be changed to xsd:positiveInteger
PMR: agreed)
matrix
is REQUIRED and MUST be specified using the dataType
attribute. The value of dataType
attribute MUST be
one of
xsd:integer
or xsd:double
. TODO: Decide whether to include other types, e.g. xsd:real, xsd:float
[PMR: NO].
cml:matrix
MUST have units even if they are dimensionless.
Authors MUST follow the RECOMMENDED style for property
s and parameter
s, visit external link.
An example of a convention-compliant CML file for a DFT calcultion with the b3lyp functional on CH2 is below.
Other examples can be found on the examples page.
Example (from above) : DFT B3LYP calculation on CH2 with 3-21g basis
<?xml version="1.0" encoding="UTF-8"?> <module cmlx:note="A file containing two or more jobs is valid." convention="convention:compchem" xmlns="http://www.xml-cml.org/schema" xmlns:convention="http://www.xml-cml.org/convention/" xmlns:units="http://www.xml-cml.org/units/units" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cmlx="http://www.xml-cml.org/schema/cmlx"> <module dictRef="compchem:jobList"> <module dictRef="compchem:job" id="job"> <module dictRef="compchem:environment" id="environment"> <parameterList> <parameter dictRef="compchem:program"> <scalar dataType="xsd:string">NWChem</scalar> </parameter> <parameter dictRef="compchem:programVersion"> <scalar dataType="xsd:string">6.1</scalar> </parameter> <parameter dictRef="compchem:hostName"> <scalar dataType="xsd:string">jmhts-MacBook-Air.local</scalar> </parameter> <parameter dictRef="compchem:executable"> <scalar dataType="xsd:string">nwchem</scalar> </parameter> <parameter dictRef="compchem:runDate"> <scalar dataType="xsd:string">Fri Apr 13 13:23:01 2012</scalar> </parameter> <parameter dictRef="compchem:compileDate"> <scalar dataType="xsd:string">Sat_Mar_03_17:07:28_2012</scalar> </parameter> <parameter dictRef="compchem:numProc"> <scalar dataType="xsd:string">1</scalar> </parameter> </parameterList> </module> <module id="jobInitialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">energy</scalar> </parameter> <parameter dictRef="compchem:title"> <scalar dataType="xsd:string">DFT B3LYP calculation on CH2 with 3-21g basis</scalar> </parameter> <parameter dictRef="compchem:wavefunctionType"> <scalar dataType="xsd:string">closed shell</scalar> </parameter> <parameter dictRef="compchem:numAtoms"> <scalar dataType="xsd:integer">3</scalar> </parameter> <parameter dictRef="compchem:numElectrons"> <scalar dataType="xsd:integer">8</scalar> </parameter> <parameter dictRef="compchem:numAlphaElectrons"> <scalar dataType="xsd:integer">4</scalar> </parameter> <parameter dictRef="compchem:numBetaElectrons"> <scalar dataType="xsd:integer">4</scalar> </parameter> <parameter dictRef="compchem:charge"> <scalar dataType="xsd:double" units="nonsi:elementary_charge">0.0</scalar> </parameter> <parameter dictRef="compchem:spinMultiplicty"> <scalar dataType="xsd:integer">1</scalar> </parameter> <parameter dictRef="compchem:pointGroup"> <scalar dataType="xsd:string">C2v</scalar> </parameter> </parameterList> <molecule id="molgeom"> <atomArray> <atom id="a1" elementType="C" x3="0.0" y3="0.0" z3="0.205"> <scalar dataType="xsd:string" dictRef="compchem:atomtypeRef">C</scalar> </atom> <atom id="a2" elementType="H" x3="0.0" y3="1.87" z3="-0.615"> <scalar dataType="xsd:string" dictRef="compchem:atomtypeRef">H</scalar> </atom> <atom id="a3" elementType="H" x3="0.0" y3="-1.87" z3="-0.615"> <scalar dataType="xsd:string" dictRef="compchem:atomtypeRef">H</scalar> </atom> </atomArray> <formula formalCharge="0" concise="C 1 H 2"> <atomArray elementType="C H" count="1.0 2.0"/> </formula> <property dictRef="cml:molmass"> <scalar dataType="xsd:double" units="unit:dalton" xmlns:unit="http://www.xml-cml.org/unit/si/">12.0107</scalar> </property> </molecule> <list id="basisSet" dictRef="compchem:basisSet"> <scalar id="basisSetLabel" dictRef="compchem:basisSetLabel" dataType="xsd:string">3-21g</scalar> <scalar id="basisSetType" dictRef="compchem:basisSetType" dataType="xsd:string">orbital</scalar> <scalar id="basisSetHarmonicType" dictRef="compchem:basisSetHarmonicType" dataType="xsd:string">cartesian</scalar> <scalar id="basisSetContractionType" dictRef="compchem:basisSetContractionType" dataType="xsd:string">segmented</scalar> <scalar id="basisSetDescription" dictRef="compchem:basisSetDescription" dataType="xsd:string">ao basis</scalar> <list id="basisSetContractions" dictRef="compchem:basisSetContractions"> <scalar dataType="xsd:string" dictRef="compchem:atomLabel">C</scalar> <scalar dictRef="compchem:basisSetHarmonicType" dataType="xsd:string">cartesian</scalar> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">S</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="3">172.256 25.9109 5.53335</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="3">0.061767 0.358794 0.700713</array> </list> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">S</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="2">3.66498 0.770545</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="2">-0.395897 1.21584</array> </list> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">P</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="2">3.66498 0.770545</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="2">0.23646 0.860619</array> </list> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">S</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="1">0.195857</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="1">1.0</array> </list> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">P</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="1">0.195857</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="1">1.0</array> </list> </list> <list id="basisSetContractions" dictRef="compchem:basisSetContractions"> <scalar dataType="xsd:string" dictRef="compchem:atomLabel">H</scalar> <scalar dictRef="compchem:basisSetHarmonicType" dataType="xsd:string">cartesian</scalar> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">S</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="2">5.447178 0.824547</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="2">0.156285 0.904691</array> </list> <list dictRef="compchem:basisSetContraction"> <scalar dictRef="compchem:basisSetShell" dataType="xsd:string">S</scalar> <array dataType="xsd:double" dictRef="compchem:basisSetExponent" size="1">0.183192</array> <array dataType="xsd:double" dictRef="compchem:basisSetCoefficient" size="1">1.0</array> </list> </list> </list> <list dictRef="compchem:dftFunctional" id="dftFunctional"> <scalar dataType="xsd:string" dictRef="compchem:dftFunctionalLabel">B3LYP</scalar> </list> </module> <module dictRef="compchem:calculation" id="dftEnergy"> <module dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">energy</scalar> </parameter> <parameter dictRef="compchem:title"> <scalar dataType="xsd:string">DFT B3LYP calculation on CH2 with 3-21g basis</scalar> </parameter> <parameter dictRef="compchem:wavefunctionType"> <scalar dataType="xsd:string">closed shell</scalar> </parameter> <parameter dictRef="compchem:numAtoms"> <scalar dataType="xsd:integer">3</scalar> </parameter> <parameter dictRef="compchem:numElectrons"> <scalar dataType="xsd:integer">8</scalar> </parameter> <parameter dictRef="compchem:numAlphaElectrons"> <scalar dataType="xsd:integer">4</scalar> </parameter> <parameter dictRef="compchem:numBetaElectrons"> <scalar dataType="xsd:integer">4</scalar> </parameter> <parameter dictRef="compchem:charge"> <scalar dataType="xsd:double" units="nonsi:elementary_charge">0.0</scalar> </parameter> <parameter dictRef="compchem:spinMultiplicty"> <scalar dataType="xsd:integer">1</scalar> </parameter> </parameterList> <list id="dftFunctional" dictRef="compchem:dftFunctional"> <scalar dataType="xsd:string" dictRef="compchem:dftFunctionalLabel">B3LYP</scalar> </list> </module> <module dictRef="compchem:calculation" id="initialGuess"> <module dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">initialGuess</scalar> </parameter> </parameterList> </module> <module dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.523335</scalar> </property> <property dictRef="compchem:e1Energy"> <scalar dataType="xsd:double" units="nonsi:hartree">-63.008753</scalar> </property> <property dictRef="compchem:e2Energy"> <scalar dataType="xsd:double" units="nonsi:hartree">18.34112</scalar> </property> </propertyList> </module> </module> <module id="iteration" dictRef="compchem:calculation"> <module id="initialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">iteration</scalar> </parameter> <parameter dictRef="compchem:iterationIndex"> <scalar dataType="xsd:integer">1</scalar> </parameter> </parameterList> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.8746435786</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="iteration" dictRef="compchem:calculation"> <module id="initialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">iteration</scalar> </parameter> <parameter dictRef="compchem:iterationIndex"> <scalar dataType="xsd:integer">2</scalar> </parameter> </parameterList> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.8851914217</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="iteration" dictRef="compchem:calculation"> <module id="initialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">iteration</scalar> </parameter> <parameter dictRef="compchem:iterationIndex"> <scalar dataType="xsd:integer">3</scalar> </parameter> </parameterList> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.8872577036</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="iteration" dictRef="compchem:calculation"> <module id="initialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">iteration</scalar> </parameter> <parameter dictRef="compchem:iterationIndex"> <scalar dataType="xsd:integer">4</scalar> </parameter> </parameterList> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.8876345541</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="iteration" dictRef="compchem:calculation"> <module id="initialization" dictRef="compchem:initialization"> <parameterList> <parameter dictRef="compchem:method"> <scalar dataType="xsd:string">dft</scalar> </parameter> <parameter dictRef="compchem:task"> <scalar dataType="xsd:string">iteration</scalar> </parameter> <parameter dictRef="compchem:iterationIndex"> <scalar dataType="xsd:integer">5</scalar> </parameter> </parameterList> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.8876352147</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.887635224491</scalar> </property> <property dictRef="compchem:e1Energy"> <scalar dataType="xsd:double" units="nonsi:hartree">-63.613972700907</scalar> </property> <property dictRef="compchem:coulombEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">24.635014928076</scalar> </property> <property dictRef="compchem:xcEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-6.052975700546</scalar> </property> <property dictRef="compchem:nuclearRepulsionEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">6.144298248886</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> <module id="finalization" dictRef="compchem:finalization"> <propertyList> <property dictRef="compchem:totalEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-38.887635224491</scalar> </property> <property dictRef="compchem:e1Energy"> <scalar dataType="xsd:double" units="nonsi:hartree">-63.613972700907</scalar> </property> <property dictRef="compchem:coulombEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">24.635014928076</scalar> </property> <property dictRef="compchem:xcEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">-6.052975700546</scalar> </property> <property dictRef="compchem:nuclearRepulsionEnergy"> <scalar dataType="xsd:double" units="nonsi:hartree">6.144298248886</scalar> </property> <property dictRef="compchem:wallTime"> <scalar dataType="xsd:double" units="si:s">0.2</scalar> </property> </propertyList> </module> </module> </module> </module>
This work is licensed under a Creative Commons Attribution 3.0 Unported License.