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.
Related
I am developing an iterative algorithm that uses quantile regression models at each iteration. For that I use the rq function from the quantreg package in R. So far it has worked fine. However, I have found a dataset where, at one of the iterations, the rq function simply gets stuck. No error message, no warning. It simply goes on as if still working, but never finishes computation.
I provide here a very small minimal code example. You can download the problematic data on this link:
https://www.dropbox.com/s/yrlotit1ovk9yzd/r555.RData?dl=0
library(quantreg)
load('~r555.RData')
dependent = r$dependent
independent = r$independent
quantreg::rq(dependent ~ -1 + independent, tau=0.1)
If you execute the above mentioned code, the rq function will get stuck and never finish. Be aware that the data provided is part of the iterative process I am developing, so it has no direct interpretation by itself. I am writing to check for possible reasons on this behaviour and check for possible solutions.
Dont know if it matters, but I have tested this on two different computers running Windows10 and using different versions of the quantreg package.
Changing the default method="br" to method="fn" fixes the problem.
quantreg::rq(dependent ~ -1 + independent, tau=0.1, method="fn")
Someone has script examples for integrating R and Dymola,
I want to perform Monte Carlo Simulations in a Dymola model
the main idea will be performing an uncertainty analysis regarding the integration of renewables into the system.
we have a calibrated model of a building which is heated by a gas fired boiler, and we are going to implement a solar collector and a biomass gas fired boiler and check the probability of x% of the energy demand to be covered by the integrating y% of renewables
But I am struggling to learn how I can make R sample, call my model and analyse the results
I do not have experience with R
Can anyone help me?
thanks
I have no experience with R but Dymola offers the following possibilities to remote control it:
Python
Java (Script)
DDE e.g. from MATLAB
Some others that don't seem relevant for this case (can be found in Dymola Manual 2 Section 6)
There is no possibility to call it directly from R as far as I know. What you can do as well is call dymosim.exe directly and modify the dsin.txt to get your parameters in the model.
From my experience I would tend to use the Python interface. Probably a good way could be to combine R and Python as presented here: https://www2.warwick.ac.uk/fac/sci/moac/people/students/peter_cock/r/rpy
In addition to the possibilities listed by Markus Andres, there is another method which is used quite often:
Calling the Dymola.exe the path to a .mos script as first argument.
Dymola will start up and immediately execute the .mos script.
A minimal .mos script would be:
openModel("<path-to-model>/MyModel.mo")
simulateModel("MyModel")
Modelica.Utilities.System.exit()
Note that you can not interact with Dymola using this method, so the exit() call is crucial. If the exit() call is not reached for whatever reason, the Dymola.exe will continue to run as idle process and you have to kill the process from R.
The Dymola User Manual Volume 1 also mentions this feature briefly in the section Parameter studies by running Dymola a number of time in “batch mode” and gives some hints how to log messages and set the result file names.
I am using the stepAIC function in R to run a stepwise regression on a dataset with 28 predictor variables. The backwards method is working perfectly, however the forward method has been running for the past half an hour with no output whatsoever this far. I believe it is to do with how I'm defining the scope attribute. Without the scope it runs instantaneously however only one step is run and no changes are made to the initial model.
Bstep.NNN.top<-step(lm(Response~X1+X2+X3+X4+.....+X28,data=df),
scope=list(upper=Response~X1*X2*X3*.....*X28,lower=Response~1),direction=c("forward"))
Does anybody know of a method that is quicker to run? Or if there is a way to simplify the scope attribute to a point where the run time will decrease?
Thanks
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!
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.