search

green-striped-gecko / PopGenReport

a simple way to analyse population genetic data using R
5 stars 5 forks source link

Running landgenreport with multiple rasters and the commute option #4

Open kvpmulder opened 6 years ago

kvpmulder commented 6 years ago

Dear green-striped-gecko,

I am currently running the landgenreport and running into some errors for which I can not find any information online.

In summary, I have SNP data across 8 populations as well as 7 rasters which I believe might be important in explaining the population structure. I have inverted the rasters where appropriate and scaled them from 0 to 1. Landgenreport runs successfully on both single rasterlayers and all 7 of them in a stack when using leastcost. However, when I try to use the option commute on all rasters together i run into an error (## Error in .solve.dgC.lu(as(a, "dgCMatrix"), b = b, tol = tol): LU computationally singular: ratio of extreme entries in |diag(U)| = 1.452e-16). This error is not apparent when running any single layer or two layers together so it seems to be related to the amount of data I am putting into it simultaneously when running commute.

Let me know if you have any idea on how to solve this?

Thank you!

Kevin

green-striped-gecko commented 6 years ago

Hi Kevin,

Not sure this sounds like an internal error from package gdistance.

What I would suggest to try to run costdistances (instead of leastcost), which allows to run your costdistance separately (without the stack ) and could solve the memory problem. Once done you can combine your cost matrices for the mantel tests of whatever you would like to do afterwards.

Cheers, Bernd

============================================================================== Dr Bernd Gruber )/ .--..---"-,--c_ Associate Professor |..' ._O) Tel: (02) 6206 3804 ,=. .+ ..--( / Fax: (02) 6201 2328 \.-''.-' \ ( _ Institute for Applied Ecology '''\ /\ Faculty of Science and Technology ') University of Canberra ACT 2601 AUSTRALIA Email: bernd.gruber@canberra.edu.aumailto:bernd.gruber@canberra.edu.au WWW: bernd-gruberhttps://researchprofiles.canberra.edu.au/en/persons/bernd-gruber

Australian Government Higher Education Provider Number CRICOS #00212K NOTICE & DISCLAIMER: This email and any files transmitted with it may contain confidential or copyright material and are for the attention of the addressee only. If you have received this email in error please notify us by email reply and delete it from your system. The University of Canberra accepts no liability for any damage caused by any virus transmitted by this email.

From: kvpmulder [mailto:notifications@github.com] Sent: Friday, 9 February 2018 07:38 To: green-striped-gecko/PopGenReport PopGenReport@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [green-striped-gecko/PopGenReport] Running landgenreport with multiple rasters and the commute option (#4)

Dear green-striped-gecko,

I am currently running the landgenreport and running into some errors for which I can not find any information online.

In summary, I have SNP data across 8 populations as well as 7 rasters which I believe might be important in explaining the population structure. I have inverted the rasters where appropriate and scaled them from 0 to 1. Landgenreport runs successfully on both single rasterlayers and all 7 of them in a stack when using leastcost. However, when I try to use the option commute on all rasters together i run into an error (## Error in .solve.dgC.lu(as(a, "dgCMatrix"), b = b, tol = tol): LU computationally singular: ratio of extreme entries in |diag(U)| = 1.452e-16). This error is not apparent when running any single layer or two layers together so it seems to be related to the amount of data I am putting into it simultaneously when running commute.

Let me know if you have any idea on how to solve this?

Thank you!

Kevin

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/green-striped-gecko/PopGenReport/issues/4, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACMUSBmEaXEy7FfpczJd9jE6AD1s3dy_ks5tS1s0gaJpZM4R-_Tj.

kvpmulder commented 6 years ago

Hi Bernd,

Thanks for your reply. I tried running costDistances for all rasters separately but it still gives the same error. When I started running the gdistance functions separately it did work so I tried to find the parts of genleastcost that are giving the error but I am not sure if i'm allowed to change those:

Note that for both of the above I also removed the line: fric.mat@crs@projargs <- "+proj=merc +units=m" as my data was in UTMs already and should thus be fine for calculating euclidian distances. But removing only that did not fix it so thats not were the issue was.

Do you think either of those are bad changes that will somehow bias the results? And which one would potentially be a better fix (scl or function)?

Thanks!

Kevin

green-striped-gecko commented 6 years ago

Hi Kevin,

A bit difficult to be sure as I cannot reproduce your error. It seems to be specific to your map.

I remember that when I developed genleastcost and using the mean function I also got errors due to some internal problem in the transition function.

That’s why I used the 1/x[2], but it seems they may be corrected now.

So my advice would be to look at the transition object (maybe in the left upper corner and check the calculated transitions for you map).

If they match your expectation then fine. It is probably time for me to revisit my genleastcost code (becomes ancient) and yes you are right if your data is already projected to UTM you can skip the CRS bit.

This is merely a quick hack to make sure the data are not reprojected and tell the functions that the data set is already in a metric distance format (hence not lat long).

So I would guess your tweaks should be fine, but I still would check the transition object to make sure it is what you intended to calculate. Be aware transition layers are the invers to resistance layers.

Cheers, Bernd

============================================================================== Dr Bernd Gruber )/ .--..---"-,--c_ Associate Professor |..' ._O) Tel: (02) 6206 3804 ,=. .+ ..--( / Fax: (02) 6201 2328 \.-''.-' \ ( _ Institute for Applied Ecology '''\ /\ Faculty of Science and Technology ') University of Canberra ACT 2601 AUSTRALIA Email: bernd.gruber@canberra.edu.aumailto:bernd.gruber@canberra.edu.au WWW: bernd-gruberhttps://researchprofiles.canberra.edu.au/en/persons/bernd-gruber

Australian Government Higher Education Provider Number CRICOS #00212K NOTICE & DISCLAIMER: This email and any files transmitted with it may contain confidential or copyright material and are for the attention of the addressee only. If you have received this email in error please notify us by email reply and delete it from your system. The University of Canberra accepts no liability for any damage caused by any virus transmitted by this email.

From: kvpmulder [mailto:notifications@github.com] Sent: Wednesday, 21 February 2018 12:52 To: green-striped-gecko/PopGenReport PopGenReport@noreply.github.com Cc: Bernd Gruber bernd@yellowgecko.de; Comment comment@noreply.github.com Subject: Re: [green-striped-gecko/PopGenReport] Running landgenreport with multiple rasters and the commute option (#4)

Hi Bernd,

Thanks for your reply. I tried running costDistances for all rasters separately but it still gives the same error. When I started running the gdistance functions separately it did work so I tried to find the parts of genleastcost that are giving the error but I am not sure if i'm allowed to change those:

· when i change the code for genleastcost from 'function(x) 1/x[2]' to 'mean' (which is the gdistance default for layer transition) it runs successfully without errors. But I am not sure if I am biasing the results somehow?

· when I run genleastcost with the original function for transition but with scl=T in geoCorrection it also works.

Note that for both of the above I also removed the line: fric.mat@crs@projargsmailto:fric.mat@crs@projargs <- "+proj=merc +units=m" as my data was in UTMs already and should thus be fine for calculating euclidian distances. But removing only that did not fix it so thats not were the issue was.

Do you think either of those are bad changes that will somehow bias the results? And which one would potentially be a better fix (scl or function)?

Thanks!

Kevin

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/green-striped-gecko/PopGenReport/issues/4#issuecomment-367187139, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACMUSC_JfNczRSGaMc8Fo0oOk4cmsZswks5tW3bcgaJpZM4R-_Tj.