grid

Internet2 2006 Fall Member Meeting Summary

| | | | | |

[phpwiki]
The Internet2 2006 Fall Member Meeting was held in Chicago, Illinois from Monday December 4th through Thursday December 7th. I attended the meeting to participate in a SURAgrid presentation and demonstration of applications running on SURAgrid, including the UABgrid BLAST application which leverages DynamicBLAST to distribute gene sequence queries across grid resources. I also participated in a meeting to discuss next steps for the continuing myVocs and GridShib integration efforts and project updates.

SURAgrid is a collaborative effort to build a production grid computing environment leveraging existing infrastructure and applications.

Integrating PHPki, GridShib CA, and MyProxy CA

| | | | |

[phpwiki]
Taking the time to read up on the GridShib CA and MyProxy CA was very useful. They and phpki ultimately all are backened by an openssl configuration so in a sense are compatible with each other. The decision to use one over the other seems to mainly be about where one stores a cert and how one can retreive it. The GridShib CA has a great way of creating certs that are truely private (client-based key) so I'm guessing there is not a key store in GridShib CA. MyProxy CA would seem to have a keystore since it's backended by Simple CA. This makes it like phpki except that the interface is command-line versus web.

Shibbolized GridSphere for UABgrid

| | | | |

As of this week, gridsphere V 2.1.4 and gridportlets are running. Tomcat version is 5.0.X. Apache version is 2.2.2


  • gridportlet as SP must be apache protected ->

    • install and configure mod_jk 4.1.30 (as ajp1.3)



      • Description of Connector Protocol
      • be sure mod_jk.so is installed (via RPM)
      • create mod_jk.conf in /etc/apache2 and Include in httpd.conf
          NOTE: skipped steps to secure WEB-INF Directory

    • Reconfigure gridsphere so that tomcat connector is used (5/10/06)

Introduction

| |

In order to demonstrate and enable utilization of a complex engineering toolkit on GRID resources, DAKOTA (Design Analysis Kit for Optimization and Terascale Applications) toolkit being developed at SNL (Sandia National Labs) has been used. DAKOTA is available for download under a GNU General Public License (GPL). DAKOTA runs on most Unix platforms and ports are actively maintained with nightly build verifications for PC Red Hat Linux, Sun Solaris, IBM AIX, SGI IRIX, DEC OSF, and the Intel TeraFLOP machine (ASCI Red).



The DAKOTA (Design Analysis Kit for Optimization and Terascale Applications) toolkit provides a flexible, extensible interface between analysis codes and iteration methods. DAKOTA contains algorithms for optimization with gradient and nongradient-based methods, uncertainty quantification with sampling, reliability, and stochastic finite element methods, parameter estimation with nonlinear least squares methods, and sensitivity/variance analysis with design of experiments and parameter study capabilities.

Commands and Input File Format

| |

The command for running DAKOTA on a single processor and exploiting asynchronous local parallelism is,


dakota -i dakota.in > dakota.out

dakota.in is the input file, dakota.out as the output file. By default DAKOTA wrties a restart file on execution, to read an existing DAKOTA restart file,



dakota -i dakota.in -read_restart dakota.rst > dakota.out

Multiprocessor execution,


mpirun -np 4 dakota -i dakota.in > dakota.out


mpirun -machinefile machines -np 4 dakota -i dakota.in > dakota.out

An issue that can arise with these command line arguments is that the mpirun script distributed with MPICH has been observed to have problems with certain file path specifications (e.g., a relative path such as "../some_file")



DAKOTA input is governed by the IDR input specification file. This file (dakota.input.spec) is used by a code generator to create parsing system components which are compiled into the DAKOTA executable. Therefore, dakota.input.spec is the definitive source for input syntax, capability options, and optional and required capability sub-parameters. Beginning users may find this file more confusing than helpful and, in this case, adaptation of example input files to a particular problem may be a more effective approach.


Detailed description of dakota.input.spec file with sample dakota.in files

Parallel Computing

| |

DAKOTA uses 'Single Program Multiple Data' (SPMD) parallel programming model. It uses message passing routines from MPI standard to communicate data between processors. The SPMD designation denotes that same DAKOTA executable is loaded on all processors during
the parallel invocation.


There are four main parallelism levels in DAKOTA,


1) Algorithmic coarse-grained parallelism: This parallelism involves concurrent execution of independent function evaluations, 
   where a function evaluation is defined as a 'Data request' from an algorithm.
2) Algorithmic fine-grained parallelism: This involves computing basic computational steps of an optimization algorithm (i.e., an internal linear algebra) in parallel.
3) Function evaluation coarse-grained parallelism: This involves concurrent computation of separable parts of a single function evaluation.
4) Function evaluation fine grained parallelism: This involves parallelization of solution steps within a single analysis code.

Coarse grained parallelism requires very little inter-processor communication and is therefore "embrrassingly parallel" i.e.,
there is very little loss in parallel efficiency due to communication as the number of processors increases.


Fine grained parallelism, on the other hand, involves much more communication among processors and care must be taken to avoid the case
of inefficient  machine utilization in which the communication demands among processors outstrip the amount of actual computational
work to be performed.


DAKOTA supports a total of three tiers of scheduling and four levels of parallelism which in combination can minimize efficiency losses and achieve near linear scaling on MP computers.


Concurrent iterators within a strategy ( Scheduling performed by DAKOTA )
Concurrent function evaluations within a iterator ( Scheduling performed by DAKOTA )
Concurrent analyses within each function evaluation ( scheduling performed by DAKOTA )
Multiprocessor analysis ( work distributed by the parallel analysis code )
All the optimization algorithms provided with DAKOTA support parallelism. Simulation invocation through DAKOTA can be synchronous (i.e., Blocking) or asynchronous (i.e., Nonblocking).

DAKOTA supports three approaches to local simulation invocation: Direct function, System call and Fork application. In direct function simulation code is linked as functions within DAKOTA source code. System call and fork interface are used for black-box interface, both are similar except that fork interface prevents file read race condition for asynchronous function evaluations.

DAKOTA uses MPI communicators to identify groups of processors. The global MPI_COMM_WORLD communicator provides the total set of processors allocated to the DAKOTA run. MPI_COMM_WORLD can be partitioned into new intra-communicators which each define a set of processors to be used for a multiprocessor server.

DAKOTA build process

| |

The following documentation of DAKOTA build process was wrtitten for installing DAKOTA version "Version of the Day" on Medusa (Rocks 4.1 cluster).


Vendor packages included in DAKOTA require many libraries to function, a careful study of these packages and their required libraries is required to successfully build DAKOTA. Building DAKOTA from source allows customization with additional packages and porting to additional platforms or operating systems.


Link to Install file, which explains more about it's build process, Install File

Links

| |

Dakota's home page is


href=http://endo.sandia.gov/DAKOTA/

Documentation for DAKOTA is given in the following links,
For reference manual

 
http://endo.sandia.gov/DAKOTA/licensing/votd/html-ref/index.html

For Developers manual


http://endo.sandia.gov/DAKOTA/licensing/votd/html-dev/index.html

User manual is given as a PDF file


http://endo.sandia.gov/DAKOTA/software.html

Here is a link to their download page (both binary and source files),


http://endo.sandia.gov/DAKOTA/licensing/download.html 

These manuals are also included in the source and binary distributions

Discussions

| |

SimpleCA for MyProxy : NOTES

| | | |

IMPORTANT SimpleCA Storage LOCATIONS

The private key of the CA is stored in /root/.globus/simpleCA//private/cakey.pem
The public CA certificate is stored in /root/.globus/simpleCA//cacert.pem

The distribution package built for this CA is stored in

/root/.globus/simpleCA//globus_simple_ca_74f9a25f_setup-0.18.tar.gz

This file must be distributed to any host wishing to request
certificates from this CA.

Syndicate content