Closed rich-iannone closed 7 years ago
Sure, I'm used to both. I've been using data.table
lately since I've been working with some data sets that are big enough that there's a difference, but I agree with you that these aren't at that point yet. Do you have access to my implementation? What I've been working on is in the parallel
branch at the moment -- you probably have a better way to implement but there might be something helpful there
@jdossgollin I've skimmed through it but will definitely have a closer look at what you did. I just have a hunch that using dplyr might set up SplitR better for the future since it has a few extra features. One thing I'm missing with the ensemble runs is multiple heights, so I will work that in. I'll test out the timing of this and compare with the data.table method.
I'll also update the README with an example of runs as an ensemble.
Finally, I've started work on a function (create_grid
) to generate a grid for a matrix/ensemble run.
OK cool, let me know how I can help! I think that a grid is a good approach because it both works pretty well from a programming point of view and is easy to understand for users. The only thing I used parallel runs for was to run each different event in parallel -- if people are running just one event (starting date) back, then there may be no need.
@jdossgollin Ensemble runs are available with recent versions of SplitR. Simply use same-length vectors for latitude and longitude and all of those runs will be done at the same time.
For speed I know you mentioned
data.table
is what you went with in your implementation. Would you be okay if I explored the use ofdplyr
? It's just as speedy, plus we can work withtbl_df
data frames which have other advantages as well.