StudyIn node
...................
-A StudyIn node has output data ports only. It is used to define data in the calculation scheme originating from a SALOME study. The associated study is given by its SALOME StudyID.
+A StudyIn node has output data ports only. It is used to define data in the calculation scheme originating from a SALOME study.
A port corresponds to data stored in the associated study. The data has a name (the port name), a type (the port type), and a reference that gives the entry into the study. This reference is either a SALOME Entry (for example 0:1:1:2) or a path in the SALOME study tree (for example, /Geometry/box_1).
StudyOut node
...................
-A StudyOut node only has input data ports. It is used to store results in a SALOME study. The associated study is given by its SALOME StudyID.
+A StudyOut node only has input data ports. It is used to store results in a SALOME study.
A port corresponds to a result to be stored in an associated study. The result has a name (the port name), a type (the port type), and a reference that gives the entry into the study. This reference is either a SALOME Entry (for example 0:1:1:2) or a path in the SALOME study tree (for example, /Geometry/box_1).
Containers
---------------------
-The SALOME platform executes its components after loading them in containers. A SALOME container is a process managed
-by the platform that may be executed on any known resource.
-A YACS container is used to define component placement constraints without necessarily precisely defining the resource
-to be used or the container name.
-The YACS container has a name. Constraints are given in the form of container properties.
-The current list of properties is as follows:
+The SALOME platform executes its components after loading them in containers.
+A SALOME container is a process managed by the platform that may be executed
+on any known resource.
+
+**WARNING !** There are two types of containers in the Salome world that must
+be clearly distinguished:
+
+- YACS container, that will be explained extensively here.
+- SALOME container which is a single process managed by the plateform that may
+ be executed on any resource in the resource catalog of the current SALOME
+ application. This single process can perform a set of jobs.
+
+To avoid misleading, in this chapter, container word will be systematically explicited.
+
+YACS containers are used in the definition of a scheme to define constraints
+on the execution of the nodes of a YACS scheme. They are part of the scheme
+as well as the nodes are.
+Exactly one YACS container is attached to an elementary node.
+
+The tasks (elementary nodes) that can be run remotely are ( or the tasks that
+are attached to a YACS container are ) :
+
+- Python script node.
+- Python function node.
+- Salome node.
+
+So all elementary nodes of a scheme (whatever their types in the list above)
+that can be executed remotely should be attached to a set of YACS container objects.
+
+YACS containers can be seen as a placement request at edition time of a scheme.
+**During the execution of a scheme, a YACS container is incarnated into one or
+several SALOME containers** depending on the type of the YACS container.
+
+Presently, there are 3 types of containers that incarnates the 3 different
+mapping strategies between YACS containers and SALOME containers :
+
+- *Mono YACS container* : The most simple. There is exactly one KERNEL container
+ attached on one mono YACS container. **WARNING**, this type of YACS container
+ can be dangerous into the context of foreach because several tasks can be
+ invoked in parallel inside of a same process that can lead to problems if the
+ service owning this YACS container is not thread safe. This type of YACS
+ container leads to no special treatment from Executor point of view.
+- *Multi YACS container* : There are as many SALOME containers as YACS component
+ instances attached to it in the scheme.
+ In the context of a foreach loop, it can lead to a pool of SALOME containers
+ attached to a YACS container. This type of YACS container leads to no special
+ treatment from Executor point of view.
+- *HP YACS container* : HP stands for Homogeneous Pool of SALOME containers. A HP
+ YACS container is mapped to a fixed size set of SALOME containers. This pool is
+ homogeneous which means that each of the SALOME containers inside of the pool
+ can be used indifferentely by the nodes attached to a same HP YACS container.
+ Contrary to the 2 YACS container types above, the Executor is active with
+ that type of YACS container by performing, if needed, a cutoff towards executed
+ tasks list in READY state regarding the availability of different YACS
+ HP containers.
+
+To create containers from TUI, see :ref:`py_container_creation`.
+
+All of these 3 types of YACS containers are sharing a common important features : set of properties.
+
+Properties are a set of (key,value) pairs which are designed to be forwarded
+directly to the KERNEL (expected "name" property and "attached_on_cloning"
+property, see :ref:`containers_aoc_property`) when a task attached to the YACS
+container has LOAD status during the execution of a scheme.
+
+The array below presents extensively the list of available keys and
+corresponding values expected that are common to 3 types of YACS container.
+Those properties (excepted "name" and "attached_on_cloning" property) are the
+way to specify the request to the KERNEL when the mapping will be requested by
+the Executor of YACS.
+For your information the dump in XML file of each YACS container object
+contains exclusively those (key,value) pairs.
+
+- To set properties from GUI to a YACS container, see :ref:`pp_for_container`.
+- To set properties from python interface, see :ref:`py_container`.
+
+.. note:: One important property is the "container_name" that must not be
+ confused with the property "name".
+
+ - "name" is relative to YACS container only (that will appear in the
+ XML file)
+
+ - "container_name" is a part of the request at run time when attaching
+ SALOME container with YACS container. Warning, the behaviour of
+ mapping is sensitive to the fact that "container_name" property is
+ empty or not.
+
+.. note:: HP YACS containers have 2 additionnal properties compared to Mono
+ and Multi YACS Containers. The first one is the "SizeOfPool" that defines the
+ size of the set of SALOME containers. The second one is "InitializeScriptKey"
+ which contains the string of a python code that will be passed to each of the
+ SALOME containers of the pool to initialize it (if necessary).
.. tabularcolumns:: |p{3cm}|p{3cm}|p{10cm}|
=================== ============= =============================================
name string if given imposes the resource to use. If not given, the resource manager will try
to find the best resource according to the constraints given by the other attributes.
+attached_on_cloning bool By default false for Multi and Mono YACS containers. Always true and not settable for HP containers. See :ref:`containers_aoc_property`
container_name string if given imposes the SALOME container name
hostname string if given imposes the machine (constraint used if name is not given)
policy "best", Choose the best or the first or the next in
parallelLib string ??
=================== ============= =============================================
+When using the "best" policy, a price is computed for each resource based on some criteria and the resource with the best price is chosen.
+The list of these criteria, from the most important to the least important, is:
+ 1. Number of processors (nb procs). For a resource, it is given by "nb_node" * "nb_proc_per_node".
+ 2. Number of nodes (nb nodes)
+ 3. Number of processors by node (nb proc/node)
+ 4. CPU frequency (cpu clock)
+ 5. Memory (mem mb)
+Undefined criteria are ignored. The price of each criterion is:
+ - the highest (3) if the expected value of the criterion is equal to the value of the criterion in the resource
+ - medium (2) if the expected value of the criterion is less than the value of the criterion in the resource
+ - the lowest (1) if the expected value of the criterion is higher than the value of the criterion in the resource
+
+.. _containers_aoc_property:
+
+Attached On cloning property
+''''''''''''''''''''''''''''''
+
+A specific chapter is dedicated to that property of YACS container. This property
+is only used by YACS and it is not forwarded to KERNEL.
+The value of this property is either False or True.
+The property is writable and by default set to false for mono YACS containers
+and multi YACS containers. For HP YACS containers this property is not writable
+and set to true.
+It controles the behaviour of the YACS container when cloning is triggered.
+
+A cloning is triggered during execution of a scheme for ForEachLoop and
+OptimizerLoop nodes of the scheme.
+In fact, when a ForEachLoop or OpmizerLoop node is executed it immediatly
+clones nbOfBranches times the node inside it (and performs right connections
+on these copies) using Node::clone method that recursively creates a deep copy
+of the node.
+
+The question is : What is done for deep copied elementary nodes executed
+remotely ? Do the copied node and base node share the same YACS container
+object or is the copied node lying on a deep copy of the YACS container
+of the base node ?
+
+The "attached_on_cloning" property of YACS container is considered here.
+
+- If false, a deep copy of YACS container is done when cloning the remotely
+ executed node.
+- If true, the cloned node and the node itself will share the same YACS
+ container.
+
+So it appears natural that HP YACS containers have this property set to true
+because it is the aim of HP YACS container to share a same pool of workers
+accross all the nodes especially in the ForEachLoop or OptimizerLoop context.
+
.. _catalogResources:
The resources catalog
resource name name the resource name
computer name hostname the complete machine name: this is the key that uniquely determines the machine
(for example : "nickel.ccc.cea.fr")
-alias alias character string to identify the machine (for example, “pluton”)
-access protocol protocol "rsh" (default) or "ssh"
-access type mode interactive "i" or batch "b". By default "i"
+access protocol protocol "ssh" (default), "rsh" or "sh"
+Type type "single_machine" (default) or "cluster"
user name userName user name to be used to connect to the machine
operating system OS
memory size memInMB
name of the batch manager
("pbs", "lsf", "slurm").
No default.
+Can Launch Batch Jobs canLaunchBatchJobs Indicate if the resource can be used to launch
+ batch jobs, through the JOBMANAGER module for
+ instance. It can be "false" (default) or
+ "true".
+Can Run Containers canRunContainers Indicate if the resource can be used to run
+ containers. It must be set to "true" if you
+ want to use this resource with YACS. It can be
+ "false" (default) or "true".
================================== =========================== ==============================================
The list of SALOME modules of the resource can also be indicated. By default, SALOME assumes that all components
<!DOCTYPE ResourcesCatalog>
<resources>
- <machine hostname="is111790" alias="is111790"
+ <machine hostname="is111790" name="is111790"
OS="LINUX" CPUFreqMHz="2992" memInMB="1024"
- protocol="rsh" mode="interactif"
- nbOfNodes="1" nbOfProcPerNode="1" >
+ protocol="rsh" type="single_machine"
+ nbOfNodes="1" nbOfProcPerNode="1"
+ canRunContainers="true">
</machine>
- <machine hostname="is111915" alias="is111915"
+ <machine hostname="is111915" name="is111915"
OS="LINUX" CPUFreqMHz="2992" memInMB="1024"
- protocol="ssh" mode="interactif"
- nbOfNodes="1" nbOfProcPerNode="1"
- appliPath="SALOME/Run">
+ protocol="ssh" type="single_machine"
+ nbOfNodes="1" nbOfProcPerNode="1"
+ appliPath="SALOME/Run"
+ canRunContainers="true">
<modules moduleName="GEOM"/>
<component name="SMESH"/>
<component name="VISU" moduleName="VISU"/>
value of 1 and a default case, then the absolute name of node “n” in the case 1 will be “c.b.p1_n” and the absolute name of the node in
the default case will be “c.b.default_n”.
-Active study
---------------
-A schema can be executed without using the SALOME study manager. But when a schema must be executed in the context
-of a SALOME study, it is possible to specify the studyId to use.
-
-The way to do that is to set the schema property **DefaultStudyID** to the study id.
-
-In the GUI, this is set automatically to the current active studyId.
-For execution in console mode, see :ref:`xml_active_study`
-
.. _errorreport:
Error report
