Updated DoRun_prc

[Daniel Gates]

Greetings all,

I've added my doRun_prc to the trunk. With it I have a few questions for the treevo experts:

Mostly I'm curious about the boxcoxOneSimSumStats (bcOSSS) object in the doRun_prc step. What exactly is the role of this?

I see that in the first abc_prc step it's used immediately after its created to find the newparticleList[[1]]$distance but what is confusing to me is that in later abc_prc steps (in dataGenerationStep 2+) it's no longer being recalculated with every new particle evolution step. What these steps do is just use the last bcOSSS calculated from the first abc_prc step. The particles in generations 2+ seem to be doing just fine while they're all using the same value for the bcOSSS object and they run FAST (as in 4.359 seconds compared to 866 seconds).

I guess what I'm wondering is if this is the case then do we need to be calculating bcOSSS for every particle in step 1 or could we just calculate it once and reuse that value (like in steps 2+)?

Part of the reason I'm bringing this up as well is that it's currently embedded within my object that I'm farming out to multiple cores so it's not being returned to the parent from the children nodes and currently I'm recalculating it once more to then use in the subsequent data generation steps (which makes my datageneration 2+ particles and results different from the older doRun_prc version that I've replaced).

Also if this is the way that it's supposed to be I may need to think about whether parallelization will really be necessary on the 2+ data generation steps...



Any insight you can give me into the nature of this would be most appreciated!

Cheers!
-Dan

[B.Banbury]

Hi Dan,

Good catch, somehow there was a missing line for recalculating the boxcoxOneSimSumStats in >2 gens.  I re-added the line back in and committed changes, so hopefully it will make sense now.  In general, boxcoxOneSimSumStats boxcox transforms the summary stats from a single simulation.  This gets used in calculating distance between that and boxcoxed original summary stats. It was running so fast, since it was missing the simulation step.  I think parallelizing is still a good idea, since now it will take longer.  

It is (unfortunately) possible that these will change again. We still need to make sure that the prc is doing what we want it to do (we really haven't tested it fully--hence the issue here!).  I don't think it should impact the merger, or if it does, it shouldn't be too hard to change again.  

Anyway, definitely a good catch and let me know if anything doesn't make sense.  

Barb
______________________
Barb Banbury
Postdoctoral Research Associate
Ecology and Evolutionary Biology
University of Tennessee, Knoxville