Resources - FAQ

General

  1. What is DAKOTA?
    DAKOTA is a general-purpose software toolkit for performing systems analysis and design on high performance computers. DAKOTA provides algorithms for design optimization, uncertainty quantification, parameter estimation, design of experiments, and sensitivity analysis, as well as a range of parallel computing and simulation interfacing services.
  2. How is DAKOTA used?
    To use DAKOTA for a particular application, an interface between DAKOTA and your simulation code must be developed. For an overview see Section 1.3 of the Users Manual. Also see the Interfacing FAQ entry for details.
    Once the simulation interface has been developed, any of the iterative studies available in DAKOTA can be performed with your simulation code through the selection of specifications in a DAKOTA input file. Refer to Chapter 2 in the Users Manual for discussion of example input files.
  3. Why are you releasing DAKOTA as open source?
    To foster collaborations and streamline the licensing process. Of particular note is the fact that an export control classification of "publicly available" allows us to work effectively with universities. For more on some of the motivations behind open source software in general, The Cathedral and the Bazaar is interesting reading.
  4. How is it that Sandia can release government software as open source?
    Sandia is a government-owned, contractor-operated (GOCO) national laboratory operated for the U.S. Department of Energy (DOE) by Lockheed Martin Corporation. The authority to release open source software resides with the DOE, and DAKOTA has gone through a series of copyright assertion and classification approvals to allow release to the general public. Important proponents for the open source release of Sandia software are the DOE's Accelerated Strategic Computing (ASC) Program Office and the DOE's Office of Science.

Support

  1. Is support available for DAKOTA?
    Not in the sense of commercial software.
    For basic usage guidance, we recommend careful perusal of our documentation followed by the use of our email lists. In particular, dakota-users is an archived email forum for usage questions and comments of general interest to the DAKOTA user community, and dakota-developers allows users to directly reach the DAKOTA development team, especially for questions related to Sandia installations and applications. Please note this guidance for support requests.
    We track problem reports and enhancement suggestions in our Bugzilla requirements database, where they are are vetted, prioritized, and planned. Enhancements are then accessible through our developmental releases (VOTD and Stable), as documented in the VOTD release notes.
  2. What information should I include with my support request or bug report?
    When contacting the dakota-users or dakota-developers mailing list for help, please clearly specify (1) what you expected to happen, (2) what you tried, and (3) what resulted instead. In particular, be sure to include the following:
    • Brief problem description.
    • DAKOTA version: either major release version number (e.g., 4.0) or VOTD subversion revision number (e.g., 4.0+, r4875). Determine the version number based on which DAKOTA you downloaded, or if installed and running, by typing "dakota -version".
    • Operating system (Linux, Solaris, AIX, Windows, Mac OS X, etc.) and architecture (Intel, AMD, PowerPC, etc.). Indicate if you're running in a 32- or 64-bit environment.
    • For problems running DAKOTA, include:
      • Relevant DAKOTA input deck, scripts (if possible), and commands executed.
      • Relevant output from code, for example, run dakota -i inputfile -o output.txt -e error.txt or perhaps more usefully, since both standard and error output will appear in the same file: "dakota >output.txt 2>&1" (if you are using sh or bash or zsh) or "dakota >& output.txt" (if you are using csh or tcsh).
    • For problems compiling DAKOTA include:
      • Configure and make commands used and corresponding output. For example "./configure >myconfigure.out 2>&1". Since make output can be voluminous, run make until the failure occurs, then type "make >make.out 2>&1" (or similar) to just capture the problem behavior.
      • The file config.log generated by the configure process.
      • Any relevant runtime or library errors.
  3. Is training available for DAKOTA?
    The DAKOTA team performs regular training for DOE laboratories and industrial CRADA partners, but not normally for other users. Our introductory training sessions closely follow the Users Manual, especially Chapter 2, so careful study of this document should be enough to get you started.
  4. Do you intend to support the Windows environment?
    A Windows port using Cygwin has been made available starting with the DAKOTA v3.1 release.
  5. Do you intend to support the Macintosh environment?
    A Mac OSX port has been made available starting with the DAKOTA v3.2 release.

Feature Additions

  1. Do you have plans for a GUI?
    Yes. Version 1.0 beta of JAGUAR has been released with DAKOTA Version 4.0. Downloads are available from the main download page, following a download registration.
  2. How can I contribute?
    Open source software initiatives benefit greatly from extensions contributed by their user communities. For example, the release notes for DAKOTA v3.1 cite a number of these contributions. Several ways that you can contribute include:
    • First, you can use the code and provide us feedback. We welcome constructive suggestions.
    • Second, if you want to port DAKOTA to another platform or operating system, you can share the configuration extensions with us for distribution within the user community (refer to the build documentation in Dakota/INSTALL).
    • Third, if you want to add a capability such as a new iterative algorithm, surrogate model, or interface protocol, this extension typically involves a class derivation along with the definition of a few virtual functions (refer to the Developers Manual for information on class hierarchies and the structure provided by their base classes).
    • Fourth, regular contributors can view the issues and requirements that we internally track using Bugzilla (currently Sandia only).
    In each of these cases, your point of contact is the DAKOTA development team at dakota-developers.

