-{section: Submit DAGMan as a Condor-C Job}
+{section: Submit DAGMan as a HTCondor-C Job}
-DAGMan can manager grid universe (universe=grid) jobs without any further work. However, if you would like to submit DAGMan itself to run on a remote host, there is a bit more work. The following technique is specific to Condor-C (grid_resource=condor), although some notes on other grid types are mentioned.
+DAGMan can manager grid universe (universe=grid) jobs without any further work. However, if you would like to submit DAGMan itself to run on a remote host, there is a bit more work. The following technique is specific to HTCondor-C (grid_resource=condor), although some notes on other grid types are mentioned.
-This discussion assumes you are comfortable using both DAGMan and submitting Condor-C jobs.
+This discussion assumes you are comfortable using both DAGMan and submitting HTCondor-C jobs.
-1: Ensure that you can successfully submit a simple Condor-C job to the remote site. DAGMan adds additional complexity, and it's best to ensure you have the ability to successfully submit a job before adding that complexity.
+1: Ensure that you can successfully submit a simple HTCondor-C job to the remote site. DAGMan adds additional complexity, and it's best to ensure you have the ability to successfully submit a job before adding that complexity.
1: Collect all of the files associated with your DAG in a single submit directory. This include the DAG file, the individual submit files, the executables, and input files.
@@ -27,8 +27,8 @@
1: Submit the DAGfile.condor.sub using condor_submit.
Differences with other grid types:
-*: DAGMan requires a working Condor install on the remote system. At the very least a running condor_schedd is required, along with a working condor_submit. With Condor-C you can largely assume one is present; after all Condor-C is designed to submit to a working Condor install. For other systems you will need the system in place and whatever environment and paths are necessary must either be set by your job or the remote grid system.
-*: Condor-C automatically pulls back any output files that are created or modified. Most other grid types do not. You will need to list any output files you want back in transfer_output_files to retrieve them. Some grid systems fail if output files are missing, so you may want to create empty versions and specify them as transfer_input_files to ensure that they are present when the job finishes.
+*: DAGMan requires a working HTCondor install on the remote system. At the very least a running condor_schedd is required, along with a working condor_submit. With HTCondor-C you can largely assume one is present; after all HTCondor-C is designed to submit to a working HTCondor install. For other systems you will need the system in place and whatever environment and paths are necessary must either be set by your job or the remote grid system.
+*: HTCondor-C automatically pulls back any output files that are created or modified. Most other grid types do not. You will need to list any output files you want back in transfer_output_files to retrieve them. Some grid systems fail if output files are missing, so you may want to create empty versions and specify them as transfer_input_files to ensure that they are present when the job finishes.
{section: Worked Example}
@@ -46,7 +46,7 @@
{subsection: File: submit-remote}
-Next I created a simple submit file to ensure that I could use Condor-C.
+Next I created a simple submit file to ensure that I could use HTCondor-C.
{code}
executable = executable
