recognizing infile

[Murray Duncan]

Dear Peter.

I am using migrate for the first time so this is probably a simple
error. The program wont recognize my input file for microsat number of
repeats.

eg: 9 populations, 10 loci

9 10 . slinger
34 Ponta_da_Barra
i0000n0000 53.53 84.104 71.83 92.93 132.132 164.167 149.166 139.148
166.166 126.126
i0000n0001 53.55 78.91 84.84 93.93 132.132 169.170 176.176 142.142
169.187 120.128
i0000n0002 53.53 76.79 85.86 93.93 128.129 161.167 161.164 115.131
162.174 129.132
i0000n0003 53.55 69.74 84.84 93.93 132.133 161.161 156.180 130.139
163.174 129.131
i0000n0004 52.53 66.89 84.85 92.93 132.132 161.170 159.162 127.151
162.179 128.130

Is the file correct and where must I store the file for the program to
read i?

thanks a lot in advance

[YC Tay]

Hi Murray,

I'm not Peter, but may i suggest you try formatting your data in PGD
Spider? It produces input files that MIGRATE can read :) I am not sure
what's wrong with your input file format, but perhaps the space
between the sample number and your alleles are too small (i compared
it with mine)?

The input file must be stored in a folder where your MIGRATE software
is.

Hope this helps!

Best regards,
YC

[Peter Halvarsson]

Hi Murray,
If you are using the actual fragment lengths and not the numbers of repeats, you need to specify it in the head of the data input file. Take a look in the documentation for all details.

This is how the 4 first lines in my sample file looks like. I am using the fragment length option:
7 17 . Jay_test
#M 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 2 2
31 pop1
B0141         168.172 240.252 298.298 341.349 366.380 164.164 234.258 98.98   166.166 220.264 328.344 324.328 222.234 290.290 193.193 271.273 ?.?


If I am not mistaken, the math used in the program assumes perfect repeats, so if you are using imperfect repeats, the program might give you biased results.

Best regards,
//Peter H

[Peter Beerli]

Peter and Murray,

I see that there is an unfortunate typo in the manual, the instructions should say

#@M

and not

#M

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

make sure that you use 

#@M 

and not 

#M

because the latter is simply a comment (you can sprinkle your datafile with comments,

to make the comments and the new modifiers compatible with each other I have started to use

combination of the comment with a modifier so for example the 

@ is used with mutation model related things [but at the moment only microsat are used]

If you use the flag then the outfile will say that you used it, I think that all demo files use the correct syntax.

sorry about this,

Peter

PS I will fix asap and also will include a check in the new version that allows #M and issues a warning to read.

--
You received this message because you are subscribed to the Google Groups "migrate-support" group.
To view this discussion on the web visit https://groups.google.com/d/msg/migrate-support/-/yHXWGNkHhTwJ.
To post to this group, send email to migrate...@googlegroups.com.
To unsubscribe from this group, send email to migrate-suppo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/migrate-support?hl=en.

[Vikram Chhatre]

Peter,

I had no idea that we were supposed to use #@M. I have been going by
the manual and using #M, and I think my analyses have been running
okay. It did occur to me earlier that putting # in the front made the
line look like a comment, but I wasn't alarmed as the program did not
give any errors.

Do I need to look out for any problems in my previous results?

Thanks
Vikram

[Peter Beerli]

Vikram,
whether you need to rerun will strongly depend on how large and different your fragment lengths were,
[I am sorry about this] the output should contain a line talking about the fragment lengths and the
allele frequency tables will show the repeats and not the fragment lengths.

Peter

[Peter Beerli]

I just looked at the manual in detail and it seems as at one point I seem to have changed my mind
from #M to
#@M
resulting in confusion. I will update all migrate versions today, and in the future I will support
both #M and #@M

Peter



On May 10, 2012, at 11:06 AM, Vikram Chhatre wrote:

[Peter Halvarsson]

I restarted my analysis. Fortunately I had only been running it for some hours and the other one on my win7 computer just finished, so I will rerun it too.
//Peter H

[Vikram Chhatre]

I will also confirm that the program outputted allele spectra weren't
correct. Instead of checking every single fragment size out, I will
just go ahead fix the problem and restart the analysis.

Does anyone know of a publicly available cluster for migrate analysis?
I could really use some powerful computers for a week or so.

Thanks
Vikram

> --
> You received this message because you are subscribed to the Google Groups
> "migrate-support" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/migrate-support/-/pHZ6VWHoSb0J.

[Bruno P. Kinoshita]

Maybe https://www.bioportal.uio.no/appinfo/?

Never used this one, but there is migrate on its list of applications. 

HTH
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com

[Vikram Chhatre]

Thanks Bruno. I will check it out.

V

[Peter Beerli]

Vikram,
I am curious, the files you sent to me ask for the infinite allele model,
which is certainly not affected by the discrepancy between manual and program??

Peter

[Vikram Chhatre]

Peter,

I am glad you brought this up, because I would not have caught my
mistake otherwise. After your email this morning, I went back and
compared my data file against the mistakes I found in the allele
spectra from output file.

It appears that the mistakes I was seeing happened because at most
loci, alleles like 140.140 (fragment sizes), got coded as 14.14. I
suspect this must have happened at some point when I opened the file
in Excel. So all alleles ending in 0, had their terminal 0 spliced
out and resulted in a new allele. This would not have been so bad, if
the allele before the period 140. had also changed. Alas, the result
was 140.14.

Now it also makes sense that the switch from M# to M@# resulted in
segmentation fault because I was actually *not* using SMM model.

Thank you for troubleshooting this and my apologies for incorrectly
shifting the blame on migrate-n :).

Vikram