Auto Select database(s) based on sequence type

[VM]

Hi,

I would like to know is there any way to auto check the database(s) based on the sequence type detected through the sequence pasted in the sequence box?

Suppose, if I paste a sequence containing ATGC, I want all the databases in nucleotide section should be marked automatically (highlighted in yellow). Is it possible in SequenceServer?

Thank you!!

[Anurag Priyam]

Hi,

There is no automatic way to do that. You will have to implement it yourself in javascript. I believe there is an event that you can listen to for sequence type changes and act accordingly.

Priyam

--
You received this message because you are subscribed to the Google Groups "sequenceserver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sequenceserve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/33cbda66-07c7-4ec6-8cbc-c17d2782a94bn%40googlegroups.com.

[VM]

Thanks Priyam for the response.

Can you please tell me how can I fix below error? It occurs when I try to download Sequence Hit. I know that the issue is occurring because the there is nothing it finds in the database with the id local to Sequence Server but I don't know how I can make sequence server to use the id that is being used in the database instead?

# ERROR: incorrect number of sequences found.

# You requested 1 sequence(s) with the following identifiers:

#   845014

# from the following databases:

#   OrthoDNA_Sequences.db

# but we found 0 sequence(s).

# 

# This is likley due to a problem with how databases are formatted.

Can you please provide any insight on this as how I can fix this issue please?

Thanks!!

[Anurag Priyam]

Did you format the database yourself? If so, this can happen if you missed the -parse_seqids option. If not, what is your BLAST version? If SequenceServer downloaded BLAST, it is likely to be 2.2.30. That and many subsequent versions of BLAST had problems with numeric sequence ids. Try minimum 2.9.0 in that case or even 2.10.0. Please let us know if that helped.

Priyam

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/d273dcad-74d9-474c-a04e-72a47f84dc83n%40googlegroups.com.

[Varnika Mittal]

Hi Priyam,

Thank you for the response. 

Happy New Year! I had to change the fasta file header but your suggestion to use -parse_seqids worked. I am encountering another problem related to UTF-8 with some of the protein sequences where view or download sequence capability is not working. My hunch is that it's happening only to those sequences which are ending with  asterisk (*), a special character. 

Below is the error I am receiving for the sequences ending with *. Can you please suggest instead of removing *, how can we fix this? 

ArgumentError - invalid byte sequence in UTF-8:
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:197:in `split'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:197:in `block in run'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:196:in `each_line'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:196:in `each'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:196:in `map'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:196:in `run'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb:172:in `initialize'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/routes.rb:152:in `new'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/routes.rb:152:in `block in <class:Routes>'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1611:in `call'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1611:in `block in compile!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:975:in `block (3 levels) in route!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:994:in `route_eval'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:975:in `block (2 levels) in route!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1015:in `block in process_route'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1013:in `catch'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1013:in `process_route'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:973:in `block in route!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:972:in `each'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:972:in `route!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1085:in `block in dispatch!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `block in invoke'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `catch'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `invoke'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1082:in `dispatch!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:907:in `block in call!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `block in invoke'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `catch'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1067:in `invoke'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:907:in `call!'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:895:in `call'
/var/lib/gems/2.7.0/gems/rack-1.6.13/lib/rack/head.rb:13:in `call'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:182:in `call'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:2013:in `call'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1487:in `block in call'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1787:in `synchronize'
/var/lib/gems/2.7.0/gems/sinatra-1.4.8/lib/sinatra/base.rb:1487:in `call'
/var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver.rb:96:in `call'
/var/lib/gems/2.7.0/gems/rack-1.6.13/lib/rack/handler/webrick.rb:88:in `service'
/usr/lib/ruby/2.7.0/webrick/httpserver.rb:140:in `service'
/usr/lib/ruby/2.7.0/webrick/httpserver.rb:96:in `run'
/usr/lib/ruby/2.7.0/webrick/server.rb:307:in `block in start_thread'

Thank you!!

On Tue, Dec 22, 2020 at 4:35 AM Anurag Priyam <anurag0...@gmail.com> wrote:

[Caution: Email from External Sender. Do not click or open links or attachments unless you know this sender.]

--
You received this message because you are subscribed to a topic in the Google Groups "sequenceserver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sequenceserver/r6e3nmQ2Lnc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sequenceserve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/0467F480-2572-443D-8B18-898F1EC3F4B0%40gmail.com.

[Anurag Priyam]

Hi Varnika,

Happy New Year!

You have two options:

1. Upgrade to 2.0.0-rc8 where the issue is fixed.

2. In /var/lib/gems/2.7.0/gems/sequenceserver-1.0.14/lib/sequenceserver/sequence.rb, look for the line Sequence.new(*line.chomp.split('      ')) (should be line 197 or around based on the error message) and the following just above it:

line = line.encode('UTF-8', invalid: :replace, replace: 'X')

This will replace * characters with X in the output.

