Help 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. Is there a graphical user interface (GUI)?
    Yes. The JAGUAR GUI offers a graphical input deck creator and editor. Downloads are available from the download page.
  4. 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.
  5. 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. See Help Resources for getting help with DAKOTA.
    We track problem reports and enhancement suggestions in Trac, 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 mailing list or other mechanism 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 support Windows?
    Starting with the DAKOTA 3.1 release, we support DAKOTA via UNIX emulation on Windows. DAKOTA can be compiled using either Cygwin or MinGW/MSYS, but the resulting binaries (available on our download pages) can be run from a Windows command prompt.
  5. Do you support Macintosh?
    A Mac OSX port has been made available starting with the DAKOTA v3.2 release.

Feature Additions

  • How can I contribute?
    Our open source software benefits greatly from the contributions of its user community. Ways that you can contribute include:
    1. Use the code and offer feedback. We welcome constructive suggestions.
    2. Port DAKOTA to another platform or operating system and share the configuration extensions.
    3. Add a capability such as a new iterative algorithm, surrogate model, or interface; 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).
    4. View the issues and requirements that we track using links on our Developer Portal.
    In each of these cases, we prefer suggestions and patches via tickets submitted to our Trac site. Use the DAKOTA mailing lists for any problems.
  • What are the terms of contribution?
    Contributions to DAKOTA, including the JAGUAR DAKOTA GUI are subject to the terms of their respective licenses. Contributions which are derivative works of DAKOTA or the DAKOTA GUI will therefore be accepted under the same license terms as the product from which they are derived. Contributions which are not derivative works, such as additional DAKOTA examples, should be licensed as permissively as possible, preferrably BSD or similar.
    Along with or following your contribution, please include:
    • Complete list of authors and affiliations at time of authorship.
    • Consent from each author indicating the following or similar:
      I contributed [NAME OF FEATURE], via patches submitted in [URL to Trac ticket]. I agree to the following terms and conditions for my contributions: First, I agree my contributions are submitted under the terms of the LGPL [BSD for JAGUAR DAKOTA GUI] license. Second, I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes my contributions, I represent that I have received permission to make contributions and grant the required license on behalf of my employer.

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, see Help Resources.
  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.
  6. Why does a system or fork interface fail in Cygwin?
    While there could be many reasons for this, two common problems are
    1. Fork fails with "Could not fork; error code 11 (Resource temporarily unavailable)": This might be resolved by exiting cygwin, starting dash or ash, and running /usr/bin/rebaseall -v. This has been reported to resolve the permissions on /tmp as well. See Lottz Blog or superuser for more details.
    2. No permission to write to /tmp: This can be an issue when relying on automatically generated parameter/response file names, that is, not using named parameters and results files. Cygwin may link /tmp to the windows TEMP directory and not give sufficient write permissions to the cygwin environment. To resolve, make sure /tmp has write permission for the active user.

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.


Advance Simulation and Computing Advanced Scientific Computing Research Consortium for Advanced Simulation of LWRs Scientific Discovery through Advanced Computing