You are here

Bug with summary.MxModel in saved workspace

19 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
Offline
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.

mithrandir82's picture
Offline
Joined: 04/10/2018 - 13:17
summary not working

Hello, have you find any clue about this bug? I still got it :(

summary(myModel1Run,refModels=refMods)
Length Class Mode
1 MxRAMModel S4

jpritikin's picture
Offline
Joined: 05/24/2012 - 00:35
do any other packages work like you want?

I'm skeptical that this is a bug that we can fix. Do you know of any other packages that work without being loaded?

mhunter's picture
Offline
Joined: 07/31/2009 - 15:26
Load the package first

Correct me if I'm wrong, but I thought the solution was to load the OpenMx package before you load the saved workspace. Then everything works fine. This seems like an easy-enough solution for users to implement. I acknowledge that having to be concerned about the order of these at all is annoying, but the fix is simple: load the package(s) first.

AdminRobK's picture
Offline
Joined: 01/24/2014 - 12:15
need to export S3 methods for derived S4 classes?

This specifically appears to be an issue with S4 object classes that extend the MxModel class. I believe only two exist in OpenMx, MxRAMModel and MxLISRELModel, of which MxRAMModel is by far the more frequently used. Compare the two attached scripts. If you run loadtest--181129b.R , quit R (after clearing its workspace if using RStudio), restart R, load the saved workspace, and run summary(factorModelFit), the summary() generic correctly uses the method defined for class MxModel (because OpenMx was automatically loaded with the saved workspace). On the other hand, if you run loadtest--181129.R , quit R (after clearing its workspace if using RStudio), restart R, load the saved workspace, and run summary(factorModelFit), summary() does not work the way it is supposed to.

Also notice that in both scripts, fm1, which is an instance of class merMod from lme4, works correctly with summary(). Class merMod differs from MxRAMModel in at least two respects. For one thing, merMod extends object classes from the stats package, and R's out-of-the-box default calls for stats to be loaded into R's workspace when R starts up. Second, merMod is an S3 class, not an S4 class.

FWIW:

> mxVersion()
OpenMx version: 2.11.5.78 [GIT v2.11.5-78-ge4567187-dirty]
R version: R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu
Default optimizer: CSOLNP
NPSOL-enabled?: Yes
OpenMP-enabled?: Yes
AdminRobK's picture
Offline
Joined: 01/24/2014 - 12:15
I do understand how obnoxious

I do understand how obnoxious to some users it must be to have to remember to load the OpenMx package before restoring their saved workspace. So, I tried again today to make it possible for summary() to work properly with an MxRAMModel object that's been loaded into R's workspace before OpenMx is. I consulted the 'Methods_for_s3' entry in the documentation for the 'methods' package, and followed as best I could its advice for dispatching S3 methods with S4 classes. All to no avail.

I think this issue must have something to do with how OpenMx constructs objects of class "MxRAMModel". I think it's significant that if you run str() on an MxRAMModel object, no associated package is reported.

AdminRobK's picture
Offline
Joined: 01/24/2014 - 12:15
good news (I think)

Good news: I think I've FINALLY figured out the cause of this bug!

AdminRobK's picture
Offline
Joined: 01/24/2014 - 12:15
workaround

It's looking pretty likely that this bug will be repaired in the next stable release of OpenMx. Until then, there's a workaround! For example, try running loadtest--181129.R, and let it save the workspace to disk. Then, restart R, and load the saved workspace. After that, run the following 3 lines:

foo <- "MxRAMModel"
attr(foo,"package") <- "OpenMx"
class(factorModelFit) <- foo

summary()will then work correctly on factorModelFit.

AdminRobK's picture
Offline
Joined: 01/24/2014 - 12:15
resolved

This bug is repaired in the v2.13.2 release, which was just announced today.