You are here

Bug with summary.MxModel in saved workspace

11 posts / 0 new
Last post
bwiernik's picture
Offline
Joined: 01/30/2014 - 19:39
Bug with summary.MxModel in saved workspace

I'm encountering an annoying bug with the summary.MxModel method.

When I open a saved R workspace that have MxModels saved it and load the OpenMx library, the summary() command doesn't work properly. Instead of running the summary.MxModel method, it just runs the generic summary method, giving something like:

    Length      Class       Mode 
         1 MxRAMModel         S4 

If I first open R, load OpenMx, then load the saved workspace into the environment, summary() works as expected.

Several other people in my lab have also encountered the same issue. I've not had the same problem with other S4 packages (e.g., lme4). Is there something I could do or that can be fixed in the OpenMx code so that the summary call works with saved workspaces? It would make my workflow a lot easier. (It's also been a frequent source of confusion for new users I've worked with.)

Thanks!

mhunter's picture
Offline
Joined: 07/31/2009 - 15:26
require(OpenMx)

I've encountered the same behavior. The solution you mentioned is the only one I've come up with: just write require(OpenMx) before looking at OpenMx objects. It seems like the R workspace is not saving the fact that OpenMx was loaded. Running a single line of code is not an onerous task for the fix, but I'm curious to hear if other developers and R experts have a better solution.

bwiernik's picture
Offline
Joined: 01/30/2014 - 19:39
The onerous bit is needing to

The onerous bit is needing to remember to open R and load OpenMx, then load the workspace, rather than being able to open the workspace from the OS directly. Yes, truly not that onerous, but does require a change in file management workflow.

Just wanted to raise the question in case any other R developers might have a better solution.

AdminHunter's picture
Offline
Joined: 03/01/2013 - 11:03
New Info

Ahh, well maybe I do have some new information. I've been able to open R workspace images directly from the OS (e.g. Windows File Explorer), then in the R session type require(OpenMx), then OpenMx summary and print methods work fine. To summarize the process: open workspace image, load OpenMx, OpenMx summary and print methods work for me. I have not needed to open R, load OpenMx, then load the workspace image to get these to work. That is, indeed, much more bothersome. Have you tried loading OpenMx after opening the workspace image like I described?

bwiernik's picture
Offline
Joined: 01/30/2014 - 19:39
Hmm. On macOS, that isn't

Hmm. On macOS, that isn't working for me. Whether using library() or require(), I still don't get OpenMx summary() to work correctly.

One thing I did try recently that works was to add the require() commands to my .Rprofile. This works (OpenMx summary works as expected), but is still a little annoying (but tolerable) as a OpenMx is quite a large package to have to load each time I start R (even when I'm not running SEM/IFA models).

AdminNeale's picture
Offline
Joined: 03/01/2013 - 14:09
Different version of OpenMx?

Running summary() on an incompatible earlier .RData saved object is not guaranteed to work. Possibly, this is the reason that you don't get it to work correctly. However, that scenario seems a bit unlikely if loading OpenMx before the mxModel object is loaded produces different results than loading it afterwards, assuming the same versions are loaded. Your "that isn't working for me" is a bit unspecific, so it's not easy to debug.

jcromley's picture
Offline
Joined: 01/24/2017 - 20:48
Bug in summary.MxModel still a problem (or again a problem?)

I am running the below version of OpenMx in R version 3.3.1, and I still get the uninformative summary
Length Class Mode
1 MxRAMModel S4

even when I try the fixes above (opening R first, require(OpenMx), etc.) this does not fix the problem. The models appear to be running, but I can't get the summary

OpenMx version: 2.7.4 [GIT v2.7.4]
R version: R version 3.3.1 (2016-06-21)
Platform: x86_64-w64-mingw32
Default optimiser: CSOLNP

> R.Version()
$platform
[1] "x86_64-w64-mingw32"

$arch
[1] "x86_64"

$os
[1] "mingw32"

$system
[1] "x86_64, mingw32"

$status
[1] ""

$major
[1] "3"

$minor
[1] "3.1"

$year
[1] "2016"

$month
[1] "06"

$day
[1] "21"

$svn rev
[1] "70800"

$language
[1] "R"

$version.string
[1] "R version 3.3.1 (2016-06-21)"

$nickname
[1] "Bug in Your Hair"

Thanks for any help, as I am teaching from the Grimm, Ram & Estabrook text and we will be using OpenMx soon!!!

neale's picture
Offline
Joined: 07/31/2009 - 15:14
Partial confirm but can get it to work on OS X

I can confirm most of the behavior jcromley reports, but for me
quit R (if it's running)
start R
library(OpenMx)
load .RData file
summary(AnOpenMxModel)

works fine. Attempting to summary the model before OpenMx is loaded, or loading OpenMx after the .RData file has been loaded fails with the uninformative summary about what the object is. That seems like a bug to me: OpenMx version: 2.7.4.5 [GIT v2.7.4-5-g0e2ecaf].

Note again that a change of OpenMx version between saving the .RData and loading it again can cause issues. OpenMx lacks backward compatibility with mxModel objects (especially ones that have been mxRun()) which is a pity. Typically the error in this case is even more cryptic, but different from the length/class/mode info one you have been getting.

AdminRobK's picture
Online
Joined: 01/24/2014 - 12:15
I observe the same behavior

I observe the same behavior, with:
OpenMx version: 2.7.4.40 [GIT v2.7.4-40-ge22a892-dirty]
R version: R version 3.3.1 (2016-06-21)
Platform: i386-w64-mingw32
Default optimiser: CSOLNP

Note again that a change of OpenMx version between saving the .RData and loading it again can cause issues. OpenMx lacks backward compatibility with mxModel objects (especially ones that have been mxRun()) which is a pity.

This should be much less of a problem with recent versions of the package than it has been historically.

jcromley's picture
Offline
Joined: 01/24/2017 - 20:48
This works in R, but not in

This works in R, but not in RStudio...very disappointing and frustrating for teaching purposes. I wish this bug would be fixed.

neale's picture
Offline
Joined: 07/31/2009 - 15:14
Very sorry for the

Very sorry for the inconvenience! We will investigate further at the developers' meeting tomorrow.

Log in or register to post comments