MARK simulations can't open RMark models?

[Eldar]

Hello,
I've found a strange problem:
I am creating an *.Rinp file (multistrata, recaptures only). It contains some models.
Mark is able to open it correctly but not to set up a simulation. I figured out that:
1. if make.mark.model(...,simplify=T) - Mark simulation module cannot understand number of parameters for true model.. with any button pressed it crushes.
2. if switch to ...,simplify=F - it eats model as a true model, but with lost fixed parameters..
PS - I can see that all of the parameters are in the file. Mark just is not able to read them correctly.

Is there any way to send RMark model design to Mark simultaions/true model module?

[bacollier]

Eldar,
Honestly, I am not sure if you can pull a .inp like that in and run simulations, never done it before.

Not surprised with your results in 1, using simplify=TRUE changes the design data in RMark so it is not directly transferable to MARK.

Can you provide more details/code as it is hard (for me, maybe not others) to deduce or debug your 2 and what you are doing without a reproducible example.

Bret

[Eldar]

Dear Jef, thanks for the idea to write a simlple example of the problem - it helped. Doing this I figured out how to solve my problem!
In short the way to send RMark multistrata model to Mark simulations module is following:- design.matrix has to be "identity" and simplify design matrix =F.
Mark will say that there is no parameters fixed - but it is OK, as they are not in beta values (here is a place I stuck yesterday..)
There is also a possibility to set up betas from RMark - the general way is to modify betas in ***Y.tmp in exported model - Mark will suggest beta values from this file..
I can publish a code with explanation if needed...

Eldar

[jlaake]

Eldar-

I've been in the field away from email. Send me an example of what you are trying to do. The simplify=FALSE may be a little dicey as I've not continued to check that option with all of the additions I've made since going to the default of simplify=TRUE. I considered removing it as an option for that reason. It may explain the problem with the fixed parameters but if I had an example I could test. Bret was partially correct in his response. With simplify=FALSE, it uses the all-different PIMS for each PIM. If simplify=TRUE, it starts with a all-different PIMS, but after applying the formula to create the DM, it works out which rows of the DM are unique and then it renumbers the PIMS and shrinks the DM to the unique rows. Gary could actually implement this in MARK with coding but it isn't something we have discussed. The reason for using simplify=TRUE, is that it the models run faster and it allows larger models to run that wouldn't run otherwise. If you specify a formula without an intercept you can use an identity DM. I'm not sure why MARK is requiring an identity DM and because I've not used the simulation module I'm not sure how it is different. Can't you tell MARK to use a model that it has in its results file for the simulation model? If so then you could import an RMark model into MARK and then use it.

regards --jeff

[Eldar]

Dear Jeff,
Thanks for the reply,
I am Ok now with the simulations - they run correctly and without errors...
I checked other possibilities and will try to formulate the story now.
A. Your questions:
a) I double checked and confirmed that only simplify = F works for Mark simulations. For identity matrix the only difference between make.mark.model(..., simplify=T) and make.mark.model(..., simplify=F) are in $links and $input lists (checked with identical())
b) I work with inentity matrix because it is the easiest choise to set up simulations betas.
c) Yes, I can export rMark model -> import to Mark database -> import to Mark simulations database. All of the problems happen with the second arrow.

B. The code:
1. We need to generate dummy dataset (let it be "d") with number of occasions and stratas we are interested in (I wrote simple function for this)
2. process data: dat<-process.data(d, model="Multistrata")
3. create ddl: des.data<-make.design.data(dat)
4. fix parameters, e.g.:
des.data$S<-des.data$S[!c((des.data$S$time)=="1" & des.data$S$stratum =="A"),]
des.data$p<-des.data$p[!c((des.data$p$time)=="1" & des.data$p$stratum =="A"),]
des.data$p<-des.data$Psi[!c((des.data$Psi$time)=="1" & des.data$Psi$stratum =="A"),]
5. make mark model:
mymodel<-make.mark.model(dat, des.data, parameters=list(S=list(formula=~-1+stratum),p=list(formula=~-1+stratum), Psi=list(formula=~-1+stratum:tostratum)), simplify=F)
6. run analysis:
mymodelres<-run.mark.model(mymodel)
7. export model:
export.MARK(dat, model=mymodelres, "mydatabase", replace=T)
8. Import to Mark (and don't close the database)
9. Run simulations/set up simulations/True model and then button "Results database"
10.If I had a model that was generated with simplify=T - a) Mark will generetate an error and close the window or b) it will show you next screen with ".. parameters fixed" - but if you will press any button -> a).
If simplify was set to FALSE - Mark will say that there are no parameters fixed but it is correct as they are not in betas (I am not sure I can describe this correctly) and you can set up your simulation..
11. If you will change betas in ...Y.tmp - Mark will suggest you to use these betas for simulation - this very helpful.

PS I also wrote a function that provides some interactive graphical interface for structural zeroes defining in multistrata models. Would you like to have a look?

Best,
Eldar

[jlaake]

Eldar-

Thanks for your post. It is helpful. I would be interested in the structural zero code. Send to me individually. Have you seen the TransitionMatrix function in RMark? I'm going to ask Evan to move this thread to the RMark subforum.

--jeff

[egc]

I've moved this thread to the RMark subforum (since it is focussed on Rmark)