[Devel] DAKOTA on Medusa

Thanks this is good information and is starting to clarify some of the
questions.

I understand dakota is just the wrapper for specific algorithms, what is
not clear is if these algorithms are actually external to the dakota
binary, at least in the case of the DAKOTA distributed, open source
algorithms. The binary tarball we are using doesn't seem to have any
other binaries except dakota.

This makes me think that these algorithms are actually part of
the main dakota binary. The dakota binary gets launched on multiple
nodes. The "main" binary acts as the coordinator and the other binaries
just take on the personality of the selected algorithm.

Could you execute a known working job configuration from cahaba on medusa
to see if you get the MPI_Init error?

On Wed, 11 Jan 2006, Vinay Nagaraja Rao wrote:

>
> That works, i had used /opt/lam/gnu/bin mpirun before and it works for
> number of processors greater than 1, basically it runs the same code
> multiple times (it is not a multi-processer job). But we get the same
> error message we get for np=1 at the end after results.
>
> What i have observed (and which flashes in my mind now) after running so
> many DAKOTA jobs is: DAKOTA can run on only single processors, it cannot
> run on multiple processors , if it does it means it is running multiple
> times.
>
> What i used to do in CAHABA is: i used to allocate say 8 processors but
> assign only 1 processor for dakota using "mpirun -np 1" command, ....the
> simulation or external code which dakota used to call would then
> automatically run on the remaining processors.
>
> We have to differentiate between dakota run and the code which dakota
> runs !!, Dakota run is to process the input file (calculate gradients,
> call optimization algorithms and do iterations), simulation code which
> dakota inturn runs can be a parallel job capable of running on multiple
> processors. Note, DAKOTA handles high end simulation codes which need
> parallel capabilities, DAKOTA just handles the input files, calculates
> gradients, hessians and predicts results (in case of uncertainty
> quantification), even though work done by DAKOTA is the most important
> it will be computationally very less expensive compared to the
> simulation code which it is running.
>
> In cahaba they are using mpirun
> /usr/local/lam/7.0.5/pgi/4.0/PBSPro/5.4.0/bin/mpirun , is it same ??
>
> How did srividya run mpirun job (from lam) without any errors at the end
> ?
>
> the users lists of DAKOTA looks very disappointing, i am not able to
> find any useful mails in there, still have to search a lot though !!
>
> Thanks,
> Vinay Rao
>
> -----Original Message-----
> From: devel-bounces@metric.it.uab.edu on behalf of John-Paul Robinson
> Sent: Wed 1/11/2006 5:03 PM
> To: Discussions about projects in the lab
> Cc:
> Subject: RE: [Devel] Re: DAKOTA on Medusa
> OK. Do what it tells you. ;)
>
> The mpirun that you are using happens to be the mpirun from the LAM/MPI
> environment. (/opt/lam/gnu/bin comes before /opt/mpich/gnu/bin in your
> default PATH.)
>
> LAM's mpirun requires that you have lam daemons running on each compute
> node to accept the execute requests. You'll need to run the lamboot
> prior
> to running mpirun (just as is the case on cahaba).
>
> On Wed, 11 Jan 2006, Vinay Nagaraja Rao wrote:
>
> >
> > I tried that and got the following message,
> >
> >
> ------------------------------------------------------------------------
> > -----
> > It seems that there is no lamd running on the host
> > medusa.lab.ac.uab.edu.
> >
> > This indicates that the LAM/MPI runtime environment is not operating.
> > The LAM/MPI runtime environment is necessary for the "mpirun" command.
> >
> > Please run the "lamboot" command the start the LAM/MPI runtime
> > environment. See the LAM/MPI documentation for how to invoke
> > "lamboot" across multiple machines.
> >
> ------------------------------------------------------------------------
>

Ok, few DAKOTA issues here,

1) I tried running DAKOTA on CAHABA (note: mpirun in CAHABA is taken from /usr/local/lam/7.0.5/pgi/4.0/PBSPro/5.4.0/bin/mpirun) for some example test cases given along with the distribution and it gave me the same MPI_Init error message at the end.

so i used mpich mpirun in CAHABA i.e (mpirun taken from /usr/local/mpich/1.2.6/gnu/3.4.0/PBSPro/5.4.0/smp/bin/mpirun) and it ran without any MPI_Init error message at the end. This worked even for np greater than 1 as well.

on cahaba:
/usr/local/mpich/1.2.6/gnu/3.4.0/PBSPro/5.4.0/smp/bin/mpirun -np 2 dakota -i dakota_pce.in

