running pyFoam(Plot)Runner.py in parallel
 

Hello everybody!

I have troubles starting a case in parallel (only local on one machine with multiple cores). If I type
within my case I receive this error message:
It doesn't work with any possible option. (--autosense-parallel, --procnr=N)

The weird thing is:
Without the parallel options (thus on a single core) pyFoamRunner.py works properly!
And on top:
If I start a parallel run "manually" with
it works without any problems, too!

Does anyone know, what to do? I really like pyFoam an would like to use it furthermore. Thanks an advance.


Regards
Sebastian

Hm. That is strange. The first warning says that "which simpleFoam" doesn't find an executable. And then it says that there is also no environment variable FOAM_MPI_LIBBIN (which may be OK for newer OF-installations. But then comes the weird part: the missing MPI_B and UFFER_SIZE (which it thinks that it is the executable) should be one string.

I think there is something problematic with the settings:
http://openfoamwiki.net/index.php/Co...yFoam#Settings

Check with pyFoamDumpConfiguration.py and look for the [MPI]-section. It should look somehow like this:
(especially MPI_BUFFER_SIZE should be one string)

To check which call to mpirun is actually used you can add this configuration option (will also print a lot of other things):
If MPI_BUFFER_SIZE looks OK in your configuration then I'm a bit surprised. What shell ("echo $SHELL") do you use?

This is working for me with OF-2.2 and PyFoam-0.6.0:
I even have the pipe-tee in there working to get the log. The 12 is because I am hyperthreading on an i7-3930k, and for some reason (maybe my specific setting) it works better than just 6 cores.

The tee is superfuous: pyFoamPlotRunner.py will automatically generate a file PyFoamRunner.mpirun.logfile. And usually the --proc=X options work quite fine and can be easily adapted with the configuration options if they're not working on your system. The problem that Studi has is that one of the options automatically passed to mpirun is "broken" (the options can be quite useful when the mpirun starts the run on two different physical machines as some environment variables are then not passed to "the other side")

Hello gschaider!

Direct hit with first shot! Yesterday I have edited the pyfoamrc file to get things working on different machines over network. I deleted the changes again and now it works.
There are two warnings again (see appending log), but the solver starts nonetheless.
I've read about the deprecated parameter on the openMPI homepage, but as long as it is working, this won't be any of my concerns. The same applies to the FOAM_MPI_LIBBIN.
Of course any suggestions for improvement are very welcome nevertheless!

Thanks a lot for helping me with this issue!

Reminding me of parallel computing with different machines: Is it necessary to distibute the according data on every node (with copying data on every node or via NFS)? I've read about MPI, that it can't "push" the data itself to every node automatically...


Regard
Sebastian

The hardcoded options are not necessarily the best, only the ones that worked for me on most machines. But you can easily override them (even on a per-OF-version basis if you have different MPIs for different versions)

Every processor has to be able to "see" its processorX-directory. If they're all in the same NFS-directory and every node can access that then you're fine. Problem is that for a large number of processors NFS might be the bottle-neck and you'll want to distribute these directories onto multiple machines. But I haven't done that and would suggest you ask elsewhere on the Board

which can't find my solver
 

I have created my own solver which is based on solidDisplacementFoam in 2.3.x. I get the first warning that has been shown above:
I am concerned regarding the implications of this warning.

Thanks in advance.

If it runs then everything is fine. The main purpose of this warning is to give a hint if the solver is really not found

The code is able to find my solver. However, it does not run as it should. I tried replacing my modified solver (convergeFracWidthFoam) with solidDisplacementFoam and the code worked using this command:
as well as this code:
where the object CONVERGED is a custom LogAnalyzer object.

However when I replace solidDisplacementFoam with convergeFracWidthFoam in either of the above options, the code does not go through the iterations. In fact for the BasicRunner case it gives me the following error:
The code works without the decomposition though.

I understand that this is a problem of creating a solver that can run in parallel. Can you help me out here?

I'm pretty sure that PyFoam is not the problem here: it just starts the OpenFOAM-solver (which it obiously did) in parallel (which according to your output worked too). After that it just waits for the output of the program. If you run your program without PyFoam (mpirun -n 3 convergeFracWidthFoam -parallel) you'll see the same behaviour.

My guess is that it is the common DidASumCalculationAndDividedByItWhichFailsInParall elBecauseOnOneProcessorTheSumIsZeroAndIDidntDoARed uce-bug. But it is hard to tell from your output because it is from a Release-version: before you do anything else compile yourself a Debug version. Stack-traces are much clearer (they even include the line numbers of where the problem occurred) and a lot of common errors are uncovered because of the bound-checking

similar error message
 

Hi I use PyFoam for parametric evaluation (it's an amazing tool I'm only just figuring out).

So I have scripted a series of templated cases for my custom solver. The output I get everytime throws a "hoping for the best" warning error:

But the solver inevitably executes correctly. However, (as you can see above) I just returned to the office to find that PyFoam had hung at the end of exedution. My log looks like this:

...


I think the that seg faults it causes PyFoam to hang.

So like is there any option I through to PlotRunner to just continue through into the next case after that seg fault?

Because the seg fault is at the end of the run so I dont care. That would be hecca useful. (I am worried that it'd be default behavoir, but somehow it doesn't happen for me. Like the story of my life).

Thanks, Eric

PS I use this config: