FeynHiggs

De e-Ciencia

Support for Grid-Users of FeynHiggs

[FeynHiggs] is a Fortran code for the evaluation of Higgs boson sector observables in the Minimal Supersymmetric Standard Model (MSSM) with highest precision. Support for the general use of FeynHiggs can be found [here].

FeynHiggs can also be used to run on the Grid. The support for the Portland Group Compiler is however not general, and this code is optimized to run with this compiler. Therefore if you compile with PGI Compiler you need a statically linked version.

After downloading and unpacking FeynHiggs, go to the new FeynHiggs directory and type:

 ./configure --static
 make

The executable "FeynHiggs" is created in the subdirectoy "build". If you use F77 compiler from GNU no static compilation is needed.

Using FeynHiggs on the Grid requires furthermore a script that calls FeynHiggs together with the respective input file(s). There are two possibilities for the input files

1. input file in the native format. Example:

 MT           171.4
 MB           4.7
 MW           80.392
 MZ           91.1875
 MSusy        500
 MA0          200 500 10
 Abs(M_2)     200
 Abs(MUE)     1000
 TB           5
 Abs(Xt)      1000
 Abs(M_3)     800

How to use this type of input files is explained in the FeynHiggs [man pages] (see: Parameter files). Loops over variables are possible, the output to a file in computer readable format is performed with the "table" command (to be found in the "build" directory). A possible script looks like this:

 #! /bin/sh
 ./FeynHiggs inputfile | ./table in_var out_var > outputfile

