Hi Frank,
Can you please provide me with any advice regarding debugging OpenSeesSP and OpenSeesMP. I am currently using gdb while running OpenSeesSP sequential so that is relatively straightforward. However, I am unclear about doing the same with mpirun. Help on this topic in the internet is relatively limited but I thought you would have had to do a lot of debugging, how did you go about it? Your help is much appreciated. If it is quite complicated just give me an idea about OpenSeesSP or at least were to get more information.
Regards
Debugging OpenSeesSP and OpenSeesMP
Moderators: silvia, selimgunay, Moderators
Re: Debugging OpenSeesSP and OpenSeesMP
a lot of times i resort to the age old solution of just spitting out messages from the code (opserr << "Truss::setTrialStrain - ele " << this->getTag() << " " << strain << endln) or if the problem is in a certain one: (if (this->getTag() == 3465) opserr << "Truss::setTrial .. blah blah blah"). i always put the method or proecdure in the output so that i can find these output messages later! of course it helps that i know the code inside out and so know what the program stack is going to be at any time a problem manifests.
when necsessary, a debugger on the sequential code, visual studio or gdb (lately i just use the visual studio). the sequential debugging is used to find most of the bugs in the code.
debugging in parallel is a royal pain. when i can, i narrow it down to the offending class (i.e. it fails to run for some model, swap out a material for something similar and it works for that) and it is then figuring out why the ObjectBroker does not create the correct class or the send/recv of the class is not working. as mentioned, the sequential debugging catches pretty much all bugs associated with theory, and such .. if the class can send/recv itself and the object broker can create it the only problem lies in theory which sequential running will also hit)
some classes are more painful, those which require communication between objects on different processes (recorders, file handlers, solvers) and of course other commands added after the original design was done (the material stage update for example) by people who only thought about a sequentual implementation.
here i must admit the age old solution is tried first, if it fails and i have to resort to a parallel debugger i use something called DDT that is available on the NSF parallel machines that i have access too. The interface to DDT is a GUI, kinda like visual studio.
for parallel applications i use one of the NSF machines and a debugger called DDT.
when necsessary, a debugger on the sequential code, visual studio or gdb (lately i just use the visual studio). the sequential debugging is used to find most of the bugs in the code.
debugging in parallel is a royal pain. when i can, i narrow it down to the offending class (i.e. it fails to run for some model, swap out a material for something similar and it works for that) and it is then figuring out why the ObjectBroker does not create the correct class or the send/recv of the class is not working. as mentioned, the sequential debugging catches pretty much all bugs associated with theory, and such .. if the class can send/recv itself and the object broker can create it the only problem lies in theory which sequential running will also hit)
some classes are more painful, those which require communication between objects on different processes (recorders, file handlers, solvers) and of course other commands added after the original design was done (the material stage update for example) by people who only thought about a sequentual implementation.
here i must admit the age old solution is tried first, if it fails and i have to resort to a parallel debugger i use something called DDT that is available on the NSF parallel machines that i have access too. The interface to DDT is a GUI, kinda like visual studio.
for parallel applications i use one of the NSF machines and a debugger called DDT.
Re: Debugging OpenSeesSP and OpenSeesMP
Much appreciated. Fortunately I've just learned that we have DDT on our cluster so will start using that for debugging in parallel.