- 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.
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".