matthewwolak / nadiv

R package that constructs (non)additive genetic relationship matrices, and their inverses, from a pedigree to be used in linear mixed effect models (A.K.A. the 'animal model').
16 stars 7 forks source link

issue with prepPed #34

Open giuliamasoero opened 1 year ago

giuliamasoero commented 1 year ago

Hello,

I have been trying to run prepPed with my pedigree _ped <- prepPed(am_pedigreered) and I get this error: _Error in numPed(ped_fixedord[, 1:3]) : Offspring appearing before their dams: first use the 'prepPed' function

The pedigree is formed by 3 columns ID, Dam and Sire, and I've checked that all the ones in the columns Dam and Sire are also in the column ID. Plus I thought the prepPed function was made for taking care of this.

What could cause the problem?

Thank you very much!

Best wishes,

Giulia Masoero

matthewwolak commented 1 year ago

Hi, Thanks for raising this as an issue. This can sometimes be caused by loops in the pedigree.

You are correct, prepPed() will take care of creating ID rows for individuals only appearing as dam/sire in the supplied pedigree. However, in doing so the function uses another one internally (numPed()) to help organize the prepared pedigree. This other function (numPed()) checks for a valid pedigree.

So often prepPed() gives errors like these if there are loops or loops are created by prepPed() - in other words a dam appearing as its own grand-dam.

What kind of pedigree is this (plant, vertebrate, insect, other) and how big is it (e.g., what does nrow(am_pedigree_red) tell you)?

Matthew

giuliamasoero commented 1 year ago

Hi Matthew,

Thanks for the very fast reply and the very clear explanation! I was a bit confused at first.

It’s a pedigree on a vertebrate, a bird species. There are 16322 rows in the pedigree, it’s a dataset for over 20 years of ringing.

I have a “fuller” version of the pedigree with the year of ringing and I checked that the year of ringing of the bird in ID was always after the one of the bird in Dam or Sire… Do you have a more efficient way to check for which lines of the dataset might raise the issue?

Thanks again very much for the help!

Giulia

-------------------------------

Giulia Masoero, Ph.D.

Marie Skłodowska-Curie Postdoctoral Fellow

Website | Google Scholar | ORCID | Twitter

Swiss Ornithological Institute Seerose 1, Sempach, Switzerland

Biology Department, University of Ottawa 30 Marie Curie Private, Ottawa, Canada

Associate Editor | Avocetta - Journal of Ornithology

I work on a flexible work schedule and across a number of time zones so my working day may not be your working day. I won't reply in my time off, and you should feel free to read or respond at a time that works for you.

On 8 Jun 2023 at 16:24 +0200, Matthew @.***>, wrote:

Hi, Thanks for raising this as an issue. This can sometimes be caused by loops in the pedigree. You are correct, prepPed() will take care of creating ID rows for individuals only appearing as dam/sire in the supplied pedigree. However, in doing so the function uses another one internally (numPed()) to help organize the prepared pedigree. This other function (numPed()) checks for a valid pedigree. So often prepPed() gives errors like these if there are loops or loops are created by prepPed() - in other words a dam appearing as its own grand-dam. What kind of pedigree is this (plant, vertebrate, insect, other) and how big is it (e.g., what does nrow(am_pedigree_red) tell you)? Matthew — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

nevillejackson commented 1 year ago

Hi Guilia,  You asked about checking pedigrees.  In the R package dmm there are functions to do thislook at pedcheck.R  or mdf.R.   Be aware that dmm stores pedigree columns in a different order to nadiv.R  There is a function to convert the order... it is called warcolak.convert.RRegardsNevilleSent from Samsung tablet. -------- Original message --------From: Giulia Masoero @.> Date: 9/6/23 1:23 am (GMT+10:00) To: matthewwolak/nadiv @.> Cc: Subscribed @.***> Subject: Re: [matthewwolak/nadiv] issue with prepPed (Issue #34) Hi Matthew,

Thanks for the very fast reply and the very clear explanation! I was a bit confused at first.

It’s a pedigree on a vertebrate, a bird species. There are 16322 rows in the pedigree, it’s a dataset for over 20 years of ringing.

I have a “fuller” version of the pedigree with the year of ringing and I checked that the year of ringing of the bird in ID was always after the one of the bird in Dam or Sire… Do you have a more efficient way to check for which lines of the dataset might raise the issue?

Thanks again very much for the help!

Giulia

-------------------------------

Giulia Masoero, Ph.D.

Marie Skłodowska-Curie Postdoctoral Fellow

Website | Google Scholar | ORCID | Twitter

Swiss Ornithological Institute Seerose 1, Sempach, Switzerland

Biology Department, University of Ottawa 30 Marie Curie Private, Ottawa, Canada

Associate Editor | Avocetta - Journal of Ornithology

I work on a flexible work schedule and across a number of time zones so my working day may not be your working day. I won't reply in my time off, and you should feel free to read or respond at a time that works for you.

On 8 Jun 2023 at 16:24 +0200, Matthew @.***>, wrote:

Hi, Thanks for raising this as an issue. This can sometimes be caused by loops in the pedigree. You are correct, prepPed() will take care of creating ID rows for individuals only appearing as dam/sire in the supplied pedigree. However, in doing so the function uses another one internally (numPed()) to help organize the prepared pedigree. This other function (numPed()) checks for a valid pedigree. So often prepPed() gives errors like these if there are loops or loops are created by prepPed() - in other words a dam appearing as its own grand-dam. What kind of pedigree is this (plant, vertebrate, insect, other) and how big is it (e.g., what does nrow(am_pedigree_red) tell you)? Matthew — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/matthewwolak/nadiv/issues/34#issuecomment-1582811028", "url": "https://github.com/matthewwolak/nadiv/issues/34#issuecomment-1582811028", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]