Just got this crash running a FIML version of the front page factor model without updating the object to FIML
> data(demoOneFactor)
> factorModel <- mxModel("One Factor",
+ mxMatrix("Full", 5, 1, values=0.2,
+ free=T, name="A"),
+ mxMatrix("Symm", 1, 1, values=1,
+ free=F, name="L"),
+ mxMatrix("Diag", 5, 5, values=1,
+ free=T, name="U"),
+ mxAlgebra(A %% L %% t(A) + U, name="R",
+ dimnames = list(names(demoOneFactor),
+ names(demoOneFactor))),
+ mxMLObjective("R"),
+ mxData(demoOneFactor, type="raw"))
> summary(mxRun(factorModel))
Running One Factor
*** caught segfault ***
address 0x15c0bdf0, cause 'memory not mapped'
Traceback:
1: .Call("callNPSOL", objective, startVals, constraints, matrices, parameters, algebras, data, options, state, PACKAGE = "OpenMx")
2: mxRun(factorModel)
Printer-friendly version
I thought the back-end was converting ML objective functions with raw data to FIML objective functions? valgrind is tracing the error down to populating the 'I' matrix, and it looks like it's interpreting the data source as a covariance matrix:
==5123== Invalid write of size 8
==5123== at 0x60F40F1: omxSetMatrixElement (omxMatrix.c:252)
==5123== by 0x60F3733: omxInitMLObjective (omxMLObjective.c:286)
==5123== by 0x60F50F2: omxFillMatrixFromMxObjective (omxObjective.c:113)
I can check-in a patch in the front-end that performs the conversion. I just wanted to make sure the back-end doesn't have this code in place (ie. the left hand should know what the right hand is doing).
Oh wait, is the issue that an ML objective function was declared with raw data, but no means vector was declared? That should be an error in the front-end. But to confirm, the back-end would be converting this to FIML otherwise?
The back-end should be converting to FIML, yes. But it doesn't look like it is.
I'll check in a fix for it.
Interesting. I was running some models with Pascal today and ran into this too. Tim Bates beat me to it. Thanks to Tim Brick for fixing it quick.