Inconsistent Divide by Zero Error – Robust Design

[cbrown]

We ran robust design models using Rmark on two different computers. One computer is getting this error on every model in the same place in the log. The other computer does not get this error.

* * WARNING * * Divide by zero occurred during optimization of this model.
IEEE flag status at end of optimization:
overflow F
divide by zero T
invalid F
underflow F
inexact T

Main Questions:
1. Why might this be happening?
2. Is it important?
3. If it is important how might we solve it?

The Details:
- This is happening on every model (like >50 different runs), including with different input data (e.g., multiple models for different sites). So it is not a one-time thing. It seems systematic.

- The only difference is that the computer with the error is running Mark Version 10.1 (March 2023), whereas the other computer is running an older version 9.0 (Jan 2019). R, Rstudio, Rmark versions are the same. The code is the same-we checked many time.

- We found this in the Mark Change Log (March 2016) which might partially explain. BUT, it is weird that the error is showing up in every model, even the simple models, and in the same way. It seems systematic.

"260. Floating point numerical issues (underflow, overflow, and divide by zero) are now reported as warnings in the MARK output. Overflows and divide by zeros should be considered serious errors, and output checked carefully for non-sensical values."

- The estimated statistics and parameters are functionally the same, with a few slight differences at 3-4 decimal places.

- The numbers I think are associated with the optimization process are sometimes different. (though I may not know what these numbers are)

- The data are a long time series (18 years) with mostly small numbers of individuals each year (~10-20) and high probability of capture (>0.5 usually and can be higher). But it is also happening on sites with large numbers of animals (>100).

- I have seen this error before, placed in different parts of the log and always when another problem occurred (like singular parameters). Never in a systematic way like this.

More Questions:
4. Does the following suggest that as long as numbers are not ‘non-sensical values’ then we are ok?
“divide by zeros should be considered serious errors, and output checked carefully for non-sensical values”

5. I am not exactly sure what floating point numerical issues mean in this context. Does it mean the models didn’t converge or run properly?

All help is much appreciated!

[gwhite]

Just uploaded the latest versions of the markxx.exe files to my web site. If you get a divide by zero or an overflow, please send me the input file.

Gary

[cbrown]

Ok, I will download the new version and try again with that.