TREND simulation step by step Gu Junhua, Olivier Martineau-Huynh & Valentin Niess March 21st 2014

Simulation goal Short term goal: determine expected EAS detection skymap for TREND-50 and show that it matches the experimental one. This would prove that selected candidates in TREND-50 are mostly EAS. TREND EAS candidates ( )

Simulation goal Mid-term goal: determine optimal layout for the 35 antennas of GRANd-proto for detection of eV EAS with  =40-70°,  =0±20° (North) Long term goal:determine neutrino detection capacities & optimal layout for the GRAND giant array (~100’000 antennas) Easting [km] Northing [km] Tianshan mountains GRAND 60’000km² GRAND proto

Simulation process Shower simulation (simulation package: CONEX) – Present set: 400 showers (completed) E= eV Uniform distribution over sky Radio emission computation (simulation package: EVA 3D) – Choose 20 random core positions for each shower. (Therefore in total 400x20 = 8000 different shower geometries). – For each of them, E x,y,z elm field components computed for antennas within 800m of shower axis (limited to the 15 closest from axis). Antenna response computation (simulation package: NEC2) – Voltages at antenna output are computed on EW, NS and Vertical arms for all antennas with fields. DAQ & Analysis chain (TREND analysis software) – Experimental calibration coef is applied to simulated voltage. Experimental noise added to compute expected signal at DAQ level. – Resulting signals are processed through the standard TREND trigger & offline analysis software to determine if the shower (E, , x core ) is detected (or not).

Simulation environment CPU needs: – Not critical for showers and voltages computation. – Field computation: 400 showers x 20 core positions x 12 antennas/shower (average) x 2h computation /antenna (average) = 8000 days of computation. => Need for distributed computing TREND’s choice: – France-Asia Virtual Organization (IN2P3+KEK+IHEP+LPNHE* computing centers putting some dedicated ressources in common to perform computation for collaborations involving French & Asian researchers) (*: latest addition!) – DIRAC: « middleware » between our simulation software and the V.O. to organize/perform our simulation (ie submit+monitor jobs and retrievejob outputs) In principle, ~200 machines available on average => 8000/200 = 40 days to complete the full simulation.

TREND simulation in practice If willing to install simulation package by yourself: follow instruction given in Valentin’s But full simulation environment already installed at CC- IN2P3… My advice: use it!

Step by step process to run simulations at CC-IN2P3 Install your grid certificate in your CC-IN2P3 account. See (section Setting up your working environment ) Get enrolled in the France-Asia virtual organization and registered in DIRAC (see corresponding section on same page) Set up a WORK directory, from which you will centralize the production. Copy scripts and envir. executables there. For example: >mkdir -p ~/production/trend-50 >cd ~/production/trend-50 >cp $THRONG_DIR/soft/sim/python/production/scripts/setup.(c)sh >setup.production.(c)sh (depending on shell = bash or tcsh) >cp $THRONG_DIR/soft/sim/python/production/scripts/*tr50*. >cp $THRHONG_DIR/soft/sim/python/trasi/setup.(c)sh c)sh setup.trasi.(c)sh (depending on shell = bash or tcsh)

Step by step process to run simulations at CC-IN2P3 Create a DATA directory DATA_DIR, with subdirectories showers and fields, and copy existing showers to DATA_DIR/showers. Also copy file coord_antennas_all.txt to DATA_DIR. During your simulation process, DIRAC will copy your job outputs to DATA_DIR/fields. Below is an example with DATA_DIR=/sps/trend/omartino/trend-50: >mkdir -p /sps/trend/omartino/trend-50 >mkdir -p /sps/trend/omartino/trend-50/showers >mkdir -p /sps/trend/omartino/trend-50/fields >cp /sps/trend/trend-50/showers/* p /sps/trend/omartino/trend-50/showers Adapt envir. variables to your settings. In particular in get-tr50-jobs.py: # Bookkeeping: DB name and location. db = { 'name' : 'trend-50', 'path' : '.' } known_locations = ['/sps/trend/'+db['name']] /sps/trend/ and ‘name’ have to be modified to match DATA_DIR. Build your production DB. It will be used throughout the simulation process to manage all simulations stored in your DATA_DIR. The DB can be re-generated from scratch from the data stored in DATA_DIR at any time. Command is: >. setup.production.sh or source setup.production.csh >import-db DATA_DIR At this stage, 402 showers and 0 fields should be stored in your DB.

Run simulations Tools are: – register-tr50-fields.py: this script will select one shower stored in the DB, define a random core position, determine on which antennas the corresponding elm field should be computed and finaly register the corresponding jobs in the DB. This field is defined with a unique ID. Its status is set to ‘NEW’. The process is looped over an ajustable number of showers. Several other parameters have to be adjusted: max_showers = 'None‘ # Number of showers to be scanned. DO SET IT TO ‘None’, otherwise only the 1st max_showers showers will be scanned over and over again at each call of this script. n_random = 20 # Number of random positions for one shower min_nantennas=5 # Minimum number of antennas that is triggered by a shower max_nantennas=15 Also adapt the azimuth range to your selection in the following line of the code: ###filter the shower parameters### if shower['azimuth_angle'][0] 90 With max_showers = ‘None’, note that ALL showers will be scanned in a call, and therefore ALL field computations registered at once. You therefore have to run the script register-tR50-fields.py ONLY ONCE. At this stage you should have 402 showers registered in the DB, and ~ fields, all of them tagged as ‘NEW’.

Run simulations – unregister-tr50-fields.py: this script will allow you to remove a field from the DB (at any stage of the simulation process). You may (or may not) choose to erase the data as well. Fields to be erased are designated through their ID. Modify the following lines: # The list of items to unregister, by global ID. gids = (10980, 10980) # Remove individual IDs. #gids = range(3330, 4400) # Remove a full range of IDs. # Flag for deleting local data, if any. delete = False

Run simulations – submit-tr50-jobs.py: this script actually submits the jobs with ‘NEW’ status to the grid. Status is then changed to ‘SUBMITTED’. One parameter to be adjusted here: the max number of jobs to be submitted at once. Too small means you will have to frequently monitor the number of jobs running if you don’t want to loose time. Too large increase the risks that the DIRAC pilot is not running anymore (major cause of job failure). Max_jobs = takes few hours and seems a good compromise. # Maximum number of jobs to process. Set to None in order to process all selected jobs in the bookkeeping. max_jobs = 200

Run simulations – get-tr50-jobs.py: this script checks the status of jobs running on the grid. If jobs failed, status are updated accordingly. For jobs completed succesfully, data is copied to DATA_DIR, and their status is changed to ‘DONE’. – monitor-tr50-db.py: this script counts the number of jobs with status ‘DONE’, ‘NEW’, ‘SUBMITTED’, or ‘FAILED/WARING/None’. It is a basic tool to monitor the status of your simulation.