Pour les professionnels de l’informatique >
Forums - Accueil
>
Windows HPC Server V2 Pre-RTM
>
Parallel Debugger with Beta2 and VS2008
Parallel Debugger with Beta2 and VS2008
Is anyone successfully using the parallel debugger with the V2 Beta? I'm following the "Basic Usage of VIsual Studio 2005 Parallel Debugger" document, start the "empty" job in the job scheduler, and then when starting debug from VS get message:
"Aborting: Access denied by "HPC-1".
mpiexec is attempting to use this node which was not allocated to job '14.0' by
the Microsoft HPC Scheduler..."
The job running (14) is configured to use the node in question, and shows it allocated to the node. I'm suspecting something needs to be different for V2 Beta and VS2008, but not sure what. Help appreciated.
Roger
Réponses
- Roger,
Usage of the parallel debugger has changed a little in the v2 product. Although there are a couple of approaches you can take, I would recommend using the job scheduler to start up the debugging session. To do so, navigate to the Debugging section of the project property pages and set the fields as follows:
- Debugger to launch: MPI Cluster Debugger
- MPIRun Command: job
<comment> job is the command you will use to submit work requests to the job scheduler. Use job instead of the standard mpiexec.exe here.</comment> - MPIRun Arguments: submit /workdir:<my dir> /requestednodes:<node list> /scheduler:<my head node> /numcores:<number of cores> /stdout:<file1> /stderr:<file2> mpiexec
<comment> This is everything else you need to tell the job scheduler up to and including the command for mpiexec. </comment>
<comment> <node list> is a coma separated list of node names (i.e., node1,node2,node3). </comment> - MPIRun Working Directory: <blank>
<comment> You have already specified this in the above MPIRun Arguments when you provided the path for /workdir. </comment> - Application Command: <full path to application, including application name>
<comment> This is either a network share or the same location on each compute node. </comment> - Application Arguments: <any arguments for your application>
- MPIShim Location: <full path to mpishim.exe, including the name "mpishim.exe">
<comment> Be sure there are no space characters in the path to mpishim.exe. </comment> - MPI network security mode: Accept connections from any address
- MPI network filter: <blank>
- Put mpishim.exe in the specified location.
- Visit each node specified in the <node list> and start msvsmon.exe. Be sure the "bit-ness" of your application matches the "bit-ness" of msvsmon.exe.
If everything is set up correctly you should now be able to launch an interactive debugging session by pressing F5.
Good luck,
Robert- Modifiérobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:44spell check
- Marqué comme réponserobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:52
- I've discovered Joe Hummel's tutorial at http://www.pluralsight.com/blogs/drjoe/archive/2008/06/19/51178.aspx that provides a different approach than manually launching the empty job as per the older documents, and appear to be getting further with that. Not quite there yet, but hopeful.
- Marqué comme réponserobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:52
Toutes les réponses
- I've discovered Joe Hummel's tutorial at http://www.pluralsight.com/blogs/drjoe/archive/2008/06/19/51178.aspx that provides a different approach than manually launching the empty job as per the older documents, and appear to be getting further with that. Not quite there yet, but hopeful.
- Marqué comme réponserobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:52
- Roger,
Usage of the parallel debugger has changed a little in the v2 product. Although there are a couple of approaches you can take, I would recommend using the job scheduler to start up the debugging session. To do so, navigate to the Debugging section of the project property pages and set the fields as follows:
- Debugger to launch: MPI Cluster Debugger
- MPIRun Command: job
<comment> job is the command you will use to submit work requests to the job scheduler. Use job instead of the standard mpiexec.exe here.</comment> - MPIRun Arguments: submit /workdir:<my dir> /requestednodes:<node list> /scheduler:<my head node> /numcores:<number of cores> /stdout:<file1> /stderr:<file2> mpiexec
<comment> This is everything else you need to tell the job scheduler up to and including the command for mpiexec. </comment>
<comment> <node list> is a coma separated list of node names (i.e., node1,node2,node3). </comment> - MPIRun Working Directory: <blank>
<comment> You have already specified this in the above MPIRun Arguments when you provided the path for /workdir. </comment> - Application Command: <full path to application, including application name>
<comment> This is either a network share or the same location on each compute node. </comment> - Application Arguments: <any arguments for your application>
- MPIShim Location: <full path to mpishim.exe, including the name "mpishim.exe">
<comment> Be sure there are no space characters in the path to mpishim.exe. </comment> - MPI network security mode: Accept connections from any address
- MPI network filter: <blank>
- Put mpishim.exe in the specified location.
- Visit each node specified in the <node list> and start msvsmon.exe. Be sure the "bit-ness" of your application matches the "bit-ness" of msvsmon.exe.
If everything is set up correctly you should now be able to launch an interactive debugging session by pressing F5.
Good luck,
Robert- Modifiérobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:44spell check
- Marqué comme réponserobert.palmerMSFT, Propriétairejeudi 26 juin 2008 16:52
- Joe's tutorial is very similar to what I have suggested here. Please do let us know if you are successful.
- Thanks Robert - yes, that was the trick. On last thing, I seem to be unable to redirect the stdout even though I put a /stdout in the submit line. If I'm also doing lots of printf's in my code for debug purposes, I'd sure like a way to get them all to a merged file. Is there a best practice for this?
Currently there is no way to redirect the IO that I am aware of. You might try doing explicit file IO instead of writing your error messages to stdout.
