Running Opensim parallel

[Sina Porsa]

Hi Sherm,
I have implemented your suggestion but I do still have the same problem of memory leak.
As you can see in my previous post, at each iteration I make so many new objects such as PiecewiseLinearFunction, PrescribedController, system, integrator, manager , etc. I was wondering maybe these classes have the same problem (memory leak)?
Thanks.
Sina

[Michael Sherman]

Very possible. The situation may be improved in OpenSim 3.0 but I suspect there are still many memory leaks. If you can determine that a class is leaking it would be worth filing a bug report to ensure that it gets fixed.

Regards,
Sherm

[Tom Lintern]

Hi Sina,

I was wondering if you had found any solutions to your memory leak problems? I am having similar issues in my program where I am running an optimizer and updating the model within an objective function. To access some of the methods, I need to remove and delete a set of analyses and forces each time the objective function is evaluated. A memory leak then occurs which causes the optimization to fail after a number of iterations.

I was wondering if you had any issues using some of the opensim destructors as when I try to use some (eg the pointkinematics and bushingforce class), a runtime error results.

I would be interested to hear if you made any progress with your problems.

Cheers
Tom

[Sina Porsa]

Hi Tom
I had the same problem with destructors.
In my research, I am trying to add a new controller to the model at each iteration to generate a movement. I am using 8 cpus and i solved the problem as below:

Code: Select all

Model OsimModel_00 ("2D9M.osim");
Model OsimModel_01 ("2D9M.osim");
Model OsimModel_02 ("2D9M.osim");
Model OsimModel_03 ("2D9M.osim");
Model OsimModel_04 ("2D9M.osim");
Model OsimModel_05 ("2D9M.osim");
Model OsimModel_06 ("2D9M.osim");
Model OsimModel_07 ("2D9M.osim")
.
.
.
if (omp_get_thread_num()==0){
    //add the controller to OsimModel_00
    // Calculate the cost
    // removethe controller from OsimModel_00
}
if (omp_get_thread_num()==1){
    //add the controller to OsimModel_01
    // Calculate the cost
    // removethe controller from OsimModel_01
}
...

I know it is not a good way to solve this problem. But it is better running out of memory!!

[Tom Lintern]

Hi Sina,

Thanks for your reply. Sorry how did you manage to delete the controllers after each iteration if you said you had problems with the destructors? My problem is that I can't delete some model elements which I presume is the reason for the memory leak.

Are you just saying that you use an entire new osimModel for each variation in the controllers?

Cheers
Tom

[Sina Porsa]

To remove the controller :
OsimModel_00.removeController(muscleController);

[Sina Porsa]

based on your previous post, I assume you want to create a NEW analysis at each iteration, which leads to memory leakage.
What I can suggest is this:

1- create a base analysis
2- modify the base analysis
3- add the modified version to your model and perform the calculations
4- undo the modifications
5- go back to line 2 to perform a new modification on your analysis

This way, you will create an analysis only once (@ first line) and hopefully it solve the memory leak problem.

[Ayman Habib]

Hi All,

I just wanted to mention that we're aware of the problem and working on a fix for it though it's unlikely that all leaks will be fixed in release 3.0 that's coming soon.

I also wanted to clarify that crashes and memory leaks are usually two different creatures (well, unless the crash is happening because you're running out of memory). The likely reason for crashes on destruction is memory management. Current API assumes that when you add an object to the model, it takes ownership of it, (we're renaming the methods in 3.0 to make this more clear) but for now I'd suggest when you add objects to the model that these objects be heap allocated with "new" rather than on the stack (without new or by passing the address of a local variable). This guarantees that the object is not "deleted more than once" (by going out of scope and by the model destructor).

Hope this helps,
-Ayman