This page is aimed at beginning users who want to use the resources on the OSG. Every user must be associated with a registered organization (called a VO). Many large VOs (such as ATLAS and CMS) already have extensive user documentation; these pages are primarily oriented at users of smaller VOs who might be porting their own or community applications to the OSG.
These pages first introduce the primary OSG concepts, then dives into the nuts and bolts of building (or porting) an application to the grid by showing demonstration applications of increasing complexity. Both job management and data management are covered.
About the Open Science Grid
What is OSG? This page introduces the "big-picture" concepts of what the OSG is, what it is not, and what it tries to achieve.
What are VOs? Virtual Organizations - "VOs" - are an important organizational concept for the OSG; this page introduces VOs for the end-user.
About Security Credentials
What is a certificate? A digital certificate is like a passport for the grid. This page introduces them to new users, and includes links for getting your own certificate.
VO List includes a Membership URL for each VO for application to become a member. For example, the Trash/Engagement VO URL allows you to apply for Engage VO membership. To access these URLs and become a member, you must already have a valid certificate loaded in your browser as explained in Get a Certificate.
Using the OSG
OSG Client Software
All of the following sections will focus on job and data management on the OSG in order to build a successful grid application.
These will all assume that you have access to (an account on) an OSG Submit host provided by your VO or have the OSG client software installed.
Running jobs with Condor-G. Condor-G is the most common client tool for submitting jobs directly to the grid. The following pages cover the most common usage patterns; each link builds upon the knowledge learned in the previous one.
Building workflows in Condor (external link). This link covers in-depth how to allow Condor to handle dependencies between jobs using DAGMan. The link discusses vanilla universe jobs, but DAGMan works with grid universe jobs as well.
Data management is difficult on the grid. Unlike running jobs, where a consensus approach is beginning to appear, there are many techniques for data management. Some of them scale up well to hundreds of TBs a day, but scale poorly to opportunistic jobs.
The most common approach is to use a get/put method - they download input from a remote endpoint to the scratch area. The jobs run, and write output to the scratch area. After computation part of the job is finished, the result upload is uploaded to a remote endpoint.
Two common approaches to staging in data are via HTTP (many sites have local caches) or a protocol called SRM.
The de-facto way to save output is through SRM.
Globus RSL language usage on the OSG: Globus RSL is a mini-language that controls advanced, specific aspects of your jobs. For some users, this might be necessary for their jobs; we recommend it against using RSL heavily because it is not portable between sites.
Job Submission tool comparison: A document that compares the three most common submission methods in the OSG: GlideInWMS, PanDA?, and OSG-MM. The current OSG recommendation is to use GlideInWMS for grid applications.