RMark version 1.9.2

[jlaake]

The new version of MARK (July 09) has the capability to import data/output from RMark. A new function export.MARK is now included in RMark that writes out a .Rinp file with the necssary parameters to define the model to MARK, the .inp file with the data and optionally any output files that should be imported into MARK. This should prevent the problems where folks have unknowingly changed the group structure or other aspects of the problem in creating the MARK project to import the RMark results. This caused some folks to get discrepancies. With this export/import facility the data/model structures will match between MARK and RMark. Also, it will import a whole set of model results rather than importing them one at a time with MARK. Note that you do need to delete the .tmp files manually after importing them into MARK.

Please report any problems with this new functionality to the forum.

regards --jeff

[dhewitt]

Just a follow-up to Jeff's announcement for any fence-sitters...

If you've been thinking of diving into RMark, most (all?) worries about moving away from the MARK GUI should dissolve with this new functionality. You can work happily via RMark and when needed pop over to MARK for things like median c-hat for your global model. I used the new functions to transfer a large and decently complex set of CJS models. It worked flawlessly and took only a couple minutes.

[dhewitt]

Hopefully this will prevent some headaches for someone in the future...

Note that with the new export.MARK() function in RMark, you need to be careful in naming the project; that is, the project.name argument to the function. If you have a project that uses a typical MARK style input file (INP), such as those you convert in RMark with convert.inp(), be careful not to name the project for export with that same name as the INP file if you also use replace=T (such as when you are messing around with different formulas for a model and then exporting to check in MARK). If the name of the INP file and the project.name argument are the same, your original INP file will be overwritten with the INP to be used by MARK on import. You don't necessarily care about that exported INP, it is simply needed by MARK to import your project, but that one will become the new INP in your working directory. The structure of that INP is not necessarily the same as your original, and from that point on your script in RMark will operate on the new and potentially incorrect INP file. And this is not case sensitive. So, an INP in your working directory named either "myINP.INP" or "myinp.INP" will be overwritten if you offer the project.name argument as "myinp" or "MYINP".