model.average() error

[brian.folt]

I am working with a colleague on a known-fate analysis of telemetered turtles over an 11 year period under three treatment groups and with time-varying body size. My colleague fit 10 models using RMark (various combinations of effects of group, size, time, and some interactions) and then model-averaged the real coefficients using model.average().

I tried to recreate the analysis, but I received the following error.

> res.modavg <- model.average(results, vcv = FALSE, drop = FALSE)
Error in compute.real(model, design = model$design.matrix, se = TRUE, :
Input design matrix must only have numeric values. Use find.covariates and fill.covariates to fill in covariate values

To find a solution, I tried various things. I tried digging into the design matrix, and looked at it's structure; the object, which is produced by 'make.design.data()', looks like this:

List of 2
$ S :'data.frame': 18 obs. of 8 variables:
..$ par.index : int [1:18] 1 2 3 4 5 6 7 8 9 10 ...
..$ model.index: num [1:18] 1 2 3 4 5 6 7 8 9 10 ...
..$ group : Factor w/ 3 levels "1","2","3": 1 1 1 1 1 1 2 2 2 2 ...
..$ age : Factor w/ 6 levels "1","2","3","4",..: 1 2 3 4 5 6 1 2 3 4 ...
..$ time : Factor w/ 6 levels "2022","2017",..: 2 3 4 5 6 1 2 3 4 5 ...
..$ Age : num [1:18] 1 2 3 4 5 6 1 2 3 4 ...
..$ Time : num [1:18] 0 1 2 3 4 5 0 1 2 3 ...
..$ group : Factor w/ 3 levels "1","2","3": 1 1 1 1 1 1 2 2 2 2 ...
$ pimtypes:List of 1
..$ S:List of 1
.. ..$ pim.type: chr "all"

But I didn't really know what to do.

One thing that stood out to me was when I restricted the models to remove any models with the time-varying body size covariate, then the model.average() calls work.

To better diagnose the issue, my colleague sent me their .Rdata for a successful session when the code ran to entirety, which included all of the objects that were produced by functions. I loaded these data and, using the objects produced by my colleagues script/RMark/MARK, the model.average() function works fine. However, when I re-run the model estimation set with my version of MARK (which I downloaded yesterday morning), the model.average() calls fail. My suspicion is that there may be a detail associated with new version of MARK, where it produces a file structure format that does not work well with the most recent version of RMark's model.average() function.

I am using a brand-new M2 Mac and the most recent version of MARK. My colleague is using an Intel Mac and likely a two-year old version of MARK, but we are having a hard time identifying version numbers for his MARK. We are both using the same version of R and RMark. We shared the outputs produced by MARK when model-fitting; while all the calculations and model structure look the same (BIC, DIC, AIC, deviance, etc.), some of the structure of those outputs (the text that runs through the R console while models are being fit) differ.

If anyone knows how to solve this problem, that would be of great interest to us. Thank you!

[cooch]

I am using a brand-new M2 Mac and the most recent version of MARK. My colleague is using an Intel Mac and likely a two-year old version of MARK, but we are having a hard time identifying version numbers for his MARK.

See fourth paragraph in the following 'sticky': viewtopic.php?f=2&t=4433

If you're using a M1- or M2-based Mac, you're SOL. Sorry, but Apple's continued attempt to build the walls around its private garden ever higher have made trying to keep compiling for Macs a growing problem (and this isn't a MARK-only problem. I know a fair few open source devs that are stuck in similar positions. Apparently, we're supposed to buy all the different flavours of Apple products just to keep up. I know at least one high-end symbolic math dev who has basically given up trying to support Apple at all...)

About the only thing you can try (that I know of) is using Rosetta, which can, in theory, run apps compiled for Intel-based Macs on Apple Silicon-based Macs.

As for what version -- its printed out at the top of a MARK output file. For example, in the following, v. 10, compiled Aug 2022:

Program MARK - Survival Rate Estimation with Capture-Recapture Data
gfortran(dble/PIM2) Vers. 10.0 Aug 2022 13-Aug-2022 12:11:30 Page 001

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Welcome to MARK gwhite on machine euler.dnr.cornell.edu in subdirectory
"/home/gwhite/MARK/SRC" running file "billbig.inp".
This version was compiled by GCC version 11.2.1 20220127 (Red Hat 11.2.1-9) using the options:
-cpp -D_REENTRANT -D IEEE -D DBLEPRECISION -m64 -mtune=generic -march=x86-64
-O3 -std=f2018 -fimplicit-none -ffpe-summary=invalid,zero,overflow,underflow
-fsignaling-nans -ffast-math -flto -fall-intrinsics -fopenmp -fpre-include=/usr/
include/finclude/math-vector-fortran.h.

This problem will use 4 of 4 possible threads.
Static thread allocation is used.
Schedule kind is omp_sched_dynamic with chunk size 1

[cooch]

Or, since OS/X is built somewhat/kind/sort of on top of UNIX, it might support this from a terminal prompt in the directory where the MARK executable installed. IN the following (on one of my Linux-based machines), the following generates version information:

Code: Select all

strings ./mark64 | grep Vers.


>> strings ./mark64 | grep Vers.
gfortran(dble/PIM2) Vers. 10.1 M 10.1 March 2023

So, its version 10.1.

[cooch]

As for what version -- its printed out at the top of a MARK output file. For example, in the following, v. 10, compiled Aug 2022:

Whoops -- I meant, 'code base set Aug 2022, but the actul executable compiled 13-Aug-2022. First date after the 'Vers.' string is the date the code itself was last changed/updated. Date after that is the date said code was compiled into an executable.

Program MARK - Survival Rate Estimation with Capture-Recapture Data
gfortran(dble/PIM2) Vers. 10.0 Aug 2022 13-Aug-2022 12:11:30 Page 001

[brian.folt]

Thanks Evan. In my haste with original post (sorry), I forgot to mention two other details. We created reproducible environments using R package 'renv' so that we both used the same R package versions. Then to test whether it was an Intel vs. Silicon issue, I tried running it with my personal Intel Mac and the current version of MARK. This effort also resulted in the same error. So, in summary:

Silicon M2 Mac, MARK v10.1, same R package versions including RMark (me) - error
Intel Mac, MARK v8? v9?, same R package versions including RMark (colleague) - works
Intel Mac, MARK v10.1, same R package versions including RMark (me) - error

This pattern suggests maybe it is an incompatibility between v10.1 and the lastest version of RMark.

Or maybe I just don't know how to dive into the design matrix or resulting model list appropriate to change the covariates... I of course tried looking at help() files, but couldn't figure it out.

[jlaake]

If you will send me the data and code to jefflaake@gmail.com, I'll run and debug into code. But if this is a mac issue, I won't be able to help.

[jlaake]

Wasn't a mac issue. There was a change in the MARK output format which my code wasn't smart enough to handle so it wasn't extracting the average covariate values from the output and thus couldn't put these into the design matrix which caused the error. This has been fixed and I have put patched version on my google drive. Eventually I'll get this to CRAN. Please let me know if you are finding any other problems with the new version of MARK.

Below is a link to a binary zip file for Windows users

https://drive.google.com/file/d/1-9yC1uRmZzbHLTQZmBzp0VaaSpR38N8D/view?usp=drive_link

For others this is a link to tar.gz file
https://drive.google.com/file/d/1-9STmNndROYLs_ZDYwg7_24U9KjHGel8/view?usp=drive_link