The UNICORE IDB (incarnation database) contains information on how abstract job definitions are to be mapped onto real executables. This process (called incarnation) is performed by the XNJS component, and uses a XML file (which by default is called 'simpleidb'). The second IDB function is advertising target system capabilities and allowing to check client resource requests against these.
This document covers Application incarnations, and resources.
The current XML schema for the IDB can be read from the SVN repository.
The most important functionality of the IDB is providing executables for abstract applications. An abstract application is given by name and version, whereas an executable application is given in terms of executable, arguments and environment variables.
Here is an example entry for the "Date" application on a UNIX system
<idb:IDBApplication>
<idb:ApplicationName>Date</idb:ApplicationName>
<idb:ApplicationVersion>1.0</idb:ApplicationVersion>
<jsdl:POSIXApplication xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix">
<jsdl:Executable>/bin/date</jsdl:Executable>
</jsdl:POSIXApplication>
</idb:IDBApplication>
As can be seen "Date" is simply mapped to "/bin/date".
Command line arguments are specified using Argument tags:
<idb:IDBApplication>
<idb:ApplicationName>LS</idb:ApplicationName>
<idb:ApplicationVersion>1.0</idb:ApplicationVersion>
<jsdl:POSIXApplication xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix">
<jsdl:Executable>/bin/ls</jsdl:Executable>
<jsdl:Argument>-l</jsdl:Argument>
<jsdl:Argument>-t</jsdl:Argument>
</jsdl:POSIXApplication>
</idb:IDBApplication>
This would result in a command line "/bin/ls -l -t".
The job submission from a client usually contains environment variables to be set when running the application. It often happens that a certain argument should only be included if a corresponding environment variable is set. This can be achieved by using "conditional arguments" in the incarnation definition. Conditional arguments are indicated by a quastion mark "?" appended to the argument value:
<idb:IDBApplication>
<idb:ApplicationName>java</idb:ApplicationName>
<idb:ApplicationVersion>1.5.0</idb:ApplicationVersion>
<jsdl:POSIXApplication xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix">
<jsdl:Executable>/usr/bin/java</jsdl:Executable>
<jsdl:Argument>-cp$CLASSPATH?</jsdl:Argument>
<!-- other args omitted for clarity -->
</jsdl:POSIXApplication>
</idb:IDBApplication>
Here, jsdl:Argument-cp$CLASSPATH?/jsdl:Argument is an optional argument.
If a job submission now includes a Environment variable named
<jsdl:Environment name="CLASSPATH">myjar.jar</jsdl:Environment>
the incarnated commandline will be "/usr/bin/java -cp$CLASSPATH ...", otherwise just "/usr/bin/java ...".
This allows very flexible incarnations.
For more details about IDB application definitions, please consult the detailed application definition guide.
The TargetSystemProperties element contains information about a site's available resources, as well as additional information that should be published to clients.
Simple strings can be entered into the IDB which are then accessible client-side. This is very useful for conveying system-specifics to client code and also to users. These text-info strings are entered into the IDB as a subtag of the TargetSystemProperties tag
Here is an example
<idb:TargetSystemProperties>
<!-- text infos -->
<idb:Info Name="Administator email">admin@site.org</idb:Info>
</idb:TargetSystemProperties>
These pieces of information are accessible client side as part of the target system properties.
The batch queue name that is sent by the UNICORE/X server to the TSI component can be configured here. By default, the queue name is "NONE", and the TSI needs to select a queue.
To change the queue name, use the QueueName tag, which is a sub-element of TargetSystemProperties:
<idb:TargetSystemProperties>
<!-- queue name -->
<idb:QueueName>batch-large</idb:QueueName>
...
</idb:TargetSystemProperties>
Resources of a target system are specified using JSDLs Resource tag. It allows to specify things like number of nodes, CPUtime (per CPU), CPUs per node, total number of CPUs, etc.
These capabilities are specified giving an exact value and a range, for example:
<jsdl:Exact>3600</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1</jsdl:LowerBound>
<jsdl:UpperBound>86400</jsdl:UpperBound>
</jsdl:Range>
The Range gives upper and lower bounds, where as the Exact value is interpreted as the DEFAULT, when the client does not request anything specific. If the Exact value is specified, the resource is part of the site's default resource set.
There exist a number of standard settings. You may choose to not specify some of them, if they do not make sense on your system. For example, some sites do not allow the user to explicitely select nodes and processors per node, but only "total number of CPUs".
The wall clock time.
The number of CPUs per node
The amount of memory per node (in bytes)
The number of nodes.
The total number of CPUs.
Users can specify the number of processors either as just "total number of CPUs", or they can give a value for both "nodes" and "CPUs per node". If both are given, the more values containing more information (i.e. nodes + CPUs per node) are used.
Similarly, if the administrator specifies both possiblities with a default value in the IDB, the nodes + CPUs per node will have precedence.
Most HPC sites have special settings that cannot be mapped to the generic JSDL elements shown in the previous section. Therefore UNICORE 6 includes a mechanism to allow sites to specify their own system settings and allow users to set these using the Grid middleware.
You can insert ResourceSetting elements into the Resources section, an example follows.
<jsdl:Resources>
<idb:ResourceSetting>
<idb:Name>TasksPerNode</idb:Name>
<idb:Description>The number of tasks per node. If larger than 32, the node will run in SMT mode.</idb:Description>
<idb:Value xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl">
<jsdl:Exact>32</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1</jsdl:LowerBound>
<jsdl:UpperBound>64</jsdl:UpperBound>
</jsdl:Range>
</idb:Value>
</idb:ResourceSetting>
</jsdl:Resources>
The meaning of the Value element is exactly as for the usual JSDL resources.
This example includes the elements defining capabilities, and some informational elements like CPUArchitecture and operating system info.
<idb:TargetSystemProperties>
<jsdl:Resources xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl">
<jsdl:CPUArchitecture>
<jsdl:CPUArchitectureName>x86</jsdl:CPUArchitectureName>
</jsdl:CPUArchitecture>
<!-- O/S -->
<jsdl:OperatingSystem>
<jsdl:OperatingSystemType>
<jsdl:OperatingSystemName>LINUX</jsdl:OperatingSystemName>
</jsdl:OperatingSystemType>
<jsdl:OperatingSystemVersion>2.6.13</jsdl:OperatingSystemVersion>
<jsdl:Description>A free UNIX clone</jsdl:Description>
</jsdl:OperatingSystem>
<!-- cpu time (per cpu) in seconds -->
<jsdl:IndividualCPUTime>
<jsdl:Exact>3600</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1</jsdl:LowerBound>
<jsdl:UpperBound>86400</jsdl:UpperBound>
</jsdl:Range>
</jsdl:IndividualCPUTime>
<!-- Nodes -->
<jsdl:TotalResourceCount>
<jsdl:Exact>1.0</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1.0</jsdl:LowerBound>
<jsdl:UpperBound>16.0</jsdl:UpperBound>
</jsdl:Range>
</jsdl:TotalResourceCount>
<!-- CPUs per node -->
<jsdl:IndividualCPUCount>
<jsdl:Exact>8.0</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1.0</jsdl:LowerBound>
<jsdl:UpperBound>8.0</jsdl:UpperBound>
</jsdl:Range>
</jsdl:IndividualCPUCount>
<!-- total CPUs -->
<jsdl:TotalCPUCount>
<jsdl:Exact>8.0</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1.0</jsdl:LowerBound>
<jsdl:UpperBound>128.0</jsdl:UpperBound>
</jsdl:Range>
</jsdl:TotalCPUCount>
<!-- Memory per node (bytes) -->
<jsdl:IndividualPhysicalMemory>
<jsdl:Exact>268435456</jsdl:Exact>
<jsdl:Range>
<jsdl:LowerBound>1024576</jsdl:LowerBound>
<jsdl:UpperBound>1073741824</jsdl:UpperBound>
</jsdl:Range>
</jsdl:IndividualPhysicalMemory>
</jsdl:Resources>
</idb:TargetSystemProperties>
If you need to modify the scripts that are generated by UNICORE/X and sent to the Perl TSI, you can achieve this using two entries in the IDB.
<idb:IDB xmlns:idb="http://www.fz-juelich.de/unicore/xnjs/idb"> <!-- Templates --> <idb:SubmitScriptTemplate> #!/bin/sh #COMMAND #RESOURCES #SCRIPT </idb:SubmitScriptTemplate> <idb:ExecuteScriptTemplate> #!/bin/sh #COMMAND #RESOURCES #SCRIPT </idb:ExecuteScriptTemplate> <!-- rest of IDB omitted --> </idb:IDB>
The SubmitScriptTenplate is used for batch job submission, the ExecuteScriptTemplate is used for everything else (e.g. creating directories, resolving user's home, etc)
UNICORE/X generates the TSI script as follows:
Modifying these templates can be used to perform special actions, such as loading modules, or changing the shell (but use something compatible to 'sh'). For example, to add some special directory to the path for user scripts submitted in batch mode, you could use
<idb:IDB xmlns:idb="http://www.fz-juelich.de/unicore/xnjs/idb"> <!-- Templates --> <idb:SubmitScriptTemplate> #!/bin/sh #COMMAND #RESOURCES LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/openmpi-2.1/lib; export LD_LIBRARY_PATH PATH=$PATH:/opt/openmpi-2.1/bin; export PATH #SCRIPT </idb:SubmitScriptTemplate> <!-- rest of IDB omitted --> </idb:IDB>
In the IDB file, properties can be specified.
<idb:IDB xmlns:idb="http://www.fz-juelich.de/unicore/xnjs/idb">
<!--- rest of IDB omitted -->
<idb:Property name="..."
value="..."/>
</idb:IDB
The following properties exist.