I'm trying to step through an OpenFOAM application (in this case, icoFoam, but this question is in general for any OpenFOAM app).
I'd like to use gdb to step through an analysis running in parallel (let's say, 2 procs).
To simply launch the app in parallel, I type:
mpirun -np 2 icoFoam -parallel
Now I want to step through it in gdb. But I'm having trouble launching icoFoam in parallel and debugging it, since I can't figure out how to set a break point before the application begins to execute.
One thing I know I could do is insert a section of code after the MPI_Initialize that waits (and endless loop) until I change some variable in gdb. Then I'd run the app in parallel, attach a gdb session to each of those PIDs, and happily debug. But I'd rather not have to alter the OpenFOAM source and recompile.
So, how can I start the application running in parallel, some how get it to stop (like at the beginning of main) and then step through it in gdb? All without changing the original source code?
Kindest regards,
Madeleine.
You could try this resource
It looks like the correct command is:
mpirunDebug -np 2 xxxFoam -parallel
Related
I have an application that can run commands in parallel. This application can work on a cluster using SLURM to get the resources, then internally, I assign each of the tasks I require to be performed by a different CPU/worker. Now, I want to run this application on my laptop (macOS) through the command line, the same code (except for the SLURM part) works fine with the only difference being that it is only performing one task at a time.
I have run code in parallel in MATLAB using the commands parcluster, parfor, etc. In this code, I can get up to 16 workers to work in parallel on my laptop.
I was hoping there is a similar solution for any other application that is not MATLAB to run other code in parallel, especially to assign the resources. Then my application itself is built to manage them.
If it is of any help, I run my application from the command line as follows:
chmod +x ./bin/OpenSees
./bin/OpenSees Run.tcl
I have read about GNU parallel or even using SLURM on my laptop, but I am not sure if these are the best (or feasible) solutions.
I tried using GNU parallel:
chmod +x ./bin/OpenSees
parallel -j 4 ./bin/OpenSees ::: Run.tcl
but it continues doing one at a time, do you have any suggestions?
I am running a MATLAB script at a cluster, having used the command
matlab -nodisplay <LocalVariation.m
I can now see that it is not going to finish within the wall time I have put. Is there any way that after I have ssh'ed to the node, that I can open up the running MATLAB instance, and stop it within the program, such that I get access to the variables it has produced so far?
It seems Matlab does not allow that unless you explicitly include it beforehand in your Matlab script. See this answer for instance.
Also it is always good to make your script 'checkpointable' so that you are able to restart easily from where the script was stopped.
Finally, a word about Octave, which has the option to create a dump of the variables automatically upon wrongful termination of the program.
Assuming you are using the SLURM workload manager you can try the following.
First open an interactive bash session using srun --pty bash -i. If you check your job queue using,squeue -u <username> you should find a bash session:
Now run your Matlab code with a breakpoint where you wish to stop execution. For example, a file runTestJob.m could look something like:
function runTestJob
A = rand(5);
B = randn(5);
keyboard; % add breakpoint
end
Now run code,
srun matlab -nodisplay -singleCompThread -r "runTestJob;quit"
This should give you a Matlab access directly in the terminal, so that you can use Matlab just like you would use it in the command window:
After you are done, make sure to close the interactive session and free up resources:
scancel <JOBID>
Hope that helps!
I am currently using the leaks command line utility on Mac OS X. It requires an active process which is a pain with a command line utility. Is there a way to launch a process and on exit freeze it (so it stays running) so leaks can work like the following
leaks executable_binary_name
instead of
leaks currently_running_process_name_or_pid
as the latter is a pain to use with a command line application that doesn't normally just remain open. I assume the program has to run through so leaks can observe the used memory and so I'd have to freeze it on exit.
Part of man page dealing with process
leaks requires one parameter -- either the process ID or executable
name
of the process to examine. It also takes several arguments for modifying
its behavior.
Use iprofiler (manpage) instead. It's the command line equivalent of Instruments and allows an executable or process ID to be specified.
Something like:
$ iprofiler -leaks -d $HOME/tmp executable [args]
You can even pass arguments to executable, if it accepts them.
The -d option specifies where the output .dtps file will be written to, which can be loaded into Instruments for examination.
On my old machine with gnu parallel version 20121122 after I
parallel -j 15 < jobs.txt
I see output of the jobs being run which is very handy for debug purposes.
On my new machine with parallel version 20140122 then I execute above-mentioned command I see nothing in the terminal.
From another SO thread I found out about --tollef flag which fixes problem for me, but soon it is to be retired. How do I keep things working after retirement of --tollef flag?
--ungroup (if half-lines are allowed to mix - as they are with --tollef).
--line-buffer (if you only want complete lines printed - i.e. no half-line mixing).
I'd like to type (at bash)
./start_screen.sh 3 some_cmd with parameters
and have it start up GNU screen with three separate, independent copies of the running command some_cmd with parameters running in bash in three separate vertically-split windows. What's the best way to do this? Does someone know how to put the pieces together?
(This is so I can run three worker daemons in the background and monitor them in one window.)
NOTE: alternatives to screen are just fine. In fact, at worst, it's ok if you can't interact with the windows apart from killing them all at once. (I mostly just want to see the outputs in parallel.)
screen executes commands from $HOME/.screenrc on startup by default.
You can override this with the -c option.
Create a temporary file with the commands you want, then run screen -c your-file.
This won't get the default settings you already have in $HOME/.screenrc unless you copy them to the temporary file.
(Disclaimer: I haven't tried this.)