I am running a simulation in R. I generate my data within R then I use R to call a second program (which is called using the command prompt) to run my analysis on the generated data. The second program occasionally crashes and a pop up comes on the screen to close the program thus stopping the simulation in its tracks.
Is it possible have R recognize that the simulation has stopped because of the secondary program crashing and continue to run (i.e. Fork package)? Is this similar to the parent-child relationship I've seen described in c?
Thanks!
Related
I was running a spatstat envelop to generate simulations sample, however, it got stuck and did not run. So, I attempted to close the application but fail.
RStudio diagnostic log
Additional error message:
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information
There are several typing errors in the command shown in the question. The argument rank should be nrank and the argument glocal should be global. I will assume that these were typed correctly when you ran the command.
Since global=TRUE this command will generate 2 * nsim = 198 realisations of a completely random pattern and calculate the L function for each one of them. In my experience it should take only a minute or two to compute this, unless the geometry of the window is very complicated. One hour is really extraordinary.
So I'm guessing either you have a very complicated window (so that the edge correction calculation is taking a long time) or that RStudio is hanging somehow.
Try setting correction="border" or correction="none" and see if that makes it run faster. (These are the fastest choices.) If that works, then read the help for Lest or Kest about edge corrections, and choose an edge correction that you like. If not, then try running the same command in R instead of RStudio.
I am writing a script that needs to be running continuously storing information on a MySQL database.
However, at some point of the day I will like to produce some summary of the data being colected, but writing this in the same script will stop collecting data while doing these summaries. Here's a sketch of the problem:
while (1==1) {
# get data and store it on the relational database
# At some point of the day (or time interval) do some summaries
if (time == certain_time) {
source("analyze_data.R")
}
}
The problem is that I'll like the data collection not to stop, being executed by another core of the computer.
I have seen references to packages parallel and multicore but my impression is that they are useful to repetitive tasks applied over vectors or lists.
You can use parallel to fork a process but you are right that the program will wait eternally for all the forked processes to come back together before proceeding (that is kind of the use case of parallel).
Why not run two separate R programs, one that collects the data and one that grabs it? Then, you simply run one continuously in the background and the other at set times. The problem then becomes one of getting the data out of the continuous data gathering program and into the summary program.
Do the logic outside of R:
Write 2 scripts; 1 with a while loop storing data, the other with a check. Run the while loop with one process and just leave it running.
Meanwhile, run your other (checking script) on demand to crunch the data. Or, put it in a cron job.
There are robust tools outside of R to handle this kind of thing; why do it inside R?
I am doing several Bayesian analyses using R2WinBugs so I can put them in a for-loop. It works perfectly, R calls WinBugs, then the simulation starts and when it is done the results are saved and the next analysis starts.
When I normally use WinBugs, without R, I can monitor the simulations already done in the update screen so I roughly know how fast it is going and how long it will take to finish. My question is: Is there an option with R2WinBugs, or maybe a different package, to call WinBugs in for loops and still force WinBugs to show the progress made?
I hope my question is clear :)
I don't think it is possible using R2WinBUGS. You can set debug=TRUE to follow the simulations in WinBUGS itself, but it will mess up your for loop as you will then need to quit WinBUGS manually after each model run.
BRugs shows the same progress as a WinBUGS log file,... as in you can run the model check, initialise parameters, compile the model and update the simulations with output printed in the R console.
I have an R script that I need to understand better - what it's doing, why it's doing what it's doing, etc. Problem is, I'm not familiar with R. I am, however, familiar with Matlab. So I'm hoping there's a way to port this R script into Matlab such that I can run through this R script in a way how to use different software.
I don't just want to run the R script and have the output sent to Matlab for further use, I want to be able to open an R script in Matlab and be able to treat it like a .m script.
Failing that, at least some way to run through the R script (using R in Windows) that doesn't involve stepping through every single line in debugging and then having to type print([variable name]) at every step to see what the function did.
I am running some large regression models in R in a grid computing environment. As far as I know, the grid just gives me more memory and faster processors, so I think this question would also apply for those who are using R on a powerful computer.
The regression models I am running have lots of observations, and several factor variables that have many (10s or 100s) of levels each. As a result, the regression can get computationally intensive. I have noticed that when I line up 3 regressions in a script and submit it to the grid, it exits (crashes) due to memory constraints. However, if I run it as 3 different scripts, it runs fine.
I'm doing some clean up, so after each model runs, I save the model object to a separate file, rm(list=ls()) to clear all memory, then run gc() before the next model is run. Still, running all three in one script seems to crash, but breaking up the job seems to be fine.
The sys admin says that breaking it up is important, but I don't see why, if I'm cleaning up after each run. 3 in one script runs them in sequence anyways. Does anyone have an idea why running three individual scripts works, but running all the models in one script would cause R to have memory issues?
thanks! EXL
Similar questions that are worth reading through:
Forcing garbage collection to run in R with the gc() command
Memory Usage in R
My experience has been that R isn't superb at memory management. You can try putting each regression in a function in the hope that letting variables go out of scope works better than gc(), but I wouldn't hold your breath. Is there a particular reason you can't run each in its own batch? More information as Joris requested would help as well.