Priyam

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/CAPBpeQW19HpLhB%3DPxsAOkb0H%2BFGUH80AS9w0DvsPD2TE6SELcQ%40mail.gmail.com.

[Varnika Mittal]

Thank you Priyam for all your help - upgrading sequence server to 2.0.0 did fix the download issue for protein sequences having special characters in there.

Thanks,

Varnika

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/25BAE9BC-7B0A-45E5-AF3C-83800DE259F1%40gmail.com.

[Anurag Priyam]

Cheers!

Priyam

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/CAPBpeQXB0ySJ2kS7-7DQRu7tGc2yxKEH_Y72CTXb3f0%2BYD__kA%40mail.gmail.com.

[Łukasz Sobala]

Dear Anurag and the Sequenceserver team,

Would replacing the asterisk with X not make the reported length of the protein too big by 1 amino acid (for downstream software)? Or is it done in a different way in the rc8 version?

Best regards,

Lukasz

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/0FD79BCF-D602-457E-8D7E-996A52DCB7FB%40gmail.com.

[Anurag Priyam]

Dear Lukasz,

2.0-rc8 takes the approach of replacing asterisk with X. We took this approach after much deliberation: https://github.com/wurmlab/sequenceserver/issues/188.

If you would rather sequenceserver additionally show a warning when * has been replaced by X, that may be possible. Although, I will only be look into it after a few weeks. If you have other ideas, I am all ears.

Priyam

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/CAMmVqTH7Y2a4zSRvwuVndNKddR1mrKg8VazkY83kn-Qf-sYpGg%40mail.gmail.com.

[Łukasz Sobala]

Hello Anurag,

I see it now - this is about situations when * appears in the middle of the sequence. I agree that replacing it with X then is reasonable. But if the * is at the end of the sequence it seems to me that removing it would be better (only if it's at the end, as the STOP codon). 

The edge case is that there is a selenocysteine as the last residue but this would be unresolvable anyway. Or if there are two * characters at the end, I would replace the penultimate one with X and remove the last one. 

Cheers, 

Łukasz

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/A06CFE4B-E987-41ED-B3D6-00A257282B8B%40gmail.com.

[Anurag Priyam]

Hi Lukasz,

I think it would be possible to remove ‘*’ if it is at the end of the sequence. I will discuss with Yannick if I should make this change. I didn’t fully understand your concern about selenocysteine - do you think that if the last residue is ‘U’ (i.e., selenocysteine), that should be removed too?

Priyam

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/CAMmVqTFrQ3c2SZdpoQt7%2BWKFzfL0RX9e3j8_bj-Hn90mOBOeOA%40mail.gmail.com.

[Łukasz Sobala]

Hi Anurag,

I considered these cases:

1) there is one 'X' at the end of the sequence and it was put there by BLAST because it was a STOP codon marked with '*';

2) there is one 'X' at the end of the sequence and it was put there by BLAST because it was a non-standard residue;

3) there are two 'X's at the end of the sequence because it ended with "U*" or "X*", for example.

Case 1 is probably most likely. Case 2 seems quite unlikely and case 3 is very unlikely, but possible. It seems to me that the length would be reported correctly for the largest fraction of results times if X is removed when it is the last character in the results, and only the last X was removed if the sequence ends with XX.

Best regards,

Lukasz

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/3E76A92D-8C63-42B5-A660-E8867449E389%40gmail.com.

[Yannick Wurm]

Hi Lukasz,

thanks for highlighting this. In discussing potential solutions, I'm concerned about inconsistencies that we might create  between the HTML output and, e.g., a table format output. 

I guess with protein-protein BLAST SequenceSErver shouldn't have to do anything, because the easy solution is at the blast database level.  

But the issue does potentially exist if there is translated blast

Or am I reading this wrong? 

Thanks,

Yannick

[Łukasz Sobala]

Dear Yannick,

Thank you for replying - yes, it's true that this could cause potential incompatibility in reports and yes, it would be easier to fix at a database level. I was more focused on my usual use case (blastp).

I may understand it incorrectly, but from what Anurag wrote/linked I thought that BLAST would convert all the non-standard amino acid letters (e.g. U, B, J) and non-standard characters (*) into Xs when producing the output file you use in sequenceserver to visualize the results (an .xml I suppose). If this happens, and the X is at the end of a sequence, it would have probably come from a '*' character at the end of the sequence in the protein database. So the full subject length reports would be overestimated by 1. Please let me know if this is all wrong!

I also think the issue wouldn't exist for blastx because BLAST would be internally consistent in how it translates the nucleotides. And for tblastn it would be the same as for blastp, no? Because the 'subjects' are translated, not the query?

Cheers,

Lukasz

To view this discussion on the web visit https://groups.google.com/d/msgid/sequenceserver/59cf5987-ee12-48bf-bc0b-9931fc211a9bn%40googlegroups.com.