You are here

Should OpenMx warn about duplicate path definitions?

4 posts / 0 new
Last post
brandmaier's picture
Joined: 02/04/2010 - 20:45
Should OpenMx warn about duplicate path definitions?

Hello everybody,

the other day, I defined a complex path model in OpenMx with a lot of mxPath objects. By accident, I included a duplicate mxPath object, that is, two mxPath objects with same "to" and "from" properties. While making changes to my model, I changed only the first definition not being aware of the later redefinition and it took me a while until I realized that my first definition was overwritten by the second. I think, OpenMx's behavior makes sense and I'd expect redefinitions of paths to overwrite past definitions. It might still be helpful to users if OpenMx checked for duplicate path definitions and gave out a warning. What do you think?

best regards,

tbates's picture
Joined: 07/31/2009 - 14:25
Objects updating objects

That's really the OpenMx workflow: Objects updating objects...

You might write a wrapper that checks that a label is unique before adding it, but that would not work here.

To "code safe", the approach to take would be to build all the paths as objects
a = mxPath("me","you")
b = mxPath("me","you")

Then write a wrapper around mxModel called mxModelSafe, which gets the labels or path from/to points from all these paths and checks for clashes.

"a and b have the same from and to..."

A similar approach can be taken for helper functions which chug across a model looking for duplicate names, latents not connected to anything, manifests with no variance etc, and issue warnings where appropriate.

Ryne's picture
Joined: 07/31/2009 - 15:12
We try to do some of what

We try to do some of what Andy's asking about through our documentation discussion of "pass-by-value". Furthermore, it would only be possible to detect some of these duplicates due to the way that mxPath statements work.

Regardless of how you specify models, OpenMx compares expected means and covariances to whatever data you specify. mxPath statements work my populating the appropriate elements of a covariance algebra with the paths you specify. At the moment, we only support "RAM" notation, so every parameter specified in an mxPath statement drops directly in to either the A or S matrix of this spec. Only the matrices are updated; the paths are not retained. For example, look at the following code:

test <- mxModel("PBV", type="RAM", manifestVars="x", mxPath("x", "x", label="y"))

The model itself (which includes only a regression of x on itself) is pretty worthless, but it shows off how OpenMx handles paths. If you go and look at the A matrix (test$A), you'll see that there is a parameter that regresses x on itself with the label "y". However, there is no "MxPath" object contained anywhere in the model. Once the matrices are updated, the paths are thrown away. Paths aren't objects in models, but instructions to update existing model objects.

If we happened to include multiple MxPath objects in the same function call (i.e., enter multiple paths at once), we could spot redundant paths then. Once a path has been included and the appropriate matrices populated, all we could do is let you know that there is already a value in the referenced matrix element. But there's always a value before we start, which is a fixed zero path with no label! Making a more complex filter could be done, but it would fail to catch some cases (free a path, then fix it again, then free it again), add unnecessary overhead and a lot of extra warning messages when people are editing models iteratively, which is one of the great features of the program.

I second Tim's statement above; if you're doing sufficiently complex work and don't intend to overwrite paths very often, helper functions can be great resources. I'd go with something simpler than Tim's suggestion: if you plan to make lots of changes and not overwrite paths, write a function that counts the degrees of freedom or number of non-NA labels and check that against the number of mxPath calls at regular intervals.

I hope this helps, and best of luck with your models.

brandmaier's picture
Joined: 02/04/2010 - 20:45
Thanks for your elaborate

Thanks for your elaborate answers! These a certainly very helpful suggestions.