dumbfounded (or dumb) on error message

7 replies [Last post]
carey's picture
Offline
Joined: 10/19/2009

perplexed over this:

> thisOMxModel <- mxRun(thisOMxModel)
Running testModel
Error in substituteOperators(as.list(retval)) :
internal error -3 in R_decompress1
In addition: Warning message:
In substituteOperators(as.list(retval)) :
restarting interrupted promise evaluation

to get the MxModel, go to:
http://psych.colorado.edu/~carey/OpenMxGUI/weirdErrorMessage.php

everything appears normal. e.g.,
> class(thisOMxModel$MZf@data@observed$Neglect1)
[1] "ordered" "factor"
> class(thisOMxModel$MZf@data@observed$Neglect2)
[1] "ordered" "factor"
> class(thisOMxModel$DZf@data@observed$Neglect1)
[1] "ordered" "factor"
> class(thisOMxModel$DZf@data@observed$Neglect2)
[1] "ordered" "factor"
> mxEval(preThreshMZf, thisOMxModel, compute = TRUE, show = TRUE)
mxEval(cbind(testModel.preThreshMZf_thresh, testModel.preThreshMZf_thresh), thisOMxModel, TRUE)
Neglect1 Neglect2
[1,] 0.5479062 0.5479062
[2,] 1.2448199 1.2448199
mxEval(cbind(testModel.preThreshDZf_thresh, testModel.preThreshDZf_thresh), thisOMxModel, TRUE)
Neglect1 Neglect2
[1,] 0.681725 0.681725
[2,] 1.387998 1.387998

am using version 1.0.6-1581

greg

mspiegel's picture
Offline
Joined: 07/31/2009
I'm at a loss. One

I'm at a loss. One possibility is to run traceback() when you get the error message. That might give us a clue as to what is causing it. Also, Ryne's comment made me think of a suggestion: avoid using save() on MxModel objects. The internal model specification will change over time. A more robust solution is to save a copy of the R script that generated the file. The public interface (the functions mxModel, mxAlgebra, mxMatrix, etc.) to the OpenMx library will be backward compatible.

mspiegel's picture
Offline
Joined: 07/31/2009
What is your hardware and

What is your hardware and software configuration? I can't reproduce the error using OpenMx 1.0.6 on R 2.12.0 or 2.13.0 on 32-bit windows.

carey's picture
Offline
Joined: 10/19/2009
fyi

mike,
just got home and ran the model on an older configuration and it ran fine.
below are the details re hard- and soft-ware configs.
greg

> mxVersion()
[1] "1.0.3-1505"

> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"

$arch
[1] "x86_64"

$os
[1] "darwin9.8.0"

$system
[1] "x86_64, darwin9.8.0"

$status
[1] ""

$major
[1] "2"

$minor
[1] "11.1"

$year
[1] "2010"

$month
[1] "05"

$day
[1] "31"

$`svn rev`
[1] "52157"

$language
[1] "R"

$version.string
[1] "R version 2.11.1 (2010-05-31)"

carey's picture
Offline
Joined: 10/19/2009
mike, see below. also, i ran

mike,
(pardon--message BEFORE this was actually sent LATER.)
see below for the configuration that generated the error. also, i ran a threshold model from a script i wrote a year ago (and used to run flawlessly) and got the same errors.
greg

> mxVersion()
[1] "1.0.6-1581"

> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"

$arch
[1] "x86_64"

$os
[1] "darwin9.8.0"

$system
[1] "x86_64, darwin9.8.0"

$status
[1] ""

$major
[1] "2"

$minor
[1] "12.0"

$year
[1] "2010"

$month
[1] "10"

$day
[1] "15"

$`svn rev`
[1] "53317"

$language
[1] "R"

$version.string
[1] "R version 2.12.0 (2010-10-15)"

Ryne's picture
Offline
Joined: 07/31/2009
Huh. Short version: build

Huh. Short version: build from source, because that's the only difference between your system and mine and I can't replicate your error. I got a status 1 on my version of the fitted model. The forums don't support .RData objects, so let me know if you want my copy of your fitted model.

The error message shows up in Google searches for sites other than us, which is always nice: the second one comes from R's eval function, while the first means that something got lost in decompression on build. I would have thought an installation error, but we have identical builds. The only possible difference is that I'm building from the trunk, so my 'mxVersion' argument doesn't indicate that I'm at version 1623.

> mxVersion()
[1] "1.0.6-1581"
> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"

$arch
[1] "x86_64"

$os
[1] "darwin9.8.0"

$system
[1] "x86_64, darwin9.8.0"

$status
[1] ""

$major
[1] "2"

$minor
[1] "11.1"

$year
[1] "2010"

$month
[1] "05"

$day
[1] "31"

$`svn rev`
[1] "52157"

$language
[1] "R"

$version.string
[1] "R version 2.11.1 (2010-05-31)"

In case I'm wrong, I've been looking through every change between revisions 1505 and 1581, based on my understanding that this code worked in 1.0.3-1505 and broke by 1.0.6-1581. I didn't see anything that really should have broken anything, but the following three revisions deal directly with the optimizer in such a way that ordinal data has even a slight chance of breaking.

r1523 - cleanup of FIMLobjective: it's at least objective function related
r1530 - added the 'threshnames' argument. Did we somehow not identify ordinal variables as such and lead to errors?
r1538 - 'Optimality tolerance' added. Changed how the objective function options are passed from R to C?

Again, I don't think its any of these issues. They're all mspeigel's commits, largely because he's awesome and commits many useful things. Keep us posted, Greg.

carey's picture
Offline
Joined: 10/19/2009
thnx, guys good suggestions.

thnx, guys
good suggestions. am pretty committed today, so may not be able to get to this. will reply asap.
greg

carey's picture
Offline
Joined: 10/19/2009
sorted it out, sort of. the R

sorted it out, sort of.
the R session must have become corrupt. just got into work, started a new R session, and the object ran fine.
go figure.