DOI-USGS / DOI-USGS/streamMetabolizer
Switch to CmdStanR
- Dominant language
- Stan
- Stars
- 47
- Forks
- 25
- PR merge metrics
- No merged PRs in 30d
Description
1. The migration will break how get_mcmc() behaves — currently the function returns a rstan::stanfit object. The rstan methods (summary(), get_stancode(), etc. ) work on this object. I can't find any package's function that converts a CmdStanMCMC object --> rstan::stanfit object and writing this would take a lot of effort. An updated get_mcmc() could return the CmdStanMCMC object, which also has a set of associated methods/functions.
We're leaning toward: Clean break after migration, with error message (get_mcmc() would now return CmdStanMCMC object, error if given a metab_model with rstan::stanfit) and point to the updated docs for how to work with CmdStanMCMC objects.
2. Unlike rstan, CmdStanR doesn't bundle Stan — users need to call cmdstanr::install_cmdstan() separately after installing the R package. At minimum I'd add an error message from metab_bayes() if CmdStan isn't found. The question is whether we should go further, adding a helper function like install_stan() that wraps cmdstanr::install_cmdstan(). This could be called on its own, or conditional in metab_bayes() if CmdStan isn't found, with a message.
We're leaning toward: error message from metab_bayes()
Contributor guide
Research direction
The main entry points are get_mcmc() and metab_bayes(); begin by tracing their current return behavior and CmdStan availability checks. Confirm the clean-break behavior for rstan::stanfit inputs and the missing-CmdStan case, then update the documentation for CmdStanMCMC workflows and verify both error paths.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- data
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100