-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time out when waitForJobs #4
Comments
I have no technical issue with setting the time limit to infinity. One idea is to set global batchtools-related options, as to not pollute the function arguments. A longer term goal of mine is to migrate to the futures/futures.batchtool package so that all parameters can be passed in to the user, via the futures API. However, I think the larger problem is that it's taking longer than a week for even a single huge run to complete. You can see our published timing results the whole pipeline took 6056 seconds for p=2000, n=2000. I'm wondering if you can try further filtering the data, just so we can rule out system or data problems more quickly. Thanks! |
I think is a combination of my data and the parameters I am using. I already calculated smaller versions of the matrix (p=955) and it was calculated fast with mb and glasso using lambda.min.ratio of 1e-2 and 1e-3. Many thanks! |
At risk of telling you something you already know... the StARS solution will not find a denser matrix by lowering Pretend for a moment that we can sample continuously along the lambda path between l_min and l_max, we compute a graphical model and estimate variability at each value of l. StaRS will always select the same l_stars, just as long as l_min <= l_stars <= l_max. StaRS selects lambda such that the average edge stability is 0.05 (in the SpiecEasi setting, 0.1 in the original StaRS paper), a number which doesn't depend on the lower/upper bound of lambda you happen to try. Raising [ as an aside: since we're not sampling continuously, we instead choose the l_stars associated with the graph with the largest variability that is not over However, I'm not convinced that your network is all that sparse. For p=4000 a network with a sparsity of 96% has 319920 edges |
Hi Zach
In addition, the target stability threshold was quite far away from the |
Hi,
the time limit for the batchtools waitForJobs function is 604800 seconds. I haven't seen a way to tell Pulsar or the SpiecEasi pulsar branch to increase the time other than modifying the source. Now, it fails with:
Maybe a solution would be to set it to Inf or to implement a way to resume Pulsar/SpiecEasi running jobs using the batchtools registry (sorry if this already exists).
Many thanks
Antonio
The text was updated successfully, but these errors were encountered: