default constraints in multi group model?

Posted on
Picture of user. paulT Joined: 11/03/2017
Forums
I am a new OpenMX|umx user and am trying to fit a multigroup model. I have fitted two separate umxRAM models (one for each group) and then tried to repeat using the 'umxSuperModel' command. I seem to get very different model results between the multi group model and the separate group models. In the single groups models, there are fewer significant paths in one group, but the multi group appears to have identical significant paths (only varying between group in path weight magnitude)?

The SE for the parameter estimates in the multi group model are much smaller as I guess this is due to larger number of observations, so perhaps this explains the difference? How do you test measurement invariance in the multi group model please?

The R code is attached. Thanks for any advice.

Replied on Wed, 12/18/2019 - 20:39
Picture of user. tbates Joined: 07/31/2009

Hi,
`umxSuperGroup` jointly optimises the contained groups. Parameters with the same label take the same value in each group. So if `m1` and `m2` are two models that differ only in their data and you do `m3 = umxSuperGroup(m1, m2)`, then this is the same as if the data were pooled in one model. (hence the reduction in parameters, tighter SEs you are seeing).

umxRAM now supports a `group= ` parameter to use a column to create groups for each level automatically. Currently, the groups are fully equated (same labels). It's on the umx TODO list to give users flexibility about what is equated.

https://github.com/OpenMx/OpenMx/issues/164

Automated measurement invariance testing is also on the radar.

https://github.com/tbates/umx/issues/71

Soo... currently to test measurement invariance, you would need to give the relevant parameters in each group distinct labels matching the form of invariance being tested.

I'm currently looking to get invariance testing automated by around March 2020. Suggestions welcome.

Replied on Thu, 12/19/2019 - 06:01
Picture of user. paulT Joined: 11/03/2017

In reply to by paulT

Just to say thanks again as I think @tbates workaround is working as expected. :-)