Building FullHet models

[jenmarie2478]

I have moderate experience with both R and MARK and decided on going the RMark route to avoid building design matrices with up to 25 columns (5 transects and 5 years in some cases).

Through the help files, this list (thank you Jeff for some initial help!), the appendix and workshop notes I think I'm getting the hang of it. I developed a script for all the models and ran it and it appeared to work.

But now I am getting concerned about whether I am building my models correctly. Hopefully I can find a few quick answers here:

1)
What is the difference between using the share=TRUE function? The example I've seen it was used to build a behavior model, but then it was also used on other models that did not have behavior which doesn't seem to make sense. For example:
p.time=list(formula=~time,share=TRUE)
p.time=list(formula=~time)

2)
Also I think I saw in the appendix that models can not be compared between model types? I'm wondering if it would be easier to build all my b, t and T models in Closed Captures then only use FullHet for heterogeneity models. Can I build a model table with them together?

3)Is Time (linear time) always built into the program? I ran a script last week with it that worked fine, but now this week with the same script but a new file it is giving me an error "Error in do.analysis() : object 'Time' not found"

While all the help files are great they are mostly CJS examples, so I'm struggling to find a lot of examples for Closed Captures or FullHet.

Any help would be greatly appreciated!

Jen

[jlaake]

Glad to hear the documentation is useful. Some answers below:

1) Pretty sure I've covered this before on the list but here goes again. In general, when RMark constructs a design matrix, it does so by constructing a DM for each parameter and then pasting them together such that they don't overlap columns and it adds 0's to fill the unused values. Typically this makes sense. You wouldn't use the same beta for Phi and p in CJS. In some cases the parameters are similar and it makes sense to use the same beta. The parameters p (initial capture prob) and c (recapture probability) in the closed models is one case where it makes sense to share columns. For any of these paired parameters, one is primary (eg p) and the other is secondary (eg c). When you set share=TRUE on the primary parameter, it appends the design data of the secondary parameter to the design data of the primary parameter and applies a single formula for both p and c. Note that there will be a field in the design data with the name of the secondary parameter and it will have the value 0 for the primary parameter and 1 for the secondary parameter so you can do things like ~time + c to have an additive difference over time for p and c. If you set or accept the default of share=FALSE then it will look for a formula for c or use the default of ~1. So if there were no c formula in your example, the first would fit time varying p and c where p=c. The second would fit time varying p and constant (~1) c. You can tell that by looking at the beta and real parameters that it is outputting.

2) All depends on the model. They have to have the same likelihood structure. You can tell which are compatible by looking in MARK under Pim/Change Data Type to see what models it includes. RMark will warn you when you create a model table from different types but does't know which should or should not be combined.

3) Time is defined in the design data for parameters where it makes sense. Look in the design data to see what is there. You can largely treat the design data as you would any dataframe. Look and see what is in the design data. You can add or modify design data. Except don't sort the rows and be careful with merge. Use merge_occasion.data if you are going to merge data to the design data and if it doesn't suit your needs mimic the code there so it will work for you. Usually you can just add design data with R code to assign values or you can use add.design.data for a limited number of things it can do.

--jeff