[carl_r]

Hi,
I am currently struggling to resolve the below error:

Warning: analysis driver "rosenbrock" not found.
Fork application failure, aborting.
System error message: Permission denied

The interface definition of the input file is:

interface
analysis_drivers = 'rosenbrock'
fork
parameters_file = 'params.in'
results_file = 'results.out'




OS: Ubuntu 18.04.4 LTS (running on windows power shell)
Dakota 6.12.0

Example problem: Files copied from DAKOTA/examples/user/rosen_syscall.*

carl@DESKTOP-SDA6914:~/OpenFOAM/carl-7/run/dakotaTutorial/rosenbrock/rosenSyscall$ ls -l
total 92
-rwxrwxrwx 1 carl carl     0 Sep  9 10:07 dakota.rst
-rwxrwxrwx 1 carl carl    65 Sep  9 10:07 rosen_syscall.dat
-rwxrwxrwx 1 carl carl  5404 Sep  4 13:15 rosen_syscall.dat.sav
-rwxrwxrwx 1 carl carl   740 Sep  4 13:15 rosen_syscall.in
-rwxrwxrwx 1 carl carl  1474 Sep  9 10:07 rosen_syscall.out
-rwxrwxrwx 1 carl carl 61623 Sep  4 13:15 rosen_syscall.out.sav
-rwxrwxrwx 1 carl carl   601 Sep  9 10:07 rosen_syscall.stdout 
-rwxrwxrwx 1 carl carl  5265 Sep  4 13:15 rosen_syscall.stdout.sav

Environment variables (.bashrc):
[/HTML]
# Dakota Variables
INSTALL_DIR=/home/carl/DAKOTA/dakota-6.12.0

export PATH=$PATH:$INSTALL_DIR/bin:$INSTALL_DIR/test
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$INSTALL_DIR/bin:$INSTALL_DIR/lib

# All versions, to use the dakota.interfacing Python module:
export PYTHONPATH=$PYTHONPATH:$INSTALL_DIR/share/dakota/Python

export PATH="/root/perl5/perlbrew/perls/perl-5.26.1/bin:$PATH"
export PATH="$PATH:."
[/HTML]

Background:
I installed Dakota for the first time, building it from source files. I ran the test suite and it seemed to work.
I have then copied the example rosenbrock problems from the examples folder. The examples using the "direct" interface run correctly. But the problems using the simulation interface do not.

I also have another simple Dakota example that uses the simulation interface. I wanted to get this running, however, this results in the same problem as with the example case. Therefore I'm focusing on getting the example case running in the hope that the solution will fix this case as well.

Investigations:
I've run the test suite and it seems to work
I've tried all the direct interface training tutorials - They work
I've tried running the problem from the original examples directory in case the file paths were missing. This gave the same error.


Any help would be appreciated.

[Tobi]

Hi,

without reading your whole post, you can easily take the interface provided within my tutorials on my website. I guess you should be able to resolve your problem while comparing the cases or directly use and rewrite the interface.

This is actually not an OpenFOAM problem

[carl_r]

Tobi,
Agreed, this is not an OpenFoam issue, rather a Dakota one, however, I was hoping someone here might have the knowledge to assist. The Dakota support system is not as well developed as OF (at least for public users). I've sent a support request to the Dakota user group, but as I'm not part of a government lab I'm likely bottom of the pile for support.

I have your example (very helpful) and I get the same error with your case, as with the simulation interface examples from the Dakota tutorials, therefore I suspect its some system/installation issue. I'm just out of ideas and expertise as to what it is or how to trace it.

[carl_r]

I've managed to get dakota to run the tutorial cases by deleting and re-installing dakota 6.12.0.
I'm not sure what the difference was in the install. The only thing that I can think of is that during trying to debug the first installation I had to install some additional libraries/packages. maybe, these being present at the start in some way fixed the installation the second time around.

[Jonathan]

Originally Posted by carl_r

I've managed to get dakota to run the tutorial cases by deleting and re-installing dakota 6.12.0.
I'm not sure what the difference was in the install. The only thing that I can think of is that during trying to debug the first installation I had to install some additional libraries/packages. maybe, these being present at the start in some way fixed the installation the second time around.

Hi, I also have a similar, if not the same problem with Dakota and OF.
Basically, when Dakota comes to forking the parent process for the individual runs, i get the

Fork application failure, aborting.
System error message: Permission denied

error. I am using Ubuntu, which is not supported as far as I could tell, so I compiled this from source, using WolfDynamics tutorials. I have run all the smoke tests and unit tests, on the comiled install, and these all appear to pass without any problems.

So i was wondering,
1) did the OP install the RELH binaries, or compile his own? Sounds like he is on Ubuntu but used the precompiled binaries
2) Can anyone else think of why the OS might be preventing the fork process (with the permission denied) message? Perhaps there is something special on Ubuntu that doesnt let the app make the fork syscall?

Any help would be greatly appreciated.
TIA
Cheers
JB

[Jonathan]

Originally Posted by Jonathan

Hi, I also have a similar, if not the same problem with Dakota and OF.
Basically, when Dakota comes to forking the parent process for the individual runs, i get the

Fork application failure, aborting.
System error message: Permission denied

error. I am using Ubuntu, which is not supported as far as I could tell, so I compiled this from source, using WolfDynamics tutorials. I have run all the smoke tests and unit tests, on the comiled install, and these all appear to pass without any problems.

So i was wondering,
1) did the OP install the RELH binaries, or compile his own? Sounds like he is on Ubuntu but used the precompiled binaries
2) Can anyone else think of why the OS might be preventing the fork process (with the permission denied) message? Perhaps there is something special on Ubuntu that doesnt let the app make the fork syscall?

Ok, for anyone else wondering / struggling with this, the solution (for me) was to ensure that the

simulator_script.sh

which is called by the forking process was ... executable (duh!). Of course, you generally write this script yourself and i had forgotten to allow +x on it, so when Dakota tried to execute (via fork) it failed.

Glad is was something simple and not deeper in the code / compilation.