2. input file in the [SUSY Les Houches Accord] format. This kind of file processes only one data point and writes the output in the new file inputfile.fh. To reasonably use the Grid several input files have to be called consecutively. A possible script looks like this:

 #! /bin/sh
 tar zxvf input.tar.gz
 rm input.tar.gz
 for file in <inputdirectory>/* ; do
   echo "processing " $file
   ./FeynHiggs $file 
 done
 tar zcvf output.tar.gz <inputdirectory>/*
 rm -rf <inputdirectory>

The files "outputfile" or "output.tar.gz", respectively, contain the results and have to be retrieved.

For questions concerning FeynHiggs, send an email to Sven Heinemeyer [Sven.Heinemeyer(at-no-spam)cern.ch] or Thomas Hahn [hahn(at-no-spam)feynarts.de].

Submission of Batch Jobs to the Grid

In what follows we will describe the submission of serial batch jobs to the Grid resources at IFCA. The example contains a restriction line which forces the job to end up on our machines locally, both at the level of CPU and at the level of Storage.

• Simple Job without Storage Elements (transferred data under 20 MB)

To submit a serial job to the grid batch queues of IFCA the job has to be described in the language of the Grid batch system, this is called Job Description Language (JDL). This is an example myjob.jdl

 # Mandatory attributes
 Executable = "myexe";
 StdOutput = "myexe.out";
 StdError = "myexe.err";
 # I/O files to be staged from/to the User Interface
 InputSandbox = {"myexe","input.dat"};
 OutputSandbox = {"myexe.out","myexe.err","myoutput.dat"};
 Requirements= other.GlueCEUniqueID == "i2gce01.ifca.es:2119/jobmanager-lcgpbs-ihep";

This is the description of the job:

1. Executes the binary myexe with needs the file input.dat to work.

2. Writes the STDOUT and STDERR in myexe.out and myexe.err

3. The output of the program is myoutput.dat

The size of data which can be carried on SandBoxes is limited to a few Mbytes. Evidently there are few real scientific applications that can work on such basic premises. However we strongly suggest users to try and succeed dummy tests like this before getting to more complicated scenarios.

The job is submited by

 [isabel@i2gui01 i2g-test]$ i2g-job-submit myjob.jdl
  
  
 Selected Virtual Organisation name (from proxy certificate extension): ihep
 Connecting to host i2grb01.ifca.es, port 7772
 Logging to host i2grb01.ifca.es, port 9002

 *******************************************************************************
                               JOB SUBMIT OUTCOME
   The job has been successfully submitted to the Network Server.
   Use i2g-job-status command to check job current status. Your job
   identifier (edg_jobId) is:
    - https://i2grb01.ifca.es:9000/ZAk0S0mwE7sMOjT7lSAtGw
 *******************************************************************************

The https identifier is used to check the status of the job

   [isabel@i2gui01 spinMC]$ i2g-job-status https://i2grb01.ifca.es:9000/ZAk0S0mwE7sMOjT7lSAtGw
   *************************************************************
   BOOKKEEPING INFORMATION:
  
   Status info for the Job : https://i2grb01.ifca.es:9000/ZAk0S0mwE7sMOjT7lSAtGw
   Current Status:     Scheduled
   Status Reason:      Job successfully submitted to Globus
   Destination:        i2gce01.ifca.es:2119/jobmanager-lcgpbs-ihep
   reached on:         Wed Nov 21 09:07:33 2007
   *************************************************************

When to job gets to status Done:

  [isabel@i2gui01 spinMC]$ i2g-job-status https://i2grb01.ifca.es:9000/JTOCrXh_i2ZzlxZy6kYpmg
  *************************************************************
  BOOKKEEPING INFORMATION:
  Status info for the Job : https://i2grb01.ifca.es:9000/JTOCrXh_i2ZzlxZy6kYpmg
  Current Status:     Done (Success)
  Exit code:          0
  Status Reason:      Job terminated successfully
  Destination:        i2gce01.ifca.es:2119/jobmanager-lcgpbs-ihep
  reached on:         Wed Nov 21 09:34:17 2007
  *************************************************************

We can retrieve the output by

  [isabel@i2gui01 spinMC]$ i2g-job-get-output https://i2grb01.ifca.es:9000/JTOCrXh_i2ZzlxZy6kYpmg
  Retrieving files from host: i2grb01.ifca.es ( for https://i2grb01.ifca.es:9000/JTOCrXh_i2ZzlxZy6kYpmg )
  *********************************************************************************
                       JOB GET OUTPUT OUTCOME
  Output sandbox files for the job:
  - https://i2grb01.ifca.es:9000/JTOCrXh_i2ZzlxZy6kYpmg
  have been successfully retrieved and stored in the directory:
  /tmp/jobOutput/isabel_JTOCrXh_i2ZzlxZy6kYpmg
 *********************************************************************************

All the files specified in the OutputSandbox will be copied to the indicated directory in /tmp

• Using the Storage Elements for massive Input/Output

In most real applications one needs to deal with data sizes that do not fit in the SandBox limitation. The way to proceed is then based on three steps

1. Store in the Grid in the apropriate place the Input data our program needs to run

Every VO, in particular iplanck has a dedicated directory for storage under /grid In order to access that directory first export the variable LFC_HOST to be at the central host for file catalogs of inteugrid, and then use the following commands

 [isabel@i2gui01 i2g-test]$ export LFC_HOST=lfc01.lip.pt
 [isabel@i2gui01 i2g-test]$ lfc-ls /grid/ihep
 isabel
 rmarco
 curto

Create a directory to store input and protect it acording to your needs. For example, you might consider to stored all your maps in a directory like CMB_MAPS and let read access to every iplanck member

 [isabel@i2gui01 i2g-test]$ lfc-mkdir /grid/ihep/CMB_MAPS
 [isabel@i2gui01 i2g-test]$ lfc-chmod 744 /grid/ihep/dummy
 [isabel@i2gui01 i2g-test]$ lfc-ls -l /grid/ihep/
 drwxr--r--   0 102      106                       0 Feb 15 16:15 CMB_MAPS

Now let us copy a big data file from your home directory in the User Interface to this directory

 lcg-cr --vo ihep -l lfn:/grid/ihep/isabel/mytarball.tar file:///home/isabel/mytarball.tar

the file mytarball.tar will be accesible for Jobs running on the grid when referencing it as lfn:/grid/ihep/isabel/mytarball.tar

 2. Design a shell script that used inside a JDL script makes the input available to
 the job, and puts the output available on a Storage Element once the Job has completed.

This in principle implies to copy the files we need before the job executes from a Storage Element to the actual node that is carrying the calculation. When the job completes, one option is to tar/gzip the result and copy it to a Storage Element. This is an example script which would do the job

 cat my-script.sh
 #!/bin/sh
 # Debug info
 echo \| Execution start: `date` \| Host: `hostname` \| User: `whoami` \| Path: `pwd` \|
 #Let us first get the input of the simulation in place
 lcg-cp --vo ihep lfn:/grid/ihep/CMB_MAPS/map.tar.gz file:///tmp/map.tar.gz
 #Let us create a directory there (it is not mandatory!)  
 mkdir RUN_febrero15
 cp /tmp/map.tar.gz RUN_febrero15/.
 cp executable RUN_febrero15/.
 cd RUN_febrero15/
 tar xzvf map.tar.gz
 rm map.tar.gz
 ./executable 
 #Once here the program has ended, we tar the result and put it on an accesible place
 cd $HOME
 tar czvf run_febrero15.tgz RUN_febrero15/*
 lcg-cr --vo ihep -l lfn:/grid/ihep/isabel/run_febrero_15.tgz file://$HOME/run_febrero15.tgz
 # Debug info
 echo \| Execution end: `date` \|

The result is now accesible from the User Interface where the user is logged, and can be retrieve by the command lcg-cp

 lcg-cp --vo ihep lfn:/grid/ihep/isabel/run_febrero15.tgz file://$HOME/gridruns/run_febrero15.tgz

Finally, this would be the JDL description of this job. Notice we have replaced the executable by the name of the script, my-script.sh

 # Mandatory attributes
 Executable = "my-script.sh";
 StdOutput = "my-script.out";
 StdError = "my-script.err";
 # Environment variables
 Environment = {"LFC_HOST=lfc01.lip.pt"};
 # I/O files to be staged from/to the User Interface
 InputSandbox = {"my-script.sh","executable"};
 OutputSandbox = {"my-script.out","my-script.err"};
 Requirements= other.GlueCEUniqueID == "i2gce01.ifca.es:2119/jobmanager-lcgpbs-ifusion";

The command i2g-job-submit will submit this job to the IFCA resources and use our File Catalog as reference for file stanging.

Submitting long jobs

An important point to consider is that the proxy of the user that has submitted the job has to be valid all the period that the job is supossed to queue and to run.

The initialization of the proxy is made by default for 12 hours. It is possible though to initialize the proxy for a longer period.

However the elegant solution to avoid that the job dies because the user proxy has expired is to use the mechanism of automatic job renovation by a proxy server. In order to use this facility one has to add to do the following

  #Create and Store a long term proxy on the proxy server
  [isabel@i2gui01 i2g-test]$ myproxy-init -s i2gpx01.ifca.es -d -n
  Your identity: /C=ES/O=DATAGRID-ES/O=BIFI/CN=Isabel Campos Plasencia
  Enter GRID pass phrase for this identity:
  Creating proxy .......................................... Done 
  Proxy Verify OK
  Your proxy is valid until: Thu Feb 22 17:12:25 2007
  A proxy valid for 168 hours (7.0 days) for user /C=ES/O=DATAGRID-ES/O=BIFI/CN=Isabel Campos Plasencia now    exists on i2gpx01.ifca.es.

The command myproxy-init has created a one-week valid proxy on the IFCA proxy server, i2gpx.ifca.es Next the user has to a line in the JDL job description informing the job about the location of the proxy

  MyProxyServer=i2gpx.ifca.es

Once the job is done, destroy that long proxy, because in general it is not safe to have long proxies impersonating us over the network.

  [isabel@i2gui01 i2g-test]$ myproxy-destroy -s i2gpx01.ifca.es -d
  Default MyProxy credential for user /C=ES/O=DATAGRID-ES/O=BIFI/CN=Isabel Campos Plasencia was successfully   removed.