works fine !!

When i tried the same on medusa i.e
/opt/mpich/gnu/bin/mpirun -np 1 /share/apps/Dakota/bin/dakota -i dakota_rosenbrock_ls.in

i got the error:
p0_7676: p4_error: interrupt SIGSEGV: 11

When we submit a job on CAHABA with a PBS job file, it generates a jobfile.e and jobfile.o file at the completion of the job run, which provides some information like Job ID, Username, Group, Job Name, Session, Limits, Resources, Queue and Account (this will be in jobfile.o , jobfile.e will have any error messages if present). I went through my simulation results i have done in cahaba and observed that all my jobfile.o files (wherever i have used mpirun) has that MPI_init error message. Since these .e and .o files were of no significance for my simulations, i had written a script to clear them soon after the job ends. I saw some surviving .e and .o files before i started using such scripts and was able to provide this information!!

2) Another issue which i saw in medusa is:

DAKOTA has two interface mechanisms with external codes a) Interface with an application 2) Interface with an approximation

Both interfaces writes and reads results to files for each iteration (note optimization is an iterative process).

For the many sample testcases in DAKOTA, reading and writing files takes place in /tmp directory. We can explicitly mention the file names to be created by giving the command:
parameters_file = 'params.in' \
results_file = 'results.out' \

anyway, what i started to say was i got the following error with the sample testcases in DAKOTA on medusa

Error: cannot open results file /tmp/fileOdjbhI

i guess this error will not be obtained when the external code path used in the input file will be given /share/apps/Dakota/path to code , as done in dakota_rosenbrock_ls.in testcase.

Do we have an issue with the mpich mpirun version we are using in medusa ?

Thanks,
Vinay Rao

Seems to me that atleast the dakota executable that we are using
does not use mpi libraries 'cause lam/MPI implementation also checks
to see if the MPI_INIT was called by the executing program and it
displays a warning message at the very end of execution of the
executable saying no mpi_init function was called.

But, actually mpich's mpirun must be able to execute any code
irrespective of it being a mpi program or not... Don't know currently
why that is not happening..

Thanks,
Srividya
On 1/11/06, John-Paul Robinson wrote:
> This is interesting.
>
> Some questions this raises are:
>
> * does dakota actually use the MPI libraries when run directly from the
> command line, ie. not useing mpirun. The point is are we having an MPI
> library issue?
>
> * What MPI implenentation was the Dakota binary that we have built with?
> Does this matter? Should we exepect to be able to run an application
> built with one MPI implementation to run in a different MPI
> implementation?
>
> ~jpr
>
> On Wed, 11 Jan 2006, Srividya Valivarthi wrote:
>
> > Hi,
> >
> > It looks like the LAM/MPI implementation is able to run dakota with
> > the provided input file.
> > However, I am still unable to get the MPICH's mpirun working.The
> > MPICH mailing lists seems to suggest to change the p4_GLOBMEMSIZE to a
> > greater value in order to solve the SIGSEGV:11 errors. But, did not
> > work in our case. Will have to dig deeper into each implementation's
> > mpirun scripts.
> >
> > Thanks,
> > Srividya
> >
> > On 1/10/06, Vinay Nagaraja Rao wrote:
> > > 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,
> > >
> > > http://lab.ac.uab.edu/~vinayrao/INSTALL
> > >
> > > 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
> > > accessing DAKOTA.
> > >
> > > 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,
> > >
> > > http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Rosenbrock.JPG
> > >
> > > 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:
> > >
> > > http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Input%20File.jpg
> > >
> > > 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 dakota_rosenbrock_ls.in"
> > > or
> > > ssh c0-0 "dakota -i dakota_rosenbrock_ls.in"
> > > or
> > > dakota -i dakota_rosenbrock_ls.in (to run the testcase on mother node)
> > >
> > > The result obtained from DAKOTA for the above command were:
> > >
> > > objective fn. = 1.1040731696e-11
> > >
> > > <<<<< Function evaluation summary: 29 total (29 new, 0 duplicate)
> > > <<<<< Best parameters =
> > > 9.9999668139e-01 x1
> > > 9.9999334619e-01 x2
> > > <<<<< Best residual terms =
> > > -1.6601013102e-07
> > > 3.3186100000e-06
> > > <<<<< Best data captured at function evaluation 29
> > > <<<<< Single Method Strategy completed.
> > > DAKOTA execution time in seconds:
> > > Total CPU = 0.15 [parent = 0.151976, child = -0.001976]
> > > 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
> > >
> > > i.e.,
> > >
> > > ssh c0-0 "/opt/mpich/gnu/bin/mpirun -np 1 -machinefile machines
> > > /usr/bin/strace /share/apps/Dakota/bin/dakota -i
> > > dakota_rosenbrock_ls.in"
> > >
> > > 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
> > > input files.
> > >
> > > 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 !!
> > >
> > > Thanks,
> > > Vinay Rao
> > >
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Devel mailing list
> > Devel@metric.it.uab.edu
> > http://metric.it.uab.edu/mailman/listinfo/devel
> >
>

Please verify that we have proper DAKOTA sources. Because according to
their website, there is both sequential and parallel DAKOTA
implementation. Since you mentioned that there was a warning about not
using MPI_Init, I am afraid we have a sequential one. Please verify.

/Prahalad

-----Original Message-----
From: devel-bounces@metric.it.uab.edu
[mailto:devel-bounces@metric.it.uab.edu] On Behalf Of Srividya
Valivarthi
Sent: Wednesday, January 11, 2006 1:10 PM
To: Discussions about projects in the lab
Subject: [Devel] Re: DAKOTA on Medusa

Seems to me that atleast the dakota executable that we are using
does not use mpi libraries 'cause lam/MPI implementation also checks
to see if the MPI_INIT was called by the executing program and it
displays a warning message at the very end of execution of the
executable saying no mpi_init function was called.

But, actually mpich's mpirun must be able to execute any code
irrespective of it being a mpi program or not... Don't know currently
why that is not happening..

Thanks,
Srividya
On 1/11/06, John-Paul Robinson wrote:
> This is interesting.
>
> Some questions this raises are:
>
> * does dakota actually use the MPI libraries when run directly from
the
> command line, ie. not useing mpirun. The point is are we having an
MPI
> library issue?
>
> * What MPI implenentation was the Dakota binary that we have built
with?
> Does this matter? Should we exepect to be able to run an application
> built with one MPI implementation to run in a different MPI
> implementation?
>
> ~jpr
>
> On Wed, 11 Jan 2006, Srividya Valivarthi wrote:
>
> > Hi,
> >
> > It looks like the LAM/MPI implementation is able to run dakota
with
> > the provided input file.
> > However, I am still unable to get the MPICH's mpirun working.The
> > MPICH mailing lists seems to suggest to change the p4_GLOBMEMSIZE to
a
> > greater value in order to solve the SIGSEGV:11 errors. But, did not
> > work in our case. Will have to dig deeper into each implementation's
> > mpirun scripts.
> >
> > Thanks,
> > Srividya
> >
> > On 1/10/06, Vinay Nagaraja Rao wrote:
> > > 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,
> > >
> > > http://lab.ac.uab.edu/~vinayrao/INSTALL
> > >
> > > 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
> > > accessing DAKOTA.
> > >
> > > 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,
> > >
> > > http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Rosenbrock.JPG
> > >
> > > 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:
> > >
> > >
http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Input%20File.jpg
> > >
> > > 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
dakota_rosenbrock_ls.in"
> > > or
> > > ssh c0-0 "dakota -i dakota_rosenbrock_ls.in"
> > > or
> > > dakota -i dakota_rosenbrock_ls.in (to run the testcase on mother
node)
> > >
> > > The result obtained from DAKOTA for the above command were:
> > >
> > > objective fn. = 1.1040731696e-11
> > >
> > > <<<<< Function evaluation summary: 29 total (29 new, 0 duplicate)
> > > <<<<< Best parameters =
> > > 9.9999668139e-01 x1
> > > 9.9999334619e-01 x2
> > > <<<<< Best residual terms =
> > > -1.6601013102e-07
> > > 3.3186100000e-06
> > > <<<<< Best data captured at function evaluation 29
> > > <<<<< Single Method Strategy completed.
> > > DAKOTA execution time in seconds:
> > > Total CPU = 0.15 [parent = 0.151976, child =
-0.001976]
> > > 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
> > >
> > > i.e.,
> > >
> > > ssh c0-0 "/opt/mpich/gnu/bin/mpirun -np 1 -machinefile machines
> > > /usr/bin/strace /share/apps/Dakota/bin/dakota -i
> > > dakota_rosenbrock_ls.in"
> > >
> > > 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
> > > input files.
> > >
> > > 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 !!
> > >
> > > Thanks,
> > > Vinay Rao
> > >
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Devel mailing list
> > Devel@metric.it.uab.edu
> > http://metric.it.uab.edu/mailman/listinfo/devel
> >
>

So if DAKOTA is not built with MPI what's the point of running it with
mpirun? Shouldn't we be using cluster-fork or similar?

This brings up more questions: Can we find out how this version of dakota
was built and if it links to the mpi libs? (ldd dakota) Also, what is
the significance of using or not using MPI for dakota. Since using MPI is
a compile time option, I have to assume that it's not a requirement. For
example, does not using MPI just eliminate the possibility of using some
of the optimization libraries that may require MPI?

I know some of these questions fall on Vinay to answer but I'm not getting
a good sense of what MPI does for dakota and if we should even worry about
it.

~jpr

On Wed, 11 Jan 2006, Srividya Valivarthi wrote:

> Seems to me that atleast the dakota executable that we are using
> does not use mpi libraries 'cause lam/MPI implementation also checks
> to see if the MPI_INIT was called by the executing program and it
> displays a warning message at the very end of execution of the
> executable saying no mpi_init function was called.
>
> But, actually mpich's mpirun must be able to execute any code
> irrespective of it being a mpi program or not... Don't know currently
> why that is not happening..
>
> Thanks,
> Srividya
> On 1/11/06, John-Paul Robinson wrote:
> > This is interesting.
> >
> > Some questions this raises are:
> >
> > * does dakota actually use the MPI libraries when run directly from the
> > command line, ie. not useing mpirun. The point is are we having an MPI
> > library issue?
> >
> > * What MPI implenentation was the Dakota binary that we have built with?
> > Does this matter? Should we exepect to be able to run an application
> > built with one MPI implementation to run in a different MPI
> > implementation?
> >
> > ~jpr
> >
> > On Wed, 11 Jan 2006, Srividya Valivarthi wrote:
> >
> > > Hi,
> > >
> > > It looks like the LAM/MPI implementation is able to run dakota with
> > > the provided input file.
> > > However, I am still unable to get the MPICH's mpirun working.The
> > > MPICH mailing lists seems to suggest to change the p4_GLOBMEMSIZE to a
> > > greater value in order to solve the SIGSEGV:11 errors. But, did not
> > > work in our case. Will have to dig deeper into each implementation's
> > > mpirun scripts.
> > >
> > > Thanks,
> > > Srividya
> > >
> > > On 1/10/06, Vinay Nagaraja Rao wrote:
> > > > 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,
> > > >
> > > > http://lab.ac.uab.edu/~vinayrao/INSTALL
> > > >
> > > > 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
> > > > accessing DAKOTA.
> > > >
> > > > 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,
> > > >
> > > > http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Rosenbrock.JPG
> > > >
> > > > 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:
> > > >
> > > > http://lab.ac.uab.edu/~vinayrao/Dakota/presentation/Input%20File.jpg
> > > >
> > > > 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 dakota_rosenbrock_ls.in"
> > > > or
> > > > ssh c0-0 "dakota -i dakota_rosenbrock_ls.in"
> > > > or
> > > > dakota -i dakota_rosenbrock_ls.in (to run the testcase on mother node)
> > > >
> > > > The result obtained from DAKOTA for the above command were:
> > > >
> > > > objective fn. = 1.1040731696e-11
> > > >
> > > > <<<<< Function evaluation summary: 29 total (29 new, 0 duplicate)
> > > > <<<<< Best parameters =
> > > > 9.9999668139e-01 x1
> > > > 9.9999334619e-01 x2
> > > > <<<<< Best residual terms =
> > > > -1.6601013102e-07
> > > > 3.3186100000e-06
> > > > <<<<< Best data captured at function evaluation 29
> > > > <<<<< Single Method Strategy completed.
> > > > DAKOTA execution time in seconds:
> > > > Total CPU = 0.15 [parent = 0.151976, child = -0.001976]
> > > > 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
> > > >
> > > > i.e.,
> > > >
> > > > ssh c0-0 "/opt/mpich/gnu/bin/mpirun -np 1 -machinefile machines
> > > > /usr/bin/strace /share/apps/Dakota/bin/dakota -i
> > > > dakota_rosenbrock_ls.in"
> > > >
> > > > 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
> > > > input files.
> > > >
> > > > 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 !!
> > > >
> > > > Thanks,
> > > > Vinay Rao
> > > >
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Devel mailing list
> > > Devel@metric.it.uab.edu
> > > http://metric.it.uab.edu/mailman/listinfo/devel
> > >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel@metric.it.uab.edu
> > http://metric.it.uab.edu/mailman/listinfo/devel
> >