Parallel performance

[janniklasrose]

If I recall correctly, a significant time is spent remapping the output of the parallel computation. This should be profiled to see if it's worth refactoring.

There is also a warning inside the parfor loop regarding func. This can be mitigated by introducing an anonymous function fn = @(i) func(i, varargin{:}); before the loop, but I'm not sure if this is the right way to go...

[ignasiialemany]

I have been looking at the parallel logic because I wanted to output the particles that go in and out of each myocyte. I have managed to obtain it but it was rather complicated to collect the data from all walkers. I wanted to modify the number of particles going in and out directly to the object handle class... but I found out that handle classes do not get the changes back to the client after the loop (Use Objects and Handles in parfor-Loops). I have been looking different answers and this one might be useful in the future (if it turns out that remapping is expensive)... I ended up remapping the output similarly to what is done but I will have another try when I have more time

[janniklasrose]

I would stay away from modifying the input objects just to sneak some additional outputs into them - instead, if you absolutely need time-history data (I'd also recommend against that, though) you can just create an additional output parameter. Since the remapping is far from elegant in its current state, I would actually say that outputs should be stored in a struct so that the number of outputs is constant and the parfor loop can be optimally used. During that refactoring, might as well change the inputs to a struct too.

structures_out = repmat(template_struct, [1, number_of_walkers]);
parfor i = 1:number_of_walkers
    structures_out(i) = execute(structures_in(i));
end

Collecting data is then as easy as output.FIELD = [structures_out.FIELD], which is definitely more efficient than the double-for loop currently used.