When a splice is created, a the nodes of the splice DAG are incorporated directly into the parent DAG. This is basically a recursive operation, so that splices that contain splices need to be absorbed before being absorbed into the parent DAG. For all practical purposes, the splice becomes part of the parent DAG. Because of this, there are some limitations:

  1. Splice DAGs cannot be created at "run-time". They must exist when the DAG is parsed (in other words, when the user runs condor_submit_dag). If you need to create a DAG on the fly, use a nested DAG.
  2. Category limits can apply to a splice DAG, but not to a nested DAG. This is because there is no way for the parent dag to communicate usage to the nested dag.
  3. There is only one DAGMan process with a splice DAG.

When one has a splice, the next question is what happens with MAXJOBS and categories. If the category name is prefixed with a '+', the category is global and refers to all jobs with that category. Otherwise, the category only refers to the splice DAG. Upper level DAGs control lower level DAGs as far as category goes.

When a node is the parent of a splice, the parent node ends up becoming the parent of each "initial" node in the splice (nodes with no parents defined within the splice). When a splice is the parent of a node, every "final" node (a node without a child defined in the splice) in the splice ends up becoming the parent of the child node. This means that, when one splice is the parent of another splice, every "final" node in the parent splice becomes are parent of every "initial" node in the child splice, possibly leading to a combinatorial explosion of parent/child relationships.

Partly to combat the possible explosion of parent/child relationships, we've proposed adding "socket" nodes to splices (see #3587) -- these would be automatically created, one node that's the parent of all "initial" nodes and one node that's the child of all "final nodes". Adding socket nodes would also make it much easier to do some other things that we'd like to do, such as allowing PRE and POST scripts on splices.

The "splice connection" feature (see #5213) allows more flexible dependencies between the nodes of two splices. In some ways the splice connection feature is a pretty big enhancement; however, in retrospect, I'm not so happy about the way in which it broke the correspondence between splices and sub-DAGs.

In general, we'd like to make splices and sub-DAGs more similar to each other. This would mainly involve adding capabilities to splices while maintaining their integration into a single DAGMan instance. Some of the features to be added are as follows:

The splice connection feature will make these enhancements more difficult to implement (or even define).