Accessing the IGWN Computing Grid¶

As described already, the IGWN Computing Grid is a distributed HTC platform that combines resources from many locations.

Resource pools¶

Collections of resources where you can run jobs in HTCondor are called "pools".

The IGWN Grid pool ('IGWN Pool') is the collection of resources that support centralised submission from an Access Point and distributed execution.

Additionally, many of the IGWN computing centres support a local resource pool for workflows that cannot be submitted to the IGWN Pool.

Use the IGWN Grid Pool by default

All IGWN workflows should attempt to use the IGWN Grid Pool by default, unless it has been demonstrated that their workflow cannot use the pool for technical reasons (including data access requirements).

If you need help in migrating an existing workflow to use the IGWN Grid Pool, or debugging why it doesn't work, please don't hesitate to Ask for help.

Access points (Submit hosts)¶

IGWN Grid Access Points¶

Workflows can be submitted to the IGWN Computing Grid (IGWN Pool) only from specific machines:

Hostname	Location
`ldas-osg.ligo.caltech.edu`	California Institute of Technology (LIGO Lab, USA)
`ldas-osg.ligo-wa.caltech.edu`	LIGO Hanford Observatory (USA)
`ldas-osg.ligo-la.caltech.edu`	LIGO Livingston Observatory (USA)

See here for documentation on how to access these machines.

Each submit host is configured to connect to the underlying HTCondor computing workload manager. Any computing task one wishes to run on the IGWN pool should be submitted from one of such submit hosts.

Local Access Points¶

In addition, each computing centre may host its own access point, with access only to the local resources pool. See the navigation links under Computing Centres for documentation specific to each computing centre.

Using a local pool from an IGWN Grid Access Point¶

Some IGWN Grid submit hosts provide access to both the IGWN Grid pool and a local resource pool.

Usage of the local pool operates under an opt-in model, where jobs must "flock" from the IGWN Grid to the local pool by using the following command in their submit instructions:

MY.flock_local = True

HTCondor submit file for jobs to include the local pool

Allow jobs to run in a local pool using MY.flock_local:

executable = ./lalapps_somejob
MY.flock_local = True

log = example.log
error = example.err
output = example.out

request_disk = 10GB
request_memory = 6GB

accounting_tag = igwn.dev.o5.compsoft.lalapps.nobelwin

queue

In general, MY.flock_local = True enables running on the local pool, but doesn't force that to happen - your job can now run on either the IGWN pool or the local pool.

To prohibit running anywhere other than the local pool, you should also include the following command in your submit instructions:

MY.DESIRED_Sites = "none"

HTCondor submit file for jobs only in the local pool

Restrict jobs to a local pool using flocking and restricting the external sites at which they can run:

executable = ./lalapps_somejob

MY.flock_local = True
MY.DESIRED_Sites = "none"

log = example.log
error = example.err
output = example.out

request_disk = 10GB
request_memory = 6GB

accounting_tag = igwn.dev.o5.compsoft.lalapps.nobelwin

queue

Using the local pool can be a powerful option for workflows where most of the processing is done on the IGWN Grid Pool tool, but some jobs have special requirements, for example:

pre-processing jobs - to extract data for further distribution using HTCondor file transfer and reduce the requirements for other jobs
short-duration post-processing jobs such as output data aggregation or web page generation.