-
Notifications
You must be signed in to change notification settings - Fork 4
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
read_samples returns incorrect results for samples from previous run #57
Comments
Hi Chris, got this message pretty late yesterday evening (I'm currently traveling in Europe) so just took a look. Two quick questions: When you run the 2nd part, the first process is still running? That is pretty dangerous. I have no idea how the timing of the (in your example 4) processes that create the 4 chains is or if the .csv file are in a suitable state to be read. Also, am I correct you run this MWE in an environment with all these packages installed and in the directory where |
Rob, no problem. I hope you are enjoying Europe. Let me backup and explain my goal. I have a long running model and I would like to re-load the samples into a different session as a chain to avoid re-running the model. So to answer your first question, the first process has completed. My understanding is that it should be safe to re-load the completed chain with |
Hi Chris, If I understand your example correctly, that works for DataFrames but not for MCMCChains:
which produces:
The 2nd set of values produced by MCMCChains are bogus. Is that indeed the issue? The .csv file is still unchanged as seen when read in as DataFrame or analyses using read_summary. |
Hi Rob. That is indeed the issue. I did not test DataFrames, but your example show that it works. For some reason, mcmcchains is incorrect on the second read. |
Yip, at least the summary produced by MCMCChains. The other part of your question, how many draws are you trying to collect? The bogus |
I am trying to collect 1000 per chain, for a total of 4000 samples. The output for mcmchains does not provide an estimate of n_eff/s. Here is what it provides on the first run:
Given that the model runs quickly, I would suspect n_eff/s is several orders of magnitude larger than ess. |
My remark was based on "I assumed the benefit of reading the samples was the ability to re-load results from a long running model". So I assumed your actual runs take 10s of minutes or even hours and you wanted to know after say 400 iterations if the results looked ok. A few years ago I had such a case and I decided to collect a limited number of draws (after warmup) and append the DataFrames collected from subsequent (newly started) runs. If this is feasible of course depends on num_warmups required, the time it take to complete warmup, etc. |
I see how looking at interim results could be helpful. In my particular case, I have a hierarchical model that takes a long time to run (30 - 90 minutes). What I was hoping to do was have a way to read in samples from a previous completed model run in case I wanted to modify a plot or run additional analyses days or weeks later. Is that a unintended use of |
We should be able to simplify below function and generate a quick table (a3d_array) and associated column names (cnames) and show the same problem:
|
No, that is perfectly feasible (provided you store the results in a tmp dir as you do in your example and hold on to or recreate the SampleModel object. In the above example I can did recreate a new SampleModel (sm_02) and it works fine:
Same result. So the problem is really why the new MCMCChains object is not correct. |
The main difference is whether |
But we're not calling `stan_sample()'. I'll try above MWE idea in creating an a3d_array for 2 parameters. |
I'm getting:
and output:
|
Extending the MWE to 4 chains also shows
Interesting! |
Ok, found a clue. Reading in the draws as an array:
produces:
Must be a bug in |
Very interesting indeed. I'm glad you found a clue. Thanks for taking the time to look into this problem. |
Ok, found it. It happens when the SampleModel is recreated. The various ..._num_chains settings are updated when stan_sample() is called. Probably introduced when I enabled C++ threads. Not sure how quickly I can fix this, might have to wait until I'm back in the US later this week. For now, a workaround is to set |
Awesome. Thanks for the workaround. I will use that until you return and have time to look into it. |
Hi Chris, There was a bug in the handling of the default case for SampleModels (4 chains, Julia processes). I'll fix that. But in case the defaults are updated when calling
For this purpose I'll add Serialization to the dependencies for StanSample.jl in the next release (v6.10.1). In your case, you used the defaults in your MWE, so that will work out of the box in v6.10.1. |
c7a425a Allow JSON data as a string (#60) 50fe2ec Update README examples section e380e82 Reword docstrings fb513e3 Reorganize and update documentation (#57) 96805fd Compile methods: split stanc args from make args, add default include path (#58) f62bf46 Fix broken link 676db6b Bump actions/setup-python from 2 to 4 (#55) 34f10dd Remove CmdStan Dependency (#51) 821883f Prefix any C-exposed symbols with `bs_` (#54) 81129b0 Add the option for autodiff Hessian calculations (#52) git-subtree-dir: deps/data/bridgestan git-subtree-split: c7a425aac54120bafa643b722ed24b2a32111782
Hi Rob,
read_samples
returned incorrect results when I tried to re-load a chain from a previous run of a model. I assumed the benefit of reading the samples was the ability to re-load results from a long running model. Here is a MWE:Start a new session and run everything except for the sampler:
Results
Note that rhat is wrong.
Version
The text was updated successfully, but these errors were encountered: