hi,
just working on the 'univACEP.R' script in /failing
It gives this error.. which is obscure to me
> twinACEFit <- mxRun(twinACEModel)
Running twinACE
Error in mxRun(twinACEModel) :
REAL() can only be applied to a 'numeric', not a 'character'
ok, so that error is from a numeric converted to a factor... probably clear enough
if a supermodel doesn't recognise paths, but its submodels do, is there a way to inject new paths into the submodels? Tried this without sucess:
twinAEModel <- mxModel(twinACEModel, name="twinAE",
+ mxPath(from=c("MZ.C1"), to="MZ.bmi1", arrows=1, free=FALSE, values=0, label="c"),
+ mxPath(from=c("DZ.C1"), to="DZ.bmi1", arrows=1, free=FALSE, values=0, label="c")
+ )
Error: The model type of model 'twinACE' does not recognize paths.
+
Interesting problem. I agree that manipulating paths within RAM-type submodels would be good to implement. Michael might be able to tell us how difficult that might be. I'm not sure if he is keeping the submodel's RAM type or converting based on the parent.
Use the following function. Otherwise the implication is that matrix-style models need to be able to process paths. Which really implies that any-style model needs to be able to process weird entities that are going to be used by any other style model. Which breaks all our efforts at encapsulation. Plus there's the problem with misusing the "." notation.
No, C1 is a latent variable and bmi1 is a manifest variable, both of which are not named entities. The "." notation currently only works with named entities, which is why it can't be used in the 'from' or 'to' arguments of mxPath, because these argument do not accept named entities.
"REAL() can only be applied to a 'numeric', not a 'character'" is a bug in the backend. Can you check in a version of the script that is failing with this error to models/failing? I can't reproduce this error with the current version of the script.
checked in a model that repros
failing/REAL_only_applied_to.R
reading in data with an un-handled missing character '.'
data("twin_NA_dot", package="OpenMx")
Thanks that was useful. Now we have error checking if the data is a matrix that is not of type 'double'. I will add error checking for data.frames after I consult with Tim Brick to confirm my suspicions on what to do about ordinal data.