Login

News

Model fails on being re-run filteredDataRow entity already exists

Submitted by tbates on
Hi, This still seems to be a bug in the OpenMx 2 beta 2.

Model with arow objective runs fine once, then dies the second time, trying to update "filteredDataRow"

OpenMx version: 2.0.0.3751
R version: R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin13.1.0
Default optimiser: CSOLNP


# ===============================
# = Model fails on being re-run =
# ===============================

library(OpenMx)
# =================
# = 1. Make data set =
# =================
set.seed(159)
xdat <- data.frame(a=rnorm(10, mean=4.2), b=1:10)

# =========================================
# = 2. Make a model with a row objective =
# =========================================
cmod <- mxModel(
name='Estimation Row Model with Missingness',
mxData(observed=xdat, type='raw'),
mxMatrix(values=.75, ncol=2, nrow=1, free=TRUE, name='M'),
mxAlgebra(omxSelectCols(M, existenceVector), name='fM'),
mxAlgebra((filteredDataRow-fM)%^%2, name='rowAlgebra'),
mxAlgebra(sum(rowResults), name='reduceAlgebra'),
mxFitFunctionRow(
rowAlgebra='rowAlgebra',
reduceAlgebra='reduceAlgebra',
dimnames=c('a', 'b'))
)

# ==========
# = 3. Run =
# ==========
cmod <- mxRun(cmod)

# ==============
# = Now re-run =
# ==============
cmod <- mxRun(cmod)
# Error: The filteredDataRow cannot have name 'Estimation Row Model with Missingness.filteredDataRow' because this entity already exists in the model

# Expected: runs quickly, returning something near the already-reached solution.
# Obtained: fails with error copied above

Submitted by AdminRobK on Tue, 09/02/2014 - 08:32

I think this is nothing new, and exists in version 1.3.2/1.4. In the past I've simply written scripts to work around it.
Log in or register to post comments

Submitted by mhunter on Tue, 09/02/2014 - 17:03

The error message is generated by lines 168-175 of trunk/R/MxFitFunctionRow.R (i.e. inside the genericFitAddEntities method). The idea is the user can't make an entity named "filteredDataRow", because OpenMx has reserved that name for use with mxFitFunctionR(). OpenMx creates this entity at run time because we use it. OpenMx keeps the name after run time so the user can use it and play with it as desired. If anyone can come up if an error checking mechanism that knows when the user made "filteredDataRow" and reports the valid error, while also knowing when OpenMx made it and reports no error, then let me know. I can't figure out a way to get it to work.

Incidentally, I think

cmod <- mxRun(cmod)

is bad coding practice in R, that includes for any function. Do it at your own risk. It saves memory in C/C++ and FORTRAN, but not in R.

Log in or register to post comments

Submitted by jpritikin on Tue, 09/02/2014 - 17:28

Maybe we could document that it is a bug. I'm not sure whether it is documented anywhere. Otherwise users may legitimately write scripts that use filteredDataRow. Is this a real risk? I don't know, but documentation might help.
Log in or register to post comments

Rob said he'd look into finding a solution for this. One thing to check is if "filteredDataRow" is an illegal name for MxMatrix objects and MxAlgerbras. If the user can't name an object that and it's in the model, then the user didn't do it and we know it's ours so we don't need to error. One strategy for a solutionis to modify the setClass for MxMatrix (around line 140 of trunk/R/MxMatrix.R) to include a .madeByOpenMx = "logical" entity. OpenMx would set this equal to TRUE for filteredDataRow, so then we know we made it and no need to error.
Log in or register to post comments
  Login

News