Чтение Official DSTs с помощью CRABа

Чтение Official DSTs с помощью CRABа.

Александр Торопин, ИЯИ РАН

CRAB Home Page: войти в http://cms-project-ccs. web. cern. ch/cms-project-ccs/,

далее кликнуть ORCA (левая колонка на странице) и далее

кликнуть CRAB в строке “Related projects: ...., CRAB, ....”

Предполагается, что GRID Certificate уже получен.

Успешно запускаются задания только из environment RedHat 7.3.4 с ORCA_8_7_1 (SCRAM_ARCH = Linux__2.4). Попытки запустить аналогичным образом задания из SLC3 (SCRAM_ARCH = slc3_ia32_gcc323) успехом не увенчались.

Для чтения Official DSTs с помощью CRABа необходимо выполнить следующие действия:

●  Войти в директорию, где есть Path to ORCA, например ~/ORCA_8_7_1/src/DST_test.

●  Сделать инициализацию CRAB: source $CMS_PATH/ccs/ww/scripts/Crab/crab. csh. В директории появится файл 'crab. cfg'.

●  Определить ORCA environment: 'eval `scram runtime - csh`'

●  Скопировать в данную директорию требуемый для анализов '.orcarc' файл, например, 'Analysis. orcarc'.

●  Создать стандартным способом при помощи команды 'scram b' library и executable файлы в соответствующих директориях ~/ORCA_8_7_1/lib и ~/ORCA/8_7_1/bin

●  В 'crab. cfg' сделать изменения в соответствующих строках:

dataset = hg03b_zz_2l2nu

owner = hg_DST871_2x1033PU_g133_CMS

executable = Analysis

orcarc_file = Analysis. orcarc

output_file = MyData. root

first_event = 0

total_number_of_events = 10000

job_number_of_events = 500

Здесь предполагается, что Analysis является именем executable file, и выходная информация будут писаться в файл MyData. root.

total_number_of_events лучше задавать > job_number_of_events * number_of_jobs.

dataset и owner здесь соответствуют DST для процесса zz -> 2l2nu. Эти DST

находятся на site PIC, который откликается практически всегда, его можно

использовать для тестов работоспособности данной системы.

●  Создать задания для CRABа: 'crab. py - create 10'. Т. е. создали 10 заданий по 500 events/job, согласно предыдущему определению. В данной директории создалась поддиректория crab_0_<date>_<time>. Здесь <date> и <time> являются реальными числами, которые CRAB определяет сам.

●  Поскольку на тех sites, где будет вестись обработка событий, computers могут быть с SLC3, а не с RedHat 7.3.4, нужно приготовить такие же library и executable файлы на машине с SLC3, задав на ней соответственно 'setenv SCRAM_ARCH slc3_ia32_gcc323', сделать 'eval `scram runtime - csh`' и 'scram b'. При этом подразумевается, что результаты предыдущей компиляции на RedHat 7.3.4, будут сохранены.

●  Далее нужно приготовить свой tarball 'default. tgz' следующим образом:

Cоздать поддиректорию test.

В test создать поддиректории bin и lib.

В bin и lib соответственно создать поддиректории Linux__2.4 и slc_ia32_gcc323

Поместить в эти поддиректории соответствующие library и executable файлы

приготовленные предварительно для Linux__2.4 и slc3_ia32_gcc323.

Получится следующая структура

test/bin/Linux_2.4/Analysis

/slc_ia32_gcc323/Analysis

test/lib/Linux__2.4/libMyAnalysis. so

/slc_ia32_gcc232/libMyAnalysis. so

Далее запустить команду 'tar - czvf default. tgz *' в директории test.

Файл default. tgz лучше поместить куда-нибудь в корневую директорию

(cp default. tgz ~/.), т. к. его не нужно создавать каждый раз для данного

sample of events.

Удалить директорию test.

●  Заменить созданный CRAB'ом default. tgz на приготовленный в предыдущем пункте файл 'cp ~/default. tgz crab_0_<time>_<date>/share/.'

●  Запустить задания: 'crab. py - submit 10 - continue'.

●  Посмотреть состояние заданий можно следующим образом:

edg-job-status - i crab_0_<date>_<time>/log/submission_id. log

●  Удобно запустить команду 'crab. py - mon noprint - continue', которая по окончании каждого задания сделает извлечение полученной информацию в директорию crab_0_<date>_<time>/res

●  Вместо этой команды можно извлекать информацию руками после окончания соответствующего задания

edg-job-get-output - i crab_0_<date>_<time>/log/submission_id. log

●  Списки всех опубликованных DST можно посмотреть на site

http://cmsdoc. cern. ch/cms/production/www/PubDB/GetPublishedCollectionInfoFromRefDB. php

Site FNAL, где находятся, например, DST фонового процесса ttbar->leptonic, удается использовать только по утрам в выходные дни. Имеется в виду процесс

## FNAL

dataset = jm03b_TTbar_leptonic

owner = jm_DST871_2x1033PU_g133_OSC

Для счета запускались пакеты в 5 заданиях по 20 jobs в каждом задании и по 1000 events/job. Т. е. за один заход обрабатывалось по 100000 events. Все задания в одном заходе обрабатывались за ~2.5 часа (астрономического времени, не CPU). Практически ~957000 events были обработаны за 3 Weekend'а. По-видимому это можно сделать быстрее, т. к. убыстрять этот процесс не было необходимости, поскольку это происходило параллельно с другой работой. Получить такое количество событий без применения DST не представляется возможным за разумное время.

Последний раз (для контроля) попытка работы с этим site была предпринята 31.08.2005 (Wednesday). Были запущены 2 задания по 100 events/job. Они простояли в состоянии Scheduled 12 часов (default time for GRID window) и были завершены с состоянием Aborted. Те же задания были запущены 3.09.2005 (Saturday), стартовали практически сразу и завершились нормально.

Задания, запущенные на site PIC без замены tarball'а default. tgz, также заканчивались неудачей, т. к. система не могла найти соответствующий executable.

Для DST, находящихся в CERNе, эта процедура с CRAB не срабатывает, хотя все должно быть симметрично.

На некоторых sites, например IN2P3, проходили очень небольшие задания

(10  events/job), но не удавалось запускать задания с разумным числом events/job.

В этой заметке описано состояние с CRAB на текущий момент. Видно, что ситуация меняется по мере развития CRABа и описанная здесь процедура может достаточно быстро устареть.