-
Notifications
You must be signed in to change notification settings - Fork 5
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
Control of parallel computation using fasterFragmentation() #24
Comments
Hi Simon, Thanks for your kind words and your message. Some of the behavior you noted is expected and some is not. The The other behavior, with multiple hidden R sessions running is very odd--I see you can get quite a lot! It's possible that I did not call
It's also possible that if you close the R session you manually started, but it created some child R sessions, that the children are still running. On my machine they "die" soon after I close the parent, but they might keep running in vain. If that's the case, I suggest either stopping the processes manually or (sorry) restarting your computer. Thanks again, |
Hi Adam, thanks for reaching back so swiftly, and thanks for all these explanations! Here is the output of
Here are the suggested chunk sizes of my
I installed the @cores branch As far as I can see, the odd behaviour did not change (see the two new .pngs), it's still running > 20 child R processes. It's (very) late here now, I'll let it run over night and report back tomorrow, we'll see if it ran through on the laptop. Thanks again, |
Hi Simon, Again, sorry for the trouble! Frustratingly, I am unable to recreate the problem on the two machines (both Win 10) I have available to me. I did search StackExchange under all entries for "R snow" but the only thing I found that was relevant was someone not being able to stop child workers when the children were on a different computer from the one they were called from, which I don't think is related to your issue. However, I did try de-anonomyzing the child worker function in If this doesn't work, I could redo Adam |
Hi Adam, No problem, it's great that you are so strongly committed to fix this issue! Update on the @cores branch (
Update on @cores3 branch (
The hardest part appears to be the connectivity calculation, but the excessive R child processes appear to be started during both the density and connectivity calculations. This behaviour was on my Mac book (Catalina, 4 cores, 16 GB RAM). I could try both side branches on the desktop computer if it helps, just to make sure it's not a weird behaviour on a particular computer. I'm confident that evetually, I'll manage to get the calculations done for all the rasters, just takes some patience and maybe some "manual" calculation of forest connectivity and fragmentation class. I've also tried running Thank you and best wishes, |
Hi Adam, I let the computer work over the weekend and all fragmentation calculations have successfully run through for 7 forest cover maps (same extent, derived from 7 different years of satellite images). They ran at constantly high numbers of R child processes during the density and connectivity calculations. The many (>20) child processes did not disappear with any On my end, I'm quite happy with the result at the moment, and I can now proceed with a sampling of training / test data and deforestation location modeling. However, if fragmentation class turns out to be an important predictor of deforestation probability, then I'd need to run the At the moment, I don't dare to run the calculations on a shared high-performance cluster, given the unusual behaviour and the generation of so many R child processes. I begin to understand why these sorts of calculations have probably not yet been attempted for very large rasters, but mainly for defined smaller areas :) Best wishes, |
Hi Simon, Well, I'm glad it worked! I still don't know why so many processes spawned. It it wasn't stopping the child processes, from what you told me, it should have at most spawned 12 of them all total, but you were getting many more than that. I won't close this issue since it's not resolved, but since I can't reproduce it on my Windows machines I can't resolve it easily. Thanks again bringing my attention to this. Adam |
This function has been superseded by |
Hi Adam,
It's super nice to have
fasterRaster
for work involving large raster files! Projection and similar calculations always take so much time using theraster
package, even when usingbeginCluster()
, so thank you very much for this great tool!I saw some unexpected behaviour when doing parallel computing with
fasterFragmentation()
using specific arguments forcores
andforceMulti
.Typically, the program starts normally (using a single core for 1-2 minutes). Then, the parallel processing kicks in and typically runs at nearly 100% total CPU usage (but runs many (>20) individual processes, each with low %CPU) until the computer needs to "cool down" again for 1-2 minutes, and kicks back into parallel processing. On my best computer, the computation ran through after 5 hours but this behaviour caused an R session interruption on my laptop (4 cores, 16 GB RAM).
cores = 3
andforceMulti = FALSE
?fasterRaster
, or is the issue in the evokedsnow
orparallel
packages?Here are two .png screenshots of my activity manager (CPU consumption) during the function execution.
I can send you the raster to try and reproduce the behaviour, I've seen a similar behaviour on Mac, Windows and Linux OS.
Thanks again and best wishes,
Simon
##############################
Here is the code:
This is how the input raster looks like (it has NA, 0, 1 values):
Here is my computer info:
Here is my session info:
The text was updated successfully, but these errors were encountered: