Different means in ACE model
Posted on

Forums
Hi,
I'm wondering how to amend an ACE script to allow for different means across zygosity? (means modelling of my phenotype showed poor fits when trying to constrain MZ/DZ means).
Can someone point me in the right direction?
Paul
Paul, You can remove the
Paul,
You can remove the constrain on means by giving the free parameters for the MZ means different labels than the DZ means. Assuming you're setting everything up as a multiple group model (i.e., one mxModel for MZs, one mxModel for DZs, a container model that holds both of them and some constraints across the two groups made with labels), you'll just replace the label that you use for means in both groups with one label for MZs and one for DZs.
ryne
Log in or register to post comments
In reply to Paul, You can remove the by Ryne
across vs within contraints
Hi, I know this is an old topic. But I just applied this and have the problem that now I do not contrain the means within zygosity anymore. So I estimate three more factors. Any idea, what I might do wrong?
thanks!
Log in or register to post comments
In reply to across vs within contraints by felice gimondi
Probably need same label for twin 1 & twin 2 mean
Something like
mxMatrix("Full", nrow=1, ncol=2, labels="MZmean", free=T, name="mzmeans")
The label will get re-used and therefore parameters will be equated. For multivariate you could build a list (one twin's number of variables, nVar, long) using, e.g., labels=paste("MZmean",1:nVar,sep="")
Log in or register to post comments
The basic idea: instead of
The basic idea: instead of creating one means matrix, create two. Give them each their own free parameters, and apply one to MZ and one to DZ.
It depends on how you lay out your ACE script to begin with. I'm going to use the example from the VIPBG site here: http://www.vipbg.vcu.edu/~vipbg/GE/UnivTwinACEMaRawCon.R but hopefully this will be illustrative enough to show you how to do it in your own code. This model uses the rather popular three-child-model approach: there is a child model called "ACE" which contains most of the algebras, then one child called "MZ" and one called "DZ", which each handle one zygosity group.
In this script, there is one calculation for the mean:
# Matrix & Algebra for expected means vector
mxMatrix( type="Full", nrow=1, ncol=nv, free=TRUE, values= 20, label="mean", name="Mean" ),
mxAlgebra( expression= cbind(Mean,Mean), name="expMean"),
Which we'll make into two like so:
# Matrix & Algebra for expected means vectors
# For MZ
mxMatrix( type="Full", nrow=1, ncol=nv, free=TRUE, values= 20, label="meanMZ", name="MeanMZ" ),
mxAlgebra( expression= cbind(Mean,Mean), name="expMeanMZ"),
# For DZ
mxMatrix( type="Full", nrow=1, ncol=nv, free=TRUE, values= 20, label="meanDZ", name="MeanDZ" ),
mxAlgebra( expression= cbind(Mean,Mean), name="expMeanDZ"),
This is a univariate model, so we only need one free parameter for the mean vector. If your model is multivariate, make sure that you distinguish the labels of the MZ means matrix from the labels of the DZ means matrix so that they are not constrained to be equal.
Now we use them in the individual models. The snippet that defines the existing models currently reads:
mxModel("MZ",
mxData( observed=mzData, type="raw" ),
mxFIMLObjective( covariance="ACE.expCovMZ", means="ACE.expMean", dimnames=selVars )
),
mxModel("DZ",
mxData( observed=dzData, type="raw" ),
mxFIMLObjective( covariance="ACE.expCovDZ", means="ACE.expMean", dimnames=selVars )
),
We'll change it to read:
mxModel("MZ",
mxData( observed=mzData, type="raw" ),
mxFIMLObjective( covariance="ACE.expCovMZ", means="ACE.expMeanMZ", dimnames=selVars )
),
mxModel("DZ",
mxData( observed=dzData, type="raw" ),
mxFIMLObjective( covariance="ACE.expCovDZ", means="ACE.expMeanDZ", dimnames=selVars )
),
The result is that you'll have two free parameters, meanDZ and meanMZ, that will allow the individual means to propagate appropriately. When calculating the DZ twins, the DZ mean will be used. When calculating MZ, the MZ mean will be used.
Of course, there are other ways to do it. If you're using a different formulation or want a different parameterization, feel free to ask.
Log in or register to post comments
In reply to The basic idea: instead of by tbrick
Thanks Guys, that works well.
Thanks Guys, that works well. I wasn't really familiar with what the difference between names and labels were.
Log in or register to post comments