Unobservable states in RMark

posts related to the RMark library, which may not be of general interest to users of 'classic' MARK

Unobservable states in RMark

Postby JeffHostetler » Wed May 06, 2009 1:45 pm

I'm having trouble getting the multistrata framework with an unobservable strata to work in RMark, and I'm wondering if I'm doing something wrong. If I have two strata - one observable and one not - and run the following line:

Code: Select all
test = process.data(allData2, model="Multistrata", strata.labels=c('1','2'))


I get an error message:
Code: Select all
Error in process.data(allData2, model = "Multistrata", strata.labels = c("1",  :
 
Multistrata designs must have at least 2 strata


I tried adding a second observable stratum (so three altogether) and running this:
Code: Select all
test2 = process.data(testData2, model="Multistrata", strata.labels=c('1','2','3'))


Then I don't get an error message, but it also doesn't seem to register the third stratum.

Thanks,

Jeff
JeffHostetler
 
Posts: 13
Joined: Thu Sep 18, 2008 11:31 am
Location: Smithsonian Institution

Re: Unobservable states in RMark

Postby JeffHostetler » Wed May 20, 2009 3:19 pm

Jeff Laake helped me out with this one. He suggested a trick that gets around the problem. You can change one of the capture history records to include an observation from the unobservable stratum, process the data, then change the capture history back in the processed data:

Code: Select all
allData2$ch[1]='0000100002'
pd = process.data(allData2, model="Multistrata", strata.labels=c('1','2'))
pd$data$ch[1]='0000100000'


Jeff also let me know that a future version of RMark will be able to accomodate unobservable strata without this workaround.

Thanks,

Jeff
JeffHostetler
 
Posts: 13
Joined: Thu Sep 18, 2008 11:31 am
Location: Smithsonian Institution

Re: Unobservable states in RMark

Postby kpearson » Wed Oct 01, 2014 4:43 pm

Not sure if this workaround has been remedied, but I am also having trouble getting the multistrata model with unobservable states (2 obs., 8 unobs.) to run in RMark. Below is the error code I receive... It appears that when I try to restrict the number of Psi parameters (e.g. run a stratum model), the Mark output reveals that they were not restricted. Instead, each time I try to run a model, Psi parameters are always all different, regardless of how I structure the model. Both S and p parameters appear to be structuring correctly.

At line 4846 of file chprob.f90
Program aborted. Backtrace:

Fortran runtime error:
Program aborted. Backtrace:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Program aborted. Backtrace:
Index '0' of dimension 1 of array 'parm' below lower bound of 1
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Program aborted. Backtrace:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Program aborted. Backtrace:


Program aborted. Backtrace:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Error in if (loc[1] == -1) loc = regexpr(" = ", out[x]) - 1 :
missing value where TRUE/FALSE needed
In addition: Warning message:
running command '"c:/Program Files (x86)/Mark/mark64.exe" i=mark002.inp o=mark002.out v=mark002.vcv r=mark002.res threads=-1' had status 2

Problem extracting output. Look at MARK output file to see what is wrong.
kpearson
 
Posts: 5
Joined: Mon Sep 01, 2014 5:43 pm

Re: Unobservable states in RMark

Postby jlaake » Wed Oct 01, 2014 5:54 pm

The problem mentioned at the start of this post is not the issue because that involved a single observed stratum and you have 2. My guess from seeing the FORTRAN error is that the problem size choked the FORTRAN code. Psi is an mlogit parameter by default and due to the mlogit structure in MARK, mlogit parameters cannot be simplified fully and they are restricted via the design matrix. By looking at the MARK output I presume you mean the PIMS and they will not be restricted (ie they will be all different). Because they cannot be simplified the number of real parameters (and thus number of rows in the DM) can get very large with 10 strata and a decent number of occasions. This problem has been discussed in many different posts but I'll reiterate here. Your options are:

1) specify mlogit0=TRUE in call to mark (or mark.wrapper) if many of the transitions are fixed to 0. If not that will not help.

2) use link="logit" for Psi and use options="SIMANNEAL" (if needed to get convergence - will take awhile). MARK uses penalty to get probabilities to sum to 1.

3) if you don't need age (diagonals) or cohort (rows) effects then use pim.type="time" for Psi in make.design.data.

Each one of those can reduce the number of real parameters. I think that is it but if someone has another solution I've forgotten please chime in. You may want to check the other posts as well.

--jeff

--jeff
jlaake
 
Posts: 1480
Joined: Fri May 12, 2006 12:50 pm
Location: Escondido, CA

Re: Unobservable states in RMark

Postby jlaake » Thu Dec 11, 2014 2:18 pm

I met with Kristen and together we were able to discover the problem. It had nothing to do with lack of memory like I originally had assumed. With her Multistate structure she was able to use the logit link so it was a relatively small problem size. The problem was that she had used more than 2 characters for the strata values of the unobserved strata. Since they were unobserved and not in the capture history I can understand why she might think that was ok. Also I chose the unfortunate argument name of strata.labels suggesting that they were labels rather than strata characters. We never tracked this down with Gary but apparently if you specify more than one character for a strata, the mark.exe will fail. The MARK interface prevents you from using more than one character so there is no reason for mark.exe to expect otherwise. Once we changed it to use single character values all was well. MARK has strata characters and strata labels. The latter are not required to be single character whereas the former must be 1 character because they can be used in the capture history. I'll add code to check for this in RMark in the next version. In the meantime only use single characters.
jlaake
 
Posts: 1480
Joined: Fri May 12, 2006 12:50 pm
Location: Escondido, CA


Return to RMark

Who is online

Users browsing this forum: No registered users and 3 guests