RE: Analysis of diallel experiment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Analysis of diallel experiment

Hi luis

i wonder why you dont just have pedigree for additive effects, then 28 sca
effects (i.e AxB the same as BxA) and then 56 specific cross effects (AxB
different to BxA).  Im not sure you need to go through the work of
overlaying maternal and paternal design matrices as this would come out by
using a pedigree and your Gca effects are 1/2 (I think) the BV's.

On the other hand could specific cross effects be treated as maternal

Give me a call if you want to chat about this

Cheers Craig

-----Original Message-----
From: Luis A. Apiolaza []
Sent: Wednesday, 9 January 2002 3:56 PM
Subject: Analysis of diallel experiment

Hi everybody,

We are currently analysing results from a full diallel test of 8
parents, including reciprocal but no selfs. Well, almost full; there
are a few missing crosses. I would like to get some comments about the
coding used for this analysis:

Models for diallel experiment in globulus
 tree   !P
 female 670
 male   670
 mum    670
 dad    670
 repl   7
 sca        !A
 reciprocal !A
dat2.csv   !csv
dat2.csv   !csv !maxit 20 !dopart $A

The first model is:
!part 1
germ_rate ~ mu repl !r female and(male) sca reciprocal

where mu is overall mean, repl, replicate for the experiment, female
and(male) overlays the design matrices for female and male to get a
unique prediction for gca, sca is a family code where crossing AxB is
equivalent to crossing BxA, and reciprocal is a unique family code
where the cross AxB is different from cross BxA. This seems to work

*Note 1* although tree is defined as !P we are not using the pedigree
factor for !part 1 and 2. We will do it with other traits later.
*Note 2* Although there are only 8 parents, they are coded as 550, 570, etc.
We did not use !I here because females and male appear in different
order and we think that this wouldn't work OK when overlaying the
design matrices (Arthur: any comments with respect to this?).

After a few discussions, we extended the model to:
!part 2
germ_rate ~ mu repl !r female and(male) mum dad sca reciprocal

the codes for mum and dad are identical to female and male
respectively, but we used different names to force ASReml to fit the
factors, given that were already fitted using female and(male).
According to our interpretation this would fit common maternal (mum)
and common paternal (dad) effects. These two extra terms would include
common environment and any non-nuclear genetic effects.

Running part 2 we get that mum is significant, while dad isn't. This
would be expected with our experience in controlled pollination.

At the same time sca appears to be non-significant for this
trait, but the reciprocal is significant (the same happens with !part
1). I'm not yet fully convinced that what you are crossing is not
significant but that the order matters, but it seems that there are
some special cases where this could be true.

Upto this stage I have mentioned models fitting only the parental
values, but not producing results for all individuals. I assume that
a way to get predicted values for all individuals (for the case of
growth, for example) would be to change the beginning of the model
equation to:

!part 3
germ_rate ~ mu repl !r tree mum dad sca reciprocal

where tree would have the role of female and(male) on terms of taking
into account additive effects. A question here, would this be
different from running !part 2 but defining the factors at the
beginning as:
 female !P
 male !P

I would really appreciate to receive your comments on the models and
any other alternative models that you have tried for this type of
mating design.

Best regards,


Dr Luis A. Apiolaza
Quantitative Geneticist
CRC for Sustainable Production Forestry
School of Plant Science
University of Tasmania
GPO Box 252-55
Hobart TAS 7001

phone:   +61-3-6226 2213
fax:     +61-3-9229 2698

'There is no intellectual exercise which is not
 ultimately useless' --Jorge Luis Borges

Asreml mailinglist archive:
Asreml mailinglist archive: