title: OpenBUGS fails to converge on model that converges in WinBUGS. Precision limit?
body: <p>As the title of this post says, when I try to run code and data that work fine in WinBUGS from R using <code>BRugsFit</code> (with <code>coda=T</code>), I get these errors:</p>
  
  <pre><code>Error in glm.fit(x = structure(c(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,  : 
    NA/NaN/Inf in foreign function call (arg 1)
  In addition: Warning messages:
  1: glm.fit: algorithm did not converge 
  2: glm.fit: algorithm did not converge 
  3: glm.fit: algorithm did not converge 
  4: glm.fit: algorithm did not converge 
  5: step size truncated due to divergence 
  </code></pre>
  
  <p>When I do <code>tail()</code> on the coda object, I get the same numbers over and over. On the other hand, when I run WinBUGS, save the coda, and load it into R, I get some stochastic variation like I would expect, and no warnings about convergence.</p>
  
  <p>Here is my model (it uses the 'ones trick' to find the posteriors for the parameters of a Logistic-Makeham distribution).</p>
  
  <pre><code>model {
      for(i in 1:n){
              ones[i]&lt;-1;
              # here I pre-calculate two quantities that occur several times 
              # in the PDF, to save a little processing time
              expbx[i] &lt;- exp(b*x[i]); expbx1[i]&lt;- 1/(1+sd*(expbx[i]-1));
              # below is the actual PDF
              p[i]&lt;-(c+a*expbx[i]*expbx1[i])*exp(-c*x[i])*pow(expbx1[i],1/s);
              # the ones trick
              ones[i]~dbern(p[i]);
      }
  b~dunif(0,1); d~dexp(1); c~dexp(1); s.raw~dflat();
      # a (lambda) parametrized this way because it comes out more accurate
      # s forced to be &gt; 0
      a&lt;-b*d; s&lt;-abs(s.raw);
      # NOT a standard deviation, just s times d, to save processing time
      sd&lt;-s*d;
      # I save all the parameters I'm interested in to one vector, for convenient
      # viewing of them all in the same window.
      out[1]&lt;-a; out[2]&lt;-b; out[3]&lt;-c; out[4]&lt;-s; out[5]&lt;-d;
  }
  </code></pre>
  
  <p>Here is a typical example of my data:</p>
  
  <pre><code> list(n= 148 ,x=c( 1246,1175,1048,1169,1043,802,543,719,1296,817,1122,542,839,443,1536,700,834,232,596,1096,1118,957,974,1031,1149,1044,1108,
  519,677,569,952,1243,970,1736,1262,1026,979,1543,1029,761,533,540,511,1150,1589,1169,1029,1248,1572,638,731,525,968,1467,1596,1077,712,1603,1
  203,991,37,1775,893,993,913,1487,1186,1381,977,1247,857,786,615,733,1206,1059,1508,569,1205,754,886,1099,843,599,780,1294,1603,1242,883,1320,
  507,1097,1193,218,1362,1181,1118,453,1291,972,787,1061,1097,1100,1117,1174,596,1305,1071,940,919,999,1209,1043,1161,1016,1025,750,423,732,
  1389,907,1184,1275,944,1209,1073,1098,1348,976,817,557,211,961,880,1039,1287,736,1400,1757,1355,977,198,689,853,1251,767,768 ))
  </code></pre>
  
  <p>...and typical inits (I use 4 chains, thinning 20, burnin 2000, 20000 iterations)</p>
  
  <pre><code>list( d=0.001738,b=0.0009672,c=0.002451,s.raw=0.001511 )
  list( d=0.006217,b=0.005596,c=0.00777,s.raw=0.007019 )
  list( d=1.504E-05,b=4.825E-06,c=2.172E-07,s.raw=6.104E-05 )
  list( d=0.3011,b=0.03552,c=0.1274,s.raw=0.2549 )
  </code></pre>
  
  <p>Does OpenBUGS simply round off to fewer significant digits than does WinBUGS, and if so, perhaps there is a setting I can change to make it stop doing that?</p>