I would like to report an instance when R was forced closed without an error message.

I was running an ACE model with the components A C and E being matrices. When specifying the DZ twin covariance I used 0.5*A+C instead of 0.5%x%A+C, which caused the crash. Replacing the * by %x% fixed the problem.

Aside from the crash, it is quite tricky that * cannot be used for scalar-matrix multiplication, which is not consistent with R operations. To represent the scalar multiplication in a linear space as a special case of Kronecker product is a bit weird.

Could you attach a script that reproduces the behavior? WRT the * operator: in OpenMx only matrix types are expressed. All scalar values are converted into 1 x 1 matrices. So * performs element multiplication, see http://openmx.psyc.virginia.edu/wiki/matrix-operators-and-functions. Ah, and you may be seeing an error if our consistency checker is passing in R, but then crashes in the backend.

As a follow up, the following small example will return a poorly phrased error. But it won't crash the R program. So we need your test case to reproduce the error. With regards to the poorly phrased error, this will be fixed in OpenMx post-1.0 when the mxEval() function is rewritten from scratch.

Please see below for more details. Hope these are helpful.

I also run the example code you provided in the follow up, but they trigger quite different outcomes. My error messages are not within the R window. Instead, they are pop outs, and R terminates.

Thank you.

> require(OpenMx)

Loading required package: OpenMx

>

> p<-2;

> replication<-1000;

> varnames<-c(paste("var1_",1:p,sep=""),paste("var2_",1:p,sep=""));

>

> pstar<-p

(p+1)/2;%t(LA),name="A");> nMZ=1000;

> nDZ=1000;

>

> LA<-mxMatrix(type="Lower",nrow=p,ncol=p,free=T,values=1,

+ label=paste("a",1:pstar,sep=""),name="LA");

> LC<-mxMatrix(type="Lower",nrow=p,ncol=p,free=T,values=1,

+ label=paste("c",1:pstar,sep=""),name="LC");

> LE<-mxMatrix(type="Lower",nrow=p,ncol=p,free=T,values=1,

+ label=paste("e",1:pstar,sep=""),name="LE");

>

> A<-mxAlgebra(expression=LA%

> C<-mxAlgebra(expression=LC%

%t(LC),name="C");%t(LE),name="E");> E<-mxAlgebra(expression=LE%

> ACESigmaMZ<-mxAlgebra(expression=rbind(cbind(A+C+E,A+C),cbind(A+C,A+C+E)),

+ name="ACESigmaMZ");

> ACESigmaDZ<-mxAlgebra(expression=rbind(cbind(A+C+E,.5

A+C),cbind(.5A+C,A+C+E)),+ name="ACESigmaDZ");

> mxRun(mxModel(LA,LC,LE,A,C,E,ACESigmaMZ,ACESigmaDZ));

Now it gives a message with header "Microsoft Visual C++ Runtime Library", saying that the "Rgui.exe" has requested the runtime to terminate in an unusual way. Then another error message with header "RGui: Ggui.exe - Application Error", saying instruction at "0x00530057" referenced memory at (the same string). The memory could not be "read".

Good news everyone. I'm checking in a patch so that the small test problem:

Now produces the error message:

`"Error: The following error occurred while evaluating the subexpression '0.5 * model.foo' during the evaluation of 'bar' in model 'model' : non-conformable arrays"`

OpenMx is now on a two-track of parallel codebases. This change will appear in the OpenMx 1.1 release, as a part of the larger rewrite of the mxEval() function. To see the changes in the meantime, build the library from the subversion trunk.

Nice patch! IMHO, the error message is correct (great) but inadequate. Better would be:

"Error: The following error occurred while evaluating the subexpression '0.5 * model.foo' during the evaluation of 'bar' in model 'model' : non-conformable arrays. The first matrix is of dimension 1x1 while the second is of dimension 2x2"

Although in this case it is pretty unambiguous as to which part of the subexpression has failed, perhaps with more complicated expressions it would be difficult to discern. Letting the user know matrix dimensions (which must be known when the error is detected) can be really helpful. At the same time, which is "first" and "second" might be difficult to assign, as for example when the left to right ordering of operations has been revised by the use of parentheses. Even if we keep track of where in the input stream the matrices originated, a problematic operation might involve the result of another operation, so that the error would become, e.g., ...while evaluating the subexpression "the result of (A*B+C) is 1x1 but D is 2x2". This level of detail would make for rapid debug of matrix expressions, and adoring users :).

Thank you for fixing the problem.

I was recently attempting to include an exponent in a mxAlgebra, and hit a similar problem with the syntax matrix^scalar. I interpreted element powering (^) as "raise each element in the matrix to the scalar power," when that functionality is actually achieved with kronecker powering (%^%). I understand the logic, that objects in mxAlgebras are treated as matrices, so the closest thing we have to a matrix by scalar is a kronecker exponent of a matrix and the "scalar" 1x1 matrix.

I have reproduced the error on my machine. Sorry for the bug. I'll run the script under a memory debugger and find the source of the problem.