When submitting an nmbayes model, we set the seed to the chain number, discarding any seed value the user may have set in the BAYES/NUTS estimation record.
Ignoring the user's value entirely doesn't seem like a good approach. On the other hand, we can't take the user value as is because we need it to be chain-specific (which is why, I assume, the original version of run_chains() from the expo used the chain number).
I suggest we should do what cmdstan does [*]: it takes the user-specified seed (scalar) and adds the chain number (so the seed for a given chain is {user seed} + {chain number}). If the caller didn't include the seed, we should probably fall back to NONMEM's default of 14455.
(In an internal issue, @timwaterhouse said he'd lean toward being consistent with cmdstan.)
[*] ... at least that's my understanding/recollection. This should be verified.
When submitting an nmbayes model, we set the seed to the chain number, discarding any seed value the user may have set in the
BAYES/NUTSestimation record.https://github.com/metrumresearchgroup/bbr.bayes/blob/a4f84fbe2a09e9113ec0706201175834e0ff15f8/R/submit-model-nmbayes-helpers.R#L114-L116
Ignoring the user's value entirely doesn't seem like a good approach. On the other hand, we can't take the user value as is because we need it to be chain-specific (which is why, I assume, the original version of
run_chains()from the expo used the chain number).I suggest we should do what cmdstan does [*]: it takes the user-specified seed (scalar) and adds the chain number (so the seed for a given chain is
{user seed} + {chain number}). If the caller didn't include the seed, we should probably fall back to NONMEM's default of 14455.(In an internal issue, @timwaterhouse said he'd lean toward being consistent with cmdstan.)
[*] ... at least that's my understanding/recollection. This should be verified.