Downloading DAKOTA

  1. When I download one of the distributions to my Windows PC, the tar file extraction fails.
    Windows does not like the ".tar.gz" suffix on the DAKOTA distributions and will rename a distribution with a name like Dakota_3_0.Solaris2.8.tar.gz to something like Dakota_3_0_Solaris2.8_tar.tar. Attempting to extract files directly from this latter filename will fail since the file must first be uncompressed. The solution is simple: rename the file to the correct name as listed on the Web site and then proceed with uncompressing the file (using "gunzip") and extracting the file (using "tar xvf") on your Unix machine or emulator (do not use Winzip as this will also cause problems). To avoid this issue entirely, download the distribution directly to your Unix machine and bypass Windows.
  2. When I download one of the VOTD source distributions to my UNIX workstation, the tar file extraction fails.
    The VOTD tar files are generated under Red Hat Linux using GNU tar. The path names for some of the files are rather long which can cause problems with some platform-specific tar implementations (e.g., Sun Solaris, SGI Irix). If this happens, then there are a few possible solutions: (1) extract the distribution under Linux and then copy it to where it's needed, or (2) locate (using "whereis tar") or download/build GNU tar on the platform of interest.
  3. When I download one of the DAKOTA manuals in PDF, Acrobat reader fails.
    The problem appears to be with embedded PDF viewers in some browsers, rather than with the PDF files themselves. In particular, problems have been reported when using Acrobat 5.0 from within Internet Explorer or Netscape, whereas other combinations work fine. In these cases, we recommend the following:
    • try saving the file to disk and using Acrobat reader outside of the browser (bypassing the browser-embedded PDF viewer).
    • try another computer/browser/Acrobat combination.
    • for the Reference and Developers manuals, you can use the HTML documentation (Reference, Developers) if hardcopies are not needed.

Building DAKOTA

  1. My build fails because it can't find header files/libraries that DAKOTA needs.
    The DAKOTA configuration files are set up for a typical build within the Sandia environment. Customizations for other environments may be needed and will typically involve supplying overrides or additional path information to the autotools. If all else fails, you can usually configure around the offending package or feature by using the "--without" and "--disable" configure options. Refer to the INSTALL file within the source distribution for additional information.
  2. I get compile-time MPI errors: "SEEK_SET is #defined but must not be for the C++ binding of MPI" and similar for SEEK_CUR and SEEK_END.
    When compiling DAKOTA against the MPI2-compliant OpenMPI, you will need to define MPICH_IGNORE_CXX_SEEK at compile time, e.g., add the following to CPPFLAGS: -DMPICH_IGNORE_CXX_SEEK See also the     Trilinos FAQ.

Running DAKOTA

  1. When I try to execute a DAKOTA binary, I get an error message that there are missing libraries.
    When building DAKOTA executables, a static linking of all libraries is not always possible (since, in some cases, only shared object libraries are made available by the platform vendor). If differences in the required shared object libraries exist between the build and run platforms, then the run time shared object linker will abort with an error. To resolve this, there are a few courses of action: (1) locate the missing shared object libraries on your system (using whereis or find) and then add this path to your linker path ($LD_liBRARY_PATH on most platforms), (2) contact your platform vendor for the missing libraries, or (3) build DAKOTA from source on your run platform. It may also prove useful to list your shared object library dependencies using "ldd dakota".
  2. When I try to run DAKOTA with my input file, I get a parser error.
    First, cross-reference your input syntax with the master input specification reference (dakota.input.nspec or the generated dakota.input.txt) that was used in building your executable. Also, refer to the Common Specification Mistakes section in the Reference Manual. If you still can't find the problem, contact the development team at dakota-developers.
  3. When I try to run DAKOTA with my input file, I get an "Invalid iterator" error.
    You selected an iterator in your method specification that comes from a package which was omitted from the configuration/build of your DAKOTA executable. For example, DAKOTA binaries must omit DOT and NPSOL since we cannot distribute optional commercial library extensions. The solution to the problem is to select a different iterator from one of the available packages (e.g., CONMIN and OPT++ may be used in place of DOT and NPSOL).
  4. When I try to run DAKOTA with my simulator, I get a "command not found" error when DAKOTA attempts to execute the simulator.
    This is most commonly a path issue. Some platforms do not provide "." (the current working directory) as a default search path within user environments. To add it, use: 
    export PATH=.:$PATH
    (for sh, bash, or zsh) or 
    set path = (. $path)
    (for csh or tcsh), either at your shell command prompt (for temporary addition) or within your shell resource file (for permanent addition). Alternatively, modify your DAKOTA input file by putting "./" in front of the name of the simulator (if it is in the current directory), or by specifying a full pathname to the simulator.
  5. When I try to run DAKOTA in parallel, the system hangs/aborts.
    This problem can result from not being able to open a remote/secure shell (rsh/ssh) without a password challenge. MPI by default uses rsh, but can be configured to use ssh. Read the man pages for the shell in use and set up the necessary files (e.g., .rhosts, authorized_keys) so that you can open a shell on the target machine without a password challenge. Parallel DAKOTA runs should then work.

Interfacing DAKOTA to a Simulation

  1. What are the options for interfacing DAKOTA to my computational model?
    DAKOTA can be either loosely or tightly coupled to a simulation. Most users start by loosely coupling DAKOTA to an application using DAKOTA's black-box interface. In this mode, DAKOTA exchanges information with the application through the file system and executes the application with a system call. Some users wish to use DAKOTA's library mode to tightly couple DAKOTA algorithms with their applications. This more advanced use case can be very powerful, but requires programming to DAKOTA's C++ library API and typically involves compiling DAKOTA from source. The next two FAQ entries describe the two modes of integration. This slide shows the overall information flow between DAKOTA and an application.
  2. How do I implement DAKOTA's black-box interface to my simulation?
    Refer to Sections 1.3 and 17.1 of the Users Manual for additional information. Chapter 17 references example files included with the DAKOTA distribution which demonstrate how to construct a black-box interface. In addition the Users Manual sections on "DAKOTA Parameters File Data Format" and "DAKOTA Results File Data Format" may be helpful.
  3. How do I tightly couple DAKOTA to my software using DAKOTA's library mode?
    Refer to the DAKOTA Developer's Manual section on Interfacing with DAKOTA as a Library.