Interfacing Dakota to a Simulation
- When I try to run Dakota in parallel, the system hangs/aborts.
- When I try to run Dakota with my simulator, I get a "command not found" error when Dakota attempts to execute the simulator.
- When I try to run Dakota with my input file, I get an "Invalid iterator" error.
- When I try to run Dakota with my input file, I get a parser error.
- When I try to execute a Dakota binary, I get an error message that there are missing libraries.
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.
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 CMake. Refer to the INSTALL file within the source distribution for additional information.
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 if hardcopies are not needed.
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.
Our open source software benefits greatly from the contributions of its user community. Ways that you can contribute include:
- Use the code and offer feedback. We welcome constructive suggestions.
- Port Dakota to another platform or operating system and share the configuration extensions.
- 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 Developer's Manual for information on class hierarchies and the structure provided by their base classes).
- 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.
Sandia is a government-owned, contractor-operated (GOCO) national laboratory operated for the U.S. Department of Energy (DOE) by National Technology and Engineering Solutions of Sandia, LLC. 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.
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.
Yes, Dakota 6.5 and newer include an update graphical user interface. It's included in the binary package downloads with UI in their name. Guide to using the GUI.
The formerly available JAGUAR GUI was compatible with Dakota 5.4, but not with more recent Dakota releases.
Please cite the Dakota User's Manual for the version you used. For example:
Adams, B.M., Bauman, L.E., Bohnhoff, W.J., Dalbey, K.R., Ebeida, M.S., Eddy, J.P., Eldred, M.S., Hough, P.D., Hu, K.T., Jakeman, J.D., Swiler, L.P., and Vigil, D.M., "DAKOTA, A Multilevel Parallel Object-Oriented Framework for Design Optimization, Parameter Estimation, Uncertainty Quantification, and Sensitivity Analysis: Version 5.4 User's Manual," Sandia Technical Report SAND2010-2183, December 2009. Updated April 2013.
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 User's Manual. The Interfacing section of the FAQ may also prove helpful. Once the simulation interface has been developed, switching between Dakota's many iterative methods usually requires only minimal modifications to the Dakota input file. Refer to Chapter 2 in the User's Manual for discussion of example input files.
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.
Refer to Sections 1.3 and 17.1 of the User's 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.
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.
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.
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:
(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.
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).
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, check out some of our other help resources.
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 *nix platforms; $DYLD_LIBRARY_PATH on OS X), (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".
A Mac OS X port has been made available starting with the DAKOTA v3.2 release.
Dakota can be compiled using Microsoft Visual Studio and the Intel compilers. A Windows version of Dakota is available on our Downloads page. Dakota can be compiled in the Cygwin environment.
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 User's Manual, especially Chapter 2, so careful study of this document should be enough to get you started.
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., 5.4) or stable subversion revision number (e.g., 5.4+, r2012). 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.), including the distribution and/or version, and architecture (Intel, AMD, PowerPC, etc.). Indicate whether 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:
- Your BuildDakotaTemplate.cmake file, along with any other files you modified.
- The commands used to invoke cmake and make and their output to the screen. E.g. "cmake -C BuildDakotaTemplate.cmake $DAK_SRC > cmake_output.txt 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 CMakeCache.txt file created by cmake (located in your build directory.)
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 Stable releases.