[Topulaneus-Hattum]

Sam, I really don't have any idea why your shell is giving you that error.

From what you posted, it looks like the shell is finding the executable file, which ought to rule out path problems. That file has a reasaonble size, and it's set for "x" for all users. That all looks correct. My only other guess is that the executable was built for a different machine, but that's truly a wild ass guess (and I'd hope you'd get a more informative error message than "no match").

It's apparently a rare situation (3 reports in 5 years) and I've never been able to reproduce it. I've tried searching for what instances the shell would report "no match" but I've had no luck.

What shell are you using?

As anothe data point, if you try wrapping your command in in an executable text file, does that work?

Bob H (lastz author)

[Topulaneus-Hattum]

With a little more searching I've found a plausible answer. I think your shell is trying to interpret [multiple] as a regular expression, as part of command-line filename expansion.

If that's the case, I don't know how to prevent it (my shell isn't doing that). You might try putting quotes or double quotes around [multiple], but I have my doubts that that will change anything.

There's an alternative way to get that multiple option into lastz, without binding it to the file name. --action1=[multiple] But I think the shell is still going to try to expand anything in square brackets. It's going to take someone who understands your shell to solve this. Sorry.

Bob H (lastz author)

[Topulaneus-Hattum]

I know this doesn't help you, but the next release of lastz (something greater than 1.03.73) will have a workaround for this, so that you can set that kind of file modifier without having to use square brackets. Under the unconfirmed idea that that is what the problem is.

Bob H (lastz author)

[ereaye]

multiple sequences in target fasta

Hello,

I am also having some problems with the option "[multiple]". I am trying to run the following command:

>lastz chicken.chrUn.fa[multiple] turkey.chr1.fa K=3000 L=2200 H=2000 M=50 format=axt > chicken.chrUn.turkey.chr1.axt

where the file chicken.chrUn.fa contains hundreds of sequences/scaffolds and the file turkey.chr1.fa contains one single sequence (always softmasked). I tried this with small test files and everything worked fine but when running in the actual data I get this error:

searching for matches in turkey.chr1.fa
processing anchor #1 (of 63651) (8212754/78681682) 16394104/78681682
alignment block score=294106 at (8212350/78681278) 16393700/78681278 length 3543/3485
processing anchor #2 (of 63651) (15263154/71894445) 30514955/71894445
alignment block score=224990 at (15261448/71892751) 30513249/71892751 length 2933/3040
processing anchor #3 (of 63651) (19232279/25722160) 38458396/25722160
alignment block score=497244 at (19226538/25716168) 38452655/25716168 length 6286/6534
processing anchor #4 (of 63651) (12774217/202502915) 25532709/202502915
alignment block score=288391 at (12773292/202502037) 25531784/202502037 length 3719/3839
processing anchor #5 (of 63651) (17840002/111698882) 35673300/111698882
FAILURE: lookup_partition could not locate position 17833297 in chicken.chrUn.fa

and it repeats consistently across all turkey chromosomes every time pointing to different locations in chicken.chrUn.fa. I do want to take advantage of the possibility to have more than one sequence in the target fasta but I continue to fail. So I wonder if someone would know how to fix this.

Thanks!

[Bob-Harris]

Howdy, ereaye,

This indicates some sort of internal error in lastz. Internally it concatenates all the target sequences into one, is trying to convert a position in that concatenated sequence back to the original sequence coordinates, and something has gone wrong with that.

I'd like to reproduce this here. Are these standard chicken and turkey assemblies? If so could you tell me which release/assembly they are? Or if perhaps turkey isn't available online, would it be possible to make that chromosome available somewhere?

Also, what version of lastz are you running (lastz --version).

Thanks,
Bob H (lastz author)

[ereaye]

Hi Bob,

Thanks for following up on this. I am using galGal4 and Turkey_2.01 (GCA_000146605.1) from the ENSEMBL77 repository.

This is an example that should run faster than the one I gave before:

lastz chicken.chrUn.fa[multiple] turkey.chr30.fa --progress --verbosity=10 --runtime --format=axt

opening "chicken.chrUn.fa[multiple]"
opening "turkey.chr30.fa"
building position table for chicken.chrUn.fa
(1.095s) processing query 1: 30
searching for matches in turkey.chr30.fa
processing anchor #1 (of 406) (6987661/2627721) 13938794/2627721
alignment block score=353604 at (6983609/2623683) 13934742/2623683 length 4706/4692
...
(((many lines)))
...
processing anchor #385 (of 406) (9796561/2204818) 19593088/2204818
FAILURE: lookup_partition could not locate position 9796526 in chicken.chrUn.fa

Here chicken.chrUn.fa contains the 100 longest unanchored scaffolds in the chicken assembly (from LGE22C19W28_E50C23 to AADN03009277.1).

In the meantime I have realised two things:
1) If I put fewer scaffolds in the file there are more chances it will work. E.g. with only the 50 longest chicken scaffolds there is no error. This number goes up to ~150 if I use the shortest scaffolds (with min length 1000bp).
2) If I use the --nogapped option everything runs fine, even if I put ~15000 scaffolds in the chicken.chrUn.fa file.

The version of lastz I am using:
version 1.02.00 released 20100112

Thanks!
Ray

[Bob-Harris]

(SeqAnswers seems to have rejected my first reply)

Short answer is use version 1.03.73 from here http://www.bx.psu.edu/~rsharris/lastz/newer

Bob H (lastz author)

[Bob-Harris]

Longer answer (assuming SeqAnswers doesn't throw it away again).

I've been lax in christening any of the newer releases over the last 5.5 years as "official". That should change soon, and the next official release will be not much different than 1.03.73.

I also find that the problem didn't occur for me in version 1.02.00 if I didn't use --verbosity. But I believe that is problem because the problem alignment (the one emanating from anchor 385 in your list) is discarded before the axt file is written. Position conversion is used only for output. My run is a little different than yours, probably because of differences in target sequence order. For me the problem (when I used 1.02.00 and --verbosity) was reported at anchor 272.

So even though the problem disappeared when --verbosity was removed, it's still there-- better to switch to 1.03.73. It shouldn't require any changes in how you're using it.

Bob H (lastz author)

[ereaye]

Yep! latest version runs smoothly

Thanks!