the bootstrap example from ctmm using question

[zeng jinyuan]

Hello,

I am trying to estimate home-range confidence intervals using ctmm.boot() and have encountered a parallelization issue that I have been unable to diagnose.

The workflow is:

GUESS <- ctmm.guess(DATA, interactive = FALSE) FIT <- ctmm.select(DATA, GUESS, trace = 3) BOOT <- ctmm.boot(DATA, FIT, cores = -1)

The model fitting step completes successfully, and ctmm.boot() also runs successfully when:

ctmm.boot(DATA, FIT, cores = 1)

However, whenever I use internal parallelization (cores > 1) on Windows, the bootstrap fails immediately with:

Error in checkForRemoteErrors(val) : object 'Green' not found

I investigated whether the issue was related to the data or fitted model, but both appear to be valid:

• ctmm.select() completes successfully.

• ctmm.boot(..., cores = 1) runs normally.

• The same dataset and fitted model can be used successfully in other workflows.

To further investigate, I implemented an alternative strategy using future.apply, where the outer bootstrap iterations are parallelized while each worker runs:

ctmm.boot(DATA, FIT, n = 1, cores = 1)

This approach runs successfully on both Windows and Linux systems, suggesting that the bootstrap procedure itself is valid and that the problem may be specific to the internal parallel implementation used by ctmm.boot().

In addition, I tested the original code on Linux using:

ctmm.boot(DATA, FIT, cores = -1)

and the bootstrap was able to start and progress beyond 50%, whereas the Windows version failed immediately.

My questions are:

1. Is object 'Green' not found a known issue related to the Windows parallel backend used by ctmm.boot()?

2. Does ctmm.boot() use different parallel mechanisms on Windows and Linux?

3. Given that external parallelization via future_lapply() works correctly, does this indicate that the issue is specifically within the internal parallelization layer of ctmm.boot()?

4. For the gazelle example dataset and an OUF model, is a runtime of approximately 36–40 hours for the external-parallel bootstrap workflow within the expected range?

Thanks for your help.

[Christen Fleming]

Hi Jin,

Parallelization is different in UNIX and Windows because Windows lacks the capability to fork processes and has to use sockets instead. The Windows sockets don't seem to copy over the global environment like UNIX fork does, and so they complain that objects in the global environment are missing. If you really need to run this in Windows, then I can take a second look at how the parallelization is implemented and pass some arguments so that frequently used objects are not stored in the global environment.

The expected run time is approximately 1/error^2 times the computation time of ctmm.fit() - very slow!

Best,

Chris