mutalyzer2 issueshttps://git.lumc.nl/mutalyzer/mutalyzer2/-/issues2021-08-30T13:20:02+02:00https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/525intron numbering - missing warning2021-08-30T13:20:02+02:00Mihai Lefterintron numbering - missing warning*Created by: jtdendunnen*
Variant description NC_000023.11(NM_004006.2):c.1149+412A>G is not correct (it should be c.1150-239G>A). Mutalyzer's Position Converter gives NC_000023.11:g.32644552C>T and corrects the description in the listi...*Created by: jtdendunnen*
Variant description NC_000023.11(NM_004006.2):c.1149+412A>G is not correct (it should be c.1150-239G>A). Mutalyzer's Position Converter gives NC_000023.11:g.32644552C>T and corrects the description in the listing below. The Name Checker gives "0 Errors, 0 Warnings". A warning should be given by the Name Checker and probably best also by the Position Converter.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/512Emit warning on position correction2020-11-11T13:44:03+01:00Mihai LefterEmit warning on position correction*Created by: mihailefter*
For the following description:
NC_000022.10(LZTR1_v001):c.1943-1256G>T
Mutalyzer corrects location `c.1943-1256` to `c.1616-68`. It would be nice to have this change signaled in a warning message.
*Created by: mihailefter*
For the following description:
NC_000022.10(LZTR1_v001):c.1943-1256G>T
Mutalyzer corrects location `c.1943-1256` to `c.1616-68`. It would be nice to have this change signaled in a warning message.
https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/507HGVS link outdated2020-05-22T19:32:27+02:00Mihai LefterHGVS link outdated*Created by: jtdendunnen*
the Mutalyzer website under External links > HGVS Sequence Variant Nomenclature directs to outdated recommendations. Correct is www.HGVS.org/varnomen*Created by: jtdendunnen*
the Mutalyzer website under External links > HGVS Sequence Variant Nomenclature directs to outdated recommendations. Correct is www.HGVS.org/varnomenhttps://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/506Alleles2020-03-19T21:51:31+01:00Mihai LefterAlleles*Created by: lossinc*
HGVS permits notation of multiple variants in series, defining them as an allele (“a series of variants in a protein encoded by one chromosome”; see [here](https://varnomen.hgvs.org/recommendations/protein/variant/...*Created by: lossinc*
HGVS permits notation of multiple variants in series, defining them as an allele (“a series of variants in a protein encoded by one chromosome”; see [here](https://varnomen.hgvs.org/recommendations/protein/variant/alleles/)). In mouse models, the terms “allele” is less restrictive: a genetic alteration involving only a single base is certainly considered an “allele”. Anyway, assuming multiple variants in close proximity, HGVS’ allele definition and associated rules provide convenient notation (e.g., NM_001290469.1:c[2401G>A; c.2404G>A] resulting in p.[(D801N;L802=)]. Mutalyzer, unfortunately, does not resolve this notation to the amino acid level. It would be excellent, if it were able to. https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/504Position Converter "Chr" error suggestion2020-03-03T09:00:02+01:00Mihai LefterPosition Converter "Chr" error suggestion*Created by: jtdendunnen*
using ChrX in the Position Converter (instead of chr) gives:
"Expected W:(0123...) (at char 4), (line:1, col:5)"
I do not understand this error, pointing to the X while the problem is the 'C'.
Using Chr1 giv...*Created by: jtdendunnen*
using ChrX in the Position Converter (instead of chr) gives:
"Expected W:(0123...) (at char 4), (line:1, col:5)"
I do not understand this error, pointing to the X while the problem is the 'C'.
Using Chr1 gives:
"Accession number Chr1 could not be found in our database or is not suitable for the requested conversion". In a sense correct but not really helpful. I suggest to automatically use 'chr' when people give 'Chr' yet warn them the description was corrected.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/503Position Converter error "not found in database" suggestion2020-02-24T17:43:45+01:00Mihai LefterPosition Converter error "not found in database" suggestion*Created by: jtdendunnen*
using NM_001492.5:c.627G>A the Position Converter gives the error "The accession number NM_001492 version 5 could not be found in our database (or is not a transcript)". I think clearer and still correct is "Co...*Created by: jtdendunnen*
using NM_001492.5:c.627G>A the Position Converter gives the error "The accession number NM_001492 version 5 could not be found in our database (or is not a transcript)". I think clearer and still correct is "Conversion not possible: NM_001492 version 5 was not mapped by NCBI to the genome build selected. Maybe try another version of NM_001492."https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/5022 allele descrption not recognized2020-02-24T14:38:04+01:00Mihai Lefter2 allele descrption not recognized*Created by: jtdendunnen*
the NameChecker's response to NM_001492.5:c.[1047_1050del];[1047_1050del] is 'Variant description contains no mutation'. I assume this is a bug. NM_001492.5:c.[1047_1050del] is recognized.*Created by: jtdendunnen*
the NameChecker's response to NM_001492.5:c.[1047_1050del];[1047_1050del] is 'Variant description contains no mutation'. I assume this is a bug. NM_001492.5:c.[1047_1050del] is recognized.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/493Mutalyzer configuration2019-12-10T13:07:47+01:00Mihai LefterMutalyzer configuration*Created by: drtconway*
Hi Mutalyzer,
We run an instance of Mutalyzer from your Ansible script, and we need to alter the configuration to unlimit request line length.
I posted previously (https://github.com/mutalyzer/mutalyzer/iss...*Created by: drtconway*
Hi Mutalyzer,
We run an instance of Mutalyzer from your Ansible script, and we need to alter the configuration to unlimit request line length.
I posted previously (https://github.com/mutalyzer/mutalyzer/issues/490) and you explained that we need to change limit_request_line to do that, but our OPs folks have not been able to make the change work.
Can you please give detailed instructions about where/what the change should look like? Other than that we are running Mutalyzer unmodified.
Thanks,
Tom.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/492Mutalyzer intermitently down2019-10-18T10:43:48+02:00Mihai LefterMutalyzer intermitently down*Created by: persida-bio*
We are using the Mutalyzer web service constantly throughout the day and have noticed that on occasion the service becomes unresponsive and halts our general diagnostics workflow.
Latest, on 16.10.2019 betwee...*Created by: persida-bio*
We are using the Mutalyzer web service constantly throughout the day and have noticed that on occasion the service becomes unresponsive and halts our general diagnostics workflow.
Latest, on 16.10.2019 between 12:00 and 13:00 we have tried the following Mutalyzer service requests:
https://mutalyzer.nl/json/runMutalyzer?variant=NM_000518.4:c.364G%3EC
https://mutalyzer.nl/json/runMutalyzer?variant=NM_000518.4:c.364G>C
Both did not work, and after a half hour or so, worked again.
Is there downtime scheduled, expected? too many requests being serviced at the same time?
What might be the cause of this?
Thanks in advance for your response. https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/491Cache problem with local instance2019-10-15T16:36:53+02:00Mihai LefterCache problem with local instance*Created by: fescudie*
Hello,
From an HGVSg I try to get the normalized HGVSg, HGVSc and HGVSp via mutalyzer/json/runMutalyzerLight.
On the main instance of mutalyzer no problem. On a local instance I have several problems.
When us...*Created by: fescudie*
Hello,
From an HGVSg I try to get the normalized HGVSg, HGVSc and HGVSp via mutalyzer/json/runMutalyzerLight.
On the main instance of mutalyzer no problem. On a local instance I have several problems.
When using the web interface or the JSON API I have two problems:
* My variants are located on exonic, intronic or intergenic sequences. In this configuration, mutalyser needs sequences for the normalization. So, it automatically downloads the NC from the EBI into its cache. However, after downloading the NC sequence, it appears to download all transcripts and it fails. This error is probably due to the number of requests. I tried with an EBI API key and the result is the same. I only succeeded for a small chromosome.
```
127.0.0.1 - - [15/Oct/2019 16:17:36] "GET /name-checker?description=NC_000005.10%3Ag.83538811T%3EC HTTP/1.1" 500 -
Traceback (most recent call last):
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 2463, in __call__
return self.wsgi_app(environ, start_response)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 2449, in wsgi_app
response = self.handle_exception(e)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 1866, in handle_exception
reraise(exc_type, exc_value, tb)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 2446, in wsgi_app
response = self.full_dispatch_request()
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 1951, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 1820, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/flask/app.py", line 1935, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/website/views.py", line 248, in name_checker
variantchecker.check_variant(description, output)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/variantchecker.py", line 1798, in check_variant
retrieved_record = retriever.loadrecord(record_id)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/Retriever.py", line 661, in loadrecord
filename = self.fetch(accession)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/Retriever.py", line 297, in fetch
retmode='text')
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/Bio/Entrez/__init__.py", line 195, in efetch
return _open(cgi, variables, post=post)
File "/home/user/Documents/mutalyzer/mutalyzer_env/lib/python2.7/site-packages/Bio/Entrez/__init__.py", line 566, in _open
and exception.status // 100 == 4:
AttributeError: 'HTTPError' object has no attribute 'status'
127.0.0.1 - - [15/Oct/2019 16:17:36] "GET /name-checker?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
127.0.0.1 - - [15/Oct/2019 16:17:36] "GET /name-checker?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
127.0.0.1 - - [15/Oct/2019 16:17:36] "GET /name-checker?__debugger__=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
127.0.0.1 - - [15/Oct/2019 16:17:37] "GET /name-checker?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
127.0.0.1 - - [15/Oct/2019 16:17:37] "GET /name-checker?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
```
* To get around this problem, I tried to synchronize the cache with the main instance of mutalyzer: `mutalyzer-admin sync-cache 'https://mutalyzer.nl/services/?wsdl' 'https://mutalyzer.nl/Reference/{file}'`. But this command fails because it inserts data without a "source" when this field cannot be null in the database.
```
(mutalyzer_env) user@computer:~/Documents/mutalyzer$ mutalyzer-admin sync-cache 'https://mutalyzer.nl/services/?wsdl' 'https://mutalyzer.nl/Reference/{file}'
Traceback (most recent call last):
File "/home/user/Documents/mutalyzer/mutalyzer_env/bin/mutalyzer-admin", line 11, in <module>
load_entry_point('mutalyzer==2.0.31', 'console_scripts', 'mutalyzer-admin')()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/entrypoints/admin.py", line 441, in main
args.func(**{k: v for k, v in vars(args).items()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/entrypoints/admin.py", line 172, in sync_cache
history)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/mutalyzer-2.0.31-py2.7.egg/mutalyzer/sync.py", line 184, in sync_with_remote
session.commit()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/scoping.py", line 162, in do
return getattr(self.registry(), name)(*args, **kwargs)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1027, in commit
self.transaction.commit()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 494, in commit
self._prepare_impl()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 473, in _prepare_impl
self.session.flush()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 2459, in flush
self._flush(objects)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 2597, in _flush
transaction.rollback(_capture_exception=True)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/util/langhelpers.py", line 68, in __exit__
compat.reraise(exc_type, exc_value, exc_tb)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 2557, in _flush
flush_context.execute()
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 422, in execute
rec.execute(self)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 589, in execute
uow,
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 245, in save_obj
insert,
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 1138, in _emit_insert_statements
statement, params
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 988, in execute
return meth(self, multiparams, params)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1107, in _execute_clauseelement
distilled_params,
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1248, in _execute_context
e, statement, parameters, cursor, context
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1466, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1244, in _execute_context
cursor, statement, parameters, context
File "/home/user/Documents/mutalyzer/mutalyzer_env/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 552, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.IntegrityError: (psycopg2.errors.NotNullViolation) null value in column "source" violates not-null constraint
DETAIL: Failing row contains (24, NM_001286191.2, a9ca5136d888c39876dd0dd95c60dac1, null, null, 2019-10-15 16:13:02.206861).
[SQL: INSERT INTO "references" (accession, checksum, source, source_data, added) VALUES (%(accession)s, %(checksum)s, %(source)s, %(source_data)s, %(added)s) RETURNING "references".id]
[parameters: {'source': None, 'source_data': None, 'added': datetime.datetime(2019, 10, 15, 16, 13, 2, 206861), 'accession': NM_001286191.2, 'checksum': a9ca5136d888c39876dd0dd95c60dac1}]
(Background on this error at: http://sqlalche.me/e/gkpj)
```
For the installation I followed the instructions on https://mutalyzer.readthedocs.io. I installed version v2.0.31 and the data for the GRCh38 assembly.
How can I load all the necessary information to normalize my data on my local instance? Am I wrong in the way I do it?
Thanks in advancehttps://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/488Promoting INS to DUP issue2019-09-12T09:21:51+02:00Mihai LefterPromoting INS to DUP issue*Created by: drtconway*
Hi Mutalyzer,
Thanks for your awesome work! We use mutalyzer on well over 1000 research & clinical assays per month and it's great!
We've run in to an issue which I think is actually a flaw in the HGVS spec...*Created by: drtconway*
Hi Mutalyzer,
Thanks for your awesome work! We use mutalyzer on well over 1000 research & clinical assays per month and it's great!
We've run in to an issue which I think is actually a flaw in the HGVS specification, which Mutalyzer is faithfully implementing.
We have an annotation pipeline which has the following steps (mixed in with other stuff):
1. transliterate variants from the VCF to HGVSg.
2. use mutalyzer to do position conversion, from which we pick a preferred HGVSc name
3. use the name checker to normalise the nomenclature
4. convert the HGVSc back to "normalised" HGVSg
5. rewrite the VCF in "normalised" form (with the HGVS{g,c,p} in the info field) for downstream tools
We've recently had a couple of cases where this blows up in our faces.
Consider the transilterated HGVSg for a 4bp insertion:
> chr1:g.33479001_33479002insATGTC
This is converted by Mutalyzer to the following HGVSc:
> NM_013411.4:c.500_501insGACAT
Which in turn is normalised by Mutalyzer to:
> NM_013411.4:c.c.496_500dup
And the corresponding HGVSg produced by Mutalyzer for this is:
> chr1:g.33479002_33480125dup
What started out as a 4bp insertion has turned into a 1124bp duplication (insertion)!
The reason is clear when we examine (e.g. in the web interface) the HGVSc form. In particular, the coding positions of the 5th and 6th exons:
> 5 426 498
> 6 499 694
The original HGVSc is an insertion just after the splice junction joining exons 5 & 6. Just by coincidence, the inserted sequence happens be the same as the preceding 4bp of the transcript (i.e. the last 2bp of exon 5 and the first 2bp of exon 6) (1/(4^4)=1/256, so I guess we shouldn't be too shocked). Accordingly, and following the prioritisation rules, the INS variant is promoted to a DUP variant. However, like 3' shifting variants onto or across splice junctions, this is misleading.
It seems to me that just as the 3' shifting rule has explicit exceptions relating to splice junctions, the prioritisation rules for duplications and inversions should also disallow promotion from insertion or deletion-insertion. Both duplications and inversions describe variants in terms of the sequence content of a reference sequence, not just position in the reference. As such, it is problematic when the implied sequence contains a splice junction.
Would you consider modifying Mutalyzer to avoid promoting ins->dup and delins->inv in such circumstances.
Thanks,
Tom.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/489In-frame insertion including stop codon not following updated HGVS2019-09-10T10:33:24+02:00Mihai LefterIn-frame insertion including stop codon not following updated HGVS*Created by: gaberudy*
The following variant: NM_001123385.1:c.2574_2575insGTTCCTTAGGAG introduces a stop codon and according to the updated HGVS spec I believe should be represented as p.E858_L859insValProTer)
Currently:
https://mu...*Created by: gaberudy*
The following variant: NM_001123385.1:c.2574_2575insGTTCCTTAGGAG introduces a stop codon and according to the updated HGVS spec I believe should be represented as p.E858_L859insValProTer)
Currently:
https://mutalyzer.nl/name-checker?description=NM_001123385.1%3Ac.2574_2575insGTTCCTTAGGAG
It produces NM_001123385.1(BCOR_i001):p.(Leu859_Trp1755delinsValPro)
The updated HGVS page describes this case with an example:
https://varnomen.hgvs.org/recommendations/protein/variant/insertion/
> insertions containing a translation stop codon in the inserted sequence are described as an insertion, not as a deletion-insertion removing the entire C-terminal amino acid sequence
> p.(Met3_His4insGlyTer)
the predicted consequence at the protein level of an insertion at the DNA level (c.9_10insGGGTAG) is the insertion of GlyTer (alternatively Gly*)
NOTE: this is not described as p.(Met3_Ile3418delinsGly), a deletion-insertion replacing the entire C-terminal protein coding sequence downstream of Met3 with a Gly)
This is definitely an edge case, but I do think the new HGVS recommendation
https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/479Error: Position 0 is out of range.2019-09-06T10:31:26+02:00Mihai LefterError: Position 0 is out of range.*Created by: jtdendunnen*
Using NM_000500.7:c.-108C>T in the name Checker I get the error: Position 0 is out of range.
A more informative error would be: Nucleotide position c.-108 is at position -1 relative to reference sequence NM_...*Created by: jtdendunnen*
Using NM_000500.7:c.-108C>T in the name Checker I get the error: Position 0 is out of range.
A more informative error would be: Nucleotide position c.-108 is at position -1 relative to reference sequence NM_000500.7. The description is not correct. Use another reference sequence, e.g. a genomic reference sequence.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/472insertion does not give predicted protein consequence2019-07-17T16:02:17+02:00Mihai Lefterinsertion does not give predicted protein consequence*Created by: jtdendunnen*
the consequence of a specific intronic variant is the insertion on RNA levele of 29 nucleotides. Since I wanted to check the predicted consequences at protein level but Mutalyzer does not support r. variant des...*Created by: jtdendunnen*
the consequence of a specific intronic variant is the insertion on RNA levele of 29 nucleotides. Since I wanted to check the predicted consequences at protein level but Mutalyzer does not support r. variant descriptions I tried the c. description NM_000207.2 :c.187_188insAACCTGCTCTGCGCGGCACGTCCTGGCAG. Unfortunately Mutalyzer gives p.? with a warning (Variant hits one or more splice sites in selected transcript). Please give the predicted protein description.
When I try NM_000207.2 :c.187_188insaacctgctctgcgcggcacgtcctggcag I get an error (Although the syntax of this variant is correct, the effect can not be analysed). This error is not correct, syntax is not OK (nucleotides should be in Capitals). I was disappointed Mutalyzer does not suggest NM_000207.2 :c.187_188insAACCTGCTCTGCGCGGCACGTCCTGGCAG as correct.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/471Different results between NameChecker und PositionConverter2019-04-16T10:37:32+02:00Mihai LefterDifferent results between NameChecker und PositionConverter*Created by: danidey*
There are two problems here that exist on both the website and the SOAP:
1: Using the NameChecker without a NM-number version number tells me the newest version number, which I then use to convert to a genomic r...*Created by: danidey*
There are two problems here that exist on both the website and the SOAP:
1: Using the NameChecker without a NM-number version number tells me the newest version number, which I then use to convert to a genomic reference. Here the newest version number can sometimes not be found when using the PositionConverter. Example: NM_024408.4(NOTCH2):c.545A>T
2. The NameChecker tells me my input is correct, but no the position conversion fails. Example: NM_001346765.1(MYO18A):c.3590C>T
https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/465improve NameChecker c.3217insT error2019-01-30T10:57:41+01:00Mihai Lefterimprove NameChecker c.3217insT error*Created by: jtdendunnen*
Using NM_000492.3:c.3217insT in the NameChecker gives:
The "^" indicates the position where the error occurred.
Suggest to make the error message more informative, e.g.;
The "^" indicates the position wher...*Created by: jtdendunnen*
Using NM_000492.3:c.3217insT in the NameChecker gives:
The "^" indicates the position where the error occurred.
Suggest to make the error message more informative, e.g.;
The "^" indicates the position where the error occurred. An insertion must be BETWEEN two flanking nucleotides, e.g. NM_004006.2:c.123_124insG.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/464NameChecker c.6614+1G>A error suggestion2019-01-30T10:57:25+01:00Mihai LefterNameChecker c.6614+1G>A error suggestion*Created by: jtdendunnen*
Using NM_004006.2:c.6614+1G>A in Mutalyzer's NameChecker gives:
Intronic position given for a non-genomic reference sequence.
Suggest to make the error message more informative, e.g.:
Intronic position giv...*Created by: jtdendunnen*
Using NM_004006.2:c.6614+1G>A in Mutalyzer's NameChecker gives:
Intronic position given for a non-genomic reference sequence.
Suggest to make the error message more informative, e.g.:
Intronic position given for a non-genomic reference sequence. Correct descriptions specify a genomic reference sequence like NC_000023.11:(NM_004006.2):c.6614+1G>A, NG_012232.1(NM_004006.2):c.6614+1G>A or LRG_199t1:c.6614+1G>A.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/467make "Notes" more prominent2019-01-29T12:02:49+01:00Mihai Leftermake "Notes" more prominent*Created by: jtdendunnen*
Mutalyzer has an important "Note" at the bottom of every page (HGVS nomenclature version 2.0 (notes)). This note will be missed by most. I suggest to make the note more prominent by adding it prominently (in a ...*Created by: jtdendunnen*
Mutalyzer has an important "Note" at the bottom of every page (HGVS nomenclature version 2.0 (notes)). This note will be missed by most. I suggest to make the note more prominent by adding it prominently (in a small text box) to the respective home page, linking to the Notes for more detail. Something like:
Mutalyzer is not perfect, it does not yet accept correct HGVS descriptions using uncertain positions (like c.(6438+1_6439-1)_(6614+1_6615-1)del) or repeated sequences (like c.53AGC[15] or c.53_55[15]).
For the notes:
Mutalyzer is not perfect, it does not yet accept correct HGVS descriptions:
* that use uncertain positions, like c.(6438+1_6439-1)_(6614+1_6615-1)del or g.(123456_234567)_(345678_456789)del (>link to HGVS http://varnomen.hgvs.org/recommendations/uncertain/).
* that use repeated sequences, like c.53AGC[15] or c.53_55[15] (>link to HGVS http://varnomen.hgvs.org/recommendations/DNA/variant/repeated/).https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/466Improve NameCheker c.6611_6612insA warning2019-01-29T11:54:56+01:00Mihai LefterImprove NameCheker c.6611_6612insA warning*Created by: jtdendunnen*
Using NM_004006.2:c.6611_6612insA in the NameChecker gives as warning:
Insertion of A at position 6855_6856 was given, however, the HGVS notation prescribes that it should be a duplication of A at position 685...*Created by: jtdendunnen*
Using NM_004006.2:c.6611_6612insA in the NameChecker gives as warning:
Insertion of A at position 6855_6856 was given, however, the HGVS notation prescribes that it should be a duplication of A at position 6855_6855.
I agree that lower on the page c.6611dup is given but this is easily missed.
Users will not understand how 6611_6612 relates to 6855_6856. In addition "duplication of A at position 6855_6855" is not correct. Suggest to change to e.g.:
Insertion of A at position n.6855_6856 was given, however, the HGVS notation prescribes that it should be a duplication of A at position n.6855.
Even better would be to give:
Insertion of A at position c.6611_6612 was given, however, the HGVS notation prescribes that it should be a duplication of A at position n.6611.https://git.lumc.nl/mutalyzer/mutalyzer2/-/issues/463Improve explanations for the different modules2019-01-23T11:47:36+01:00Mihai LefterImprove explanations for the different modules*Created by: mihailefter*
Mention that:
- Syntax Checker: checks syntax, NOT correctness HGVS description.
- Position Converter: does NOT check correctness HGVS description.
- SNP Converter: does NOT check correctness HGVS desc...*Created by: mihailefter*
Mention that:
- Syntax Checker: checks syntax, NOT correctness HGVS description.
- Position Converter: does NOT check correctness HGVS description.
- SNP Converter: does NOT check correctness HGVS description.