Ensure OpenMx is the package associated with MxRAMModel objects

[tbates]

summary() bug or deep mystery of the universe

http://openmx.ssri.psu.edu/thread/4199
Is the package (OpenMx) associated with MxRAMModel objects not being stored as part of the class definition?

[tbates]

FYI, teaching a class, about 5/50 people had this error last week. It seemed to have something to do with package order. Went away with reinstall package, restart R.

[jpritikin]

No idea how to reproduce this or whether it's even an OpenMx problem. Closing until we receive a better bug report.

[RMKirkpatrick]

I wonder if this issue is worth revisiting in light of thread 4311?

[mcneale]

Doesn’t the result of 2.8.3 upgrade eliminating the error imply that the problem is fixed?

[RMKirkpatrick]

But upgrading didn't resolve the issue. What did was krzysiek re-running his MxModels anew, instead of loading them from a saved workspace.

[RMKirkpatrick]

Should we revisit this issue? It's still tripping users up.

[mcneale]

I think we should indicate which prior versions of OpenMx would be compatible with the present one. If none, that’s just the way it is. We could then issue an error on attempts to load outdated versions: “Sorry, this mxModel was saved with an earlier version of OpenMx which is not compatible with the version you are using. Please first rerun the original model with your newer version, which will make it compatible." On Jan 26, 2018, at 8:24 PM, RMKirkpatrick <notifications@github.com<mailto:notifications@github.com>> wrote: Should we revisit this issue? It's still tripping users up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACNfDciv6X-Sfb7US49MTBveUJ4Wu8aQks5tOiaCgaJpZM4L9fRw>.

[tbates]

Or maybe "“Sorry, this mxModel was saved with an earlier version of OpenMx (version string) which we can't be sure is fully binary compatible with the version you are using. Please first rerun the original model with your newer version, which will make it compatible." i.e., not sure developers will be able to maintain a list of all compatible version-spans. t

…

On 29 Jan 2018, at 11:04 am, Michael Neale ***@***.***> wrote: I think we should indicate which prior versions of OpenMx would be compatible with the present one. If none, that’s just the way it is. We could then issue an error on attempts to load outdated versions: “Sorry, this mxModel was saved with an earlier version of OpenMx which is not compatible with the version you are using. Please first rerun the original model with your newer version, which will make it compatible." On Jan 26, 2018, at 8:24 PM, RMKirkpatrick ***@***.******@***.***>> wrote: Should we revisit this issue? It's still tripping users up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACNfDciv6X-Sfb7US49MTBveUJ4Wu8aQks5tOiaCgaJpZM4L9fRw>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAs7nP2fZ9BricOM6OJP6Uq93UqywGLLks5tPaXVgaJpZM4L9fRw>.

[mcneale]

Yeah, it isn’t clear to me what would cause crash/failure to load and what would not. Changing slot type or number seems to be the major culprit in backward compatibility. Maybe there are ways to code more politely so that such changes don’t affect backward saved mxModel incompatibilities? In any case, I am firmly of the opinion that we really should do something for the unsuspecting user out there. Another useful thing is checkpointing - it’s easy to reload estimates into a model from the solution, despite not having to run the thing again - very handy if wall time was a month or something. I almost feel like we should automatically dump the estimates out in a readable form (pasting from summary isn’t fun and summary of mxModels can be broken by a version update). Or stash them so they can always be easily extracted from a prior version’s mxModel and fed into omxSetParameters() with no fuss. Perhaps this is the easiest way to go?

[RMKirkpatrick]

N.B. that we DO warn the user if s/he is running an MxModel that was created with a version of OpenMx different from the one currently loaded. See line 72 in R/MxModel.R and line 21 in R/MxRun.R .

[RMKirkpatrick]

I'm reopening this issue, because I think I finally have a fix for it. Today, I read the R Internals manual, concerning S4 classes (plus another document to which the manual links). Based on what it said, I began to suspect that this issue is caused by MxRAMModels never being initialize()d as instances of that class. Instead, they are only ever initialize()d as instances of the base class, "MxModel". Then, what happens to turn them into MxRAMModels is that a function called by mxModel() uses class()<- to change their class to "MxRAMModel" per the value of mxModel() argument type. That does not suffice to give them the "package" attribute, set to "OpenMx"; that's because S4 classes are defined within the context of a package, whereas the end user's R script can use class()<- to change an object's class arbitrarily (even to an undefined class!).

As a proof of concept, I attach summary.MxRAMModel.diff.txt, which is a git diff relative to 7ebcc10 . If I rebuild OpenMx after making the changes reflected in the diff, I can run loadtest--181129.R, save R's workspace, restart R, and load the saved workspace, and OpenMx is automatically loaded into R's workspace with it. That is the current behavior for objects of class "MxModel", but that is new behavior for objects of class "MxRAMModel". I'm running R in RStudio, FYI.

For reference, this is the forums thread about this issue: https://openmx.ssri.psu.edu/thread/4199 .

[RMKirkpatrick]

The changes reflected in that diff are just proof-of-concept. The actual implementation of the bug-fix will have to be less crude. We should probably discuss it at a meeting. And we should implement analogous changes for MxLISRELModels, too.

[jpritikin]

Wow, Rob, accolades to your tenacity on solving this one!

[RMKirkpatrick]

@jpritikin Thanks!

[RMKirkpatrick]

Oh, ba80a3f , for Pete's sake! Can it be that the bug-fix that has eluded us all this time IS A SINGLE LINE OF CODE?!

Fingers crossed that travis and the nightly run both pass.

Edit: well, travis failed, but that wasn't my fault.

[RMKirkpatrick]

If class() is allowed to change the class identifier of an object to an arbitrary string, then it's allowed to change the class identifier of an object into a string with an arbitrary attribute: https://openmx.ssri.psu.edu/comment/8122#comment-8122

[RMKirkpatrick]

Well, it looks like the fix for this issue was much simpler than I thought. Contrary to my initial suspicion, it's not actually necessary for objects of class "MxRAMModel" to be initialize()d as such, and unlike the diff I posted upthread, implementing the repair required only one line of code.

The nightly run passed all tests. Could someone please independently verify that it works? You should be able to build R from the head of the master branch, run loadtest--181129.R, let it save R's workspace, restart R, load the saved workspace, and see OpenMx get automatically loaded into R's workspace with it.

Once someone confirms that it works, this issue can be closed.

[RMKirkpatrick]

I'm going to close this issue. We can reopen it if it turns out my fix doesn't work.