Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mxPath: Adding undirected effect removes directed effect #375

Open
jhorzek opened this issue Aug 11, 2023 · 6 comments
Open

mxPath: Adding undirected effect removes directed effect #375

jhorzek opened this issue Aug 11, 2023 · 6 comments

Comments

@jhorzek
Copy link

jhorzek commented Aug 11, 2023

Hi,
I've been experimenting with the mxPath() function lately, and have come across a problem that is probably an edge case. Adding both a directed effect and an undirected effect for the same observed variable does not seem to work. The effect added first is removed from the model.

library(OpenMx)
model <- mxModel(type = "RAM",
                 manifestVars = c("x1", "x2"),
                 mxPath(from = "x1", to = "x2", 
                        arrows = 1, 
                        labels = "b_x2_x1"),
                 mxPath(from = "x1", 
                        to = "x2", 
                        arrows = 2, 
                        labels = "v_x2_x1"))
# adding the covariance removes the directed effect x1 -> x2
coef(model)
# v_x2_x1 
#      0 
model <- mxModel(type = "RAM",
                 manifestVars = c("x1", "x2"),
                 mxPath(from = "x1", 
                        to = "x2", 
                        arrows = 2, 
                        labels = "v_x2_x1"),
                 mxPath(from = "x1", to = "x2", 
                        arrows = 1, 
                        labels = "b_x2_x1"))
# adding the directed effect removes the covariance x1 <-> x2
coef(model)
# b_x2_x1
#      0 

Best,
Jannik

@mcneale
Copy link
Contributor

mcneale commented Aug 11, 2023

That is possibly by design, although the paths would not overwrite each other (one goes in A and the other in the S matrix), so I think the restriction should be removed (other dev team members may disagree so we will discuss). If you need a workaround, then you can add latent variables that cause the observed variables with paths equal to 1, give them variances of 1, and estimate their covariance instead while retaining the causal path from x1 to x2.

@jhorzek
Copy link
Author

jhorzek commented Aug 11, 2023

Thanks for the quick reply! I also think that adding both types of effects on the same variables is a rare situation and most likely a user error. However, we wanted to implement a model from Gische & Voelkle, 2022 where there are both directed and undirected effects between repeatedly measured variables. As the autoregressive and cross-lagged effects in this model are constrained to be equal over time, the model should also allow the estimation of covariances.

@RMKirkpatrick
Copy link
Contributor

Here's another possible workaround: directly modify the 'A' or 'S' MxMatrices. For example, if you already have the undirected path in your model, you can add the directed one like this:

model$A$free["x2","x1"] <- TRUE
model$A$labels["x2","x1"] <- "b_x2_x1"

You can likewise modify the 'values' matrix of 'S' or 'A' to set start values. Also, remember that 'S' is symmetric, so if you modify an off-diagonal element of 'S', you have to likewise modify the corresponding element on the other side of the diagonal.

@jhorzek
Copy link
Author

jhorzek commented Aug 11, 2023

Thank you! The workarounds work perfectly!

jhorzek added a commit to jhorzek/panelSEM that referenced this issue Aug 11, 2023
@tbates
Copy link
Member

tbates commented Nov 26, 2023

If you discuss this, plus 1 for removing the restriction in the next release: It surprises users when OpenMx silently deletes paths from their model, and as @mcneale notes, having both A and S paths connecting a pair of variables is a legitimate and valid model.

That is possibly by design, although the paths would not overwrite each other (one goes in A and the other in the S matrix), so I think the restriction should be removed (other dev team members may disagree so we will discuss)

@RMKirkpatrick
Copy link
Contributor

I'm inclined to agree that OpenMx's current behavior is not what's best, and that the restriction should be removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants