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!

[jlaake]

This is a question for the MARK forum because that is a message from MARK. It is likely to be difference in versions of MARK.

[cbrown]

Ok, I 'll post it there. I didn't see how to post on the general Mark site, but I will figure it out. Thanks!

[gwhite]

You're correct that I added the WARNINGS about divide by zero, underflows, overflows, etc. and these warnings started showing up.

I spent some time several months ago tracking down important ones, particularly the divide by zeros, and fixed those bugs. Interesting that one of them was caused by the compiler doing a little too much optimization and generating code inside an if statement that was checking to avoid a divide by zero. Adding the -fno-unsafe-math-optimizations flag to the compiler fixed that one, and probably some more that I hadn't tracked down. My guess is that the divide by zero that you mention as "systematic" is this one.

There was one overflow error I encountered when running my 183 test datasets, and I fixed it

I also removed lots of the underflows, which in general are not critical. I found most of these that you'll encounter are from the Gauss-Hermite integration models, and occur because the integrations in the tails of the distribution are basically underflows. These can be ignored.

So I hadn't put the revised code on the web yet because I've been doing other overhauls to improve code readability and function. I'll put the new executables on my web site, and I think Evan will make them available shortly.

If you now encounter a divide by zero or an overflow, send me the input file so that I can track then down.

Gary