First we tried to build DAKOTA Version VOTD (Version
of the Day) on medusa, DAKOTA requires pgF90 compiler to compile and
build some of its F90 algorithms. Since medusa did not have pgF90
compiler installed we were not able to build it successfully, also we
observed many errors in some vendor packages included with DAKOTA.
DAKOTA includes many open source optimization packages (commercial
packages like DOT and NPSOL requires license to build and by default are
not included in the Configure file of DAKOTA).
Vendor packages included in DAKOTA require many libraries to function, a
careful study of these packages and thier 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,
The VOTD release of DAKOTA is a pre-release to release of Version 4.0 of
DAKOTA, which will have a java based GUI as well.
Since VOTD release of DAKOTA is not a fully stable release, we then
decided to build DAKOTA version 3.3.
Before we can try building version 3.3, we decided to use pre-built
binaries of DAKOTA on medusa, which provides the simplest route to
After unpacking DAKOTA and setting the environment variables, a simple
testcase (rosenbrock function) which is provided with the sample input
files was tested,
The below image file describes a rosenbrock function,
The unique solution to this problem lies at the point (x1, x2) = (1,
1) where the function value is zero.
The input file for this testcase is:
The backslash symbol (\) is used to escape the newline character in
order to split a keyword onto multiple lines for readability, use of the
# symbol to indicate a comment, use of single quotes for string inputs
(e.g., x1 ), the use of commas and/or white space for separation
of specifications, and the use of = symbols to optionally
enhance the association of supplied data.
The interface section of the input file specifies what approach will be
used to map variables into responses as well as details on how DAKOTA
will pass data to and from a simulation code. In this example, a test
function internal to DAKOTA is used, but the data may also be obtained
from a simulation code that is external to DAKOTA. The analysis_driver
keyword specifies the path to the simulation code.
Graphical output (2D graphs) is disabled, OPT++ Gauss Newton
algorithm is used and maximum number of iterations is set to 50.
DAKOTA is executed on compute node 0 by the following command,
ssh c0-0 "/share/apps/Dakota/bin/dakota -i
ssh c0-0 "dakota -i dakota_rosenbrock_ls.in"
dakota -i dakota_rosenbrock_ls.in (to run the testcase on mother
The result obtained from DAKOTA for the above command were:
objective fn. = 1.1040731696e-11
<<<<< Function evaluation summary: 29 total (29 new, 0
<<<<< Best residual terms
<<<<< Best data captured at function evaluation 29
<<<<< Single Method Strategy completed.
DAKOTA execution time in seconds:
= 0.15 [parent = 0.151976, child
Total wall clock = 0.689
NOTE: It satisfies the analytical results
When we tried to run DAKOTA using MPI libraries (mpirun command) it
failed with --- SIGSEGV (Segmentation fault) @ 0 (0) --- error
ssh c0-0 "/opt/mpich/gnu/bin/mpirun -np 1 -machinefile machines
/usr/bin/strace /share/apps/Dakota/bin/dakota -i
but DAKOTA does use mpi libraries since it ran successfully with ssh
command, i guess we need to build DAKOTA on medusa to enable it to run
successfully with mpirun command.
Note: DAKOTA version 3.3 for Redhat 9 is the one on which we tested the
I tried building DAKOTA on CAHABA which has pgf90 compiler installed,
but encountered somme errors with various packages. DAKOTA will try to
access many different libraries for its various packages.
NOTE: Building DAKOTA from RPM's has been avoided for now. If we are
successful with the build process from its source, we may not need one
at all !!
Building DAKOTA from source is not going to be an easy task, but we are
working on it !!