[nilshomer]

I'm wondering in the postprocess step, if BFAST will do something like: choose the best for F and second best for R within a pair because that is within the expected distance, yet the best for R is in another chromsome.
I know it is a rare scenario and maybe I should not worry about it.

It could happen when using the insert size distance in the probability calculation, though it is rare.

[nilshomer]

Hi. everyone.

Should we transform the fastq file from solid2fastq (Bfast) before mapping with bwa?
I mean from "0123123" to "ACTGACT", something likewise plus some other format issues?

Before, I proced without any transformation, then got malformed .sai file and some "segmentation fault" which I haven't specified yet.

Any suggestions? Thank you

Make sure you use the solid2fastq within BWA if you are going to use BWA. On the other hand, if you are using bfast+bwa, make sure you see the command line parameters in BFAST's solid2fastq.

[guo]

Hi. everyone.

Should we transform the fastq file from solid2fastq (Bfast) before mapping with bwa?
I mean from "0123123" to "ACTGACT", something likewise plus some other format issues?

Before, I proced without any transformation, then got malformed .sai file and some "segmentation fault" which I haven't specified yet.

Any suggestions? Thank you

[NanYu]

Good point, the manual and binaries are not in sync. Try "bfast postprocess -h".

Saw them now.

Thanks for your help! I will try them now.

-v insertSizeAvg Specifies the mean insert size to use when rescuing
-s insertSizeStdDev Specifies the standard deviation of the insert size to use when rescuing

[nilshomer]

Good point, the manual and binaries are not in sync. Try "bfast postprocess -h".

[NanYu]

See "-v" and "-s". Make sure you have latest BFAST.

Nils

Hi, Nils:

The version I have is 0.6.5a and the bfast-book.pdf I am reading also shows "version 0.6.5a" but I could not find -v option and -s is common parameter and has nothing to do with insertion size.

"-s INTEGER, --startReadNum=INTEGER
Specifies the first read in which to process. This may be useful when distributing a large data set across a cluster."

Maybe I didn't get things right?

[nilshomer]

See "-v" and "-s". Make sure you have latest BFAST.

Nils

[NanYu]

It may take a very long time to run. Note that "-S" is the standard deviation, not the mean (etc.).

The best way, as a scientist, to find out these answers is to try it out for yourself! I cannot predict the behavior

Thanks!
It did takes much longer time to run (compared to use "-U") option.

There is no option for me to tell BFAST at the postprocess step the expected insertion size (or range of the insertion size) for pair-end sequences.

Maybe what I should do is to use "-U" and use a perl script to look for column #8 in the sam file and separate the results according to the value of #8 (and other information). By doing so, it means this information (expected insertion size) is wasted when using BFAST to map the paired-end sequences.

[nilshomer]

It may take a very long time to run. Note that "-S" is the standard deviation, not the mean (etc.).

The best way, as a scientist, to find out these answers is to try it out for yourself! I cannot predict the behavior

[NanYu]

Yes, that is a possibility with any pairing step.

Thanks!

As mentioned above, if we are expecting ~1.5kb (insertion size, from the lab protocol) , do you think if I set "-S 3000" (very loose criteria) is an OK value for "-S"?

I saw the "-v 160 -s 20 " in #3 but could not find them in the BFAST manual (postprocess section). Could you please let me know what they are?

I really appreciate your help in this forum.

[nilshomer]

Yes, that is a possibility with any pairing step.

[NanYu]

The problem seems to be the estmation of distances and standar deviations. If you set these parameters it will be much faster.

you mean I should provide a value for "-S"?
We are expecting ~1.5kb, so should I set "-S 3000" (allow the distance to be a bit bigger).

Thanks!

[NanYu]

I am not sure why you are concerned. Did you look at the data and see something odd?

I'm wondering in the postprocess step, if BFAST will do something like: choose the best for F and second best for R within a pair because that is within the expected distance, yet the best for R is in another chromsome.
I know it is a rare scenario and maybe I should not worry about it.

[Chipper]

The problem seems to be the estmation of distances and standar deviations. If you set these parameters it will be much faster.

[nilshomer]

with the -U option added, it finished within 1 min!
but it means BFAST will not consider the results for "mated-pair".

It means that it will not try the mate-pair rescue strategy, but it will be annotated as mate pair in the SAM file (check the flag field).

How much it will affect the final result (compared with not using -U option)?

It should affect it by 42. On a serious note, I don't know how much it will affect your results. Please post back if you notice an interesting difference.

If I use the -U option, may I use the SAMTools or other software to further filter the result before SNP discovery?
Thanks!

I am not sure why you are concerned. Did you look at the data and see something odd?