This VV bug is still active:

openvar/rest_variantValidator#74

Manifestation in MD:

To try to reduce the number of occurences in MD, duplicate the internal VV server set up for CLI queries, to completely by-pass the english server.

The /api/variant/create_g API method currently allows for creating variants in MobiDetails based on hg38. LOVD recently added a link to MD, using the /api/variant/create method because having hg38 data couldn't be guaranteed. The first issues, however, have already shown up where LOVD uses older transcripts that are not supported. Being able to submit the variant on either hg19 or hg38 would fix that problem and would allow LOVD to submit any variant.

Hi,
I'm not sure how I did wrong but I'm not seeing your new feature using google chrome (Version 90.0.4430.212 (Build officiel) (64 bits) on my windows 10 but it is working properly with Internet Explorer. No problem either with my Android.
I don't know if it is a bug on my side...
There problem seems to be that the version "0.5.2" is rendered and no the "0.6.2"

Thank you for this amasing tool,
Jean-Marie (Nancy, France)

When I made installation with this command :
pip3 install -r requirements.txt

I got this error :
RuntimeError: The 'apxs' command appears not to be installed or is not executable. Please check the list of prerequisites in the documentation for this package and install any missing Apache httpd server packages.

Solution :
apt-get -y install apache2 apache2-utils apache2-dev

To avoid this kind of problem, you can add in the wiki 'Local Installation'>> 'Installation requirement' Apache2

A user uploaded a file which triggered a UnicodeDecodeError on upload.py line 53.

 File "/webapp/MobiDetails/MobiDetailsApp/upload.py", line 53, in file_upload
     lines = uploaded_file.read().decode().replace('\\r\\n', '\\n').replace('\\r', '\
\n').split('\\n')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xad in position 14: invalid sta
rt byte

To fix with meaningful error message.

Around 08/2020 a bug was preventing some variants protein type to be correctly assigned - exmeples were missense from DMRT2 created 2020/08/20.
Need to check all variants protein types.

when the CSRF tokens do not match, the error is displayed twice:

In addition, it would be nice to display a more useful error message.

md_utilities get_segment_size_from_vv_cigar() function reports an error for this variant in gene FCGBP.

The genome assembly for this region shows multiple patches:

UCSC

However, VV validates the variant with correct genomic positions but the cigar associated to the exon in genes2transcripts does not allow to get the size directly:

{
              "cigar": "504D5=2X13=1X3=3X2=6I3=1I2=1X1=2X8=1I4=2I2=1X2=1X1=1X3=10D320=1X66=1X126=",
              "exon_number": 11,
              "genomic_end": 39906315,
              "genomic_start": 39905731,
              "transcript_end": 7601,
              "transcript_start": 6513
},

Modifying the method to get the segment_size from positions['segment_start'] and positions['segment_end'] which are mandatory anyway should fix the issue (check that end > start).

This function get_segment_size_from_vv_cigar() is used only once from get_positions_dict_from_vv_json().

When adding a new variants on page "General features" I can choose my favorite isoform but when I am on the page "Get Variant" I can't...

Waiting for the full implementation of variants lying on on-coding variants, display a more comprehensible message.

Currently, when submitting e.g. 1-101026084-C-G via the search engine, the answer is:

Must do better.

When a user submits a variant linked to a non-canonical isoform and that VariantValidator returns a warning, MobiDetails only returns a mapping error.

e.g.
NM_001042749.2:c.-41+219C>T
VV returns
"NM_001042749.2:c.-41+219C>T automapped to NM_001042749.2:c.44+135T="

We need to improve the management of the warning so that the user has a precise idea of what triggered the error.

• Problem

Typing NM_001384474.1:c.5086-5C>T in the search engine will lead to the variant page while typing NM_001384474.1:c.5086-5c>T will lead to the gene page

• expected behaviour

NM_001384474.1:c.5086-5c>T or NM_001384474.1:c.5086-5c>t or NM_001384474.1:c.5086-5C>t should open the variant page

I know this is on your radar already, but just to have it registered here; LOVD now uses the create_g method and sends the genomic variant to MD, including an HGNC ID of the relevant gene. This fails for genes where one of the transcripts isn't fully supported by VariantValidator.

For instance, the IVD gene is supported when using the create method and sending NM_002225.3:c.157C>T. Is is not supported when using the create_g method and sending NC_000015.9:g.40700194G>A with HGNC ID 6186. MD's reply is:

mobidetails_error: The gene 6186 is currently not available for variant annotation in MobiDetails

However, since the problem is caused by NM_002225.4 and not NM_002225.3, the variant can actually be annotated and processed. My suggestion would be to drop the transcripts not working, and use the one(s) that are.

When using the LOVD submission API to send classifications to LOVD, it's best to avoid using gene symbols because LOVD can be using older gene symbols (which is an issue they need to solve, obviously). Until then, LOVD is currently working on processing HGNC IDs in their submission API. When that's done, it would be good to start using that feature.

Depends: LOVDnl/LOVD3/issues/466.

When I made installation with this command :
pip3 install -r requirements.txt

I got this error :
ERROR: Failed building wheel for python-ldap Failed to build python-ldap ERROR: Could not build wheels for python-ldap, which is required to install pyproject.toml-based projects

Solution :
apt-get -y install libsas12-dev gcc

To avoid this kind of problem, you can add in the wiki 'Local Installation'>> 'Installation requirement' libsas12-dev and GCC

Currently MD uses specific files to retrieve CADD and Clinpred values for the variants. As they are now part of dbNSFP v4.1, the values for missense should be taken from dbNSFP. This would avoid 2 supplementary tabix searches for missense variants.

It seems that currently there is an error on GnomAD non-cancer fields.

I think that for the exome non-cancer the value that appears is only the first and not the global one, and that no value appears for the genome _non-cancer.

Example:
https://mobidetails.iurc.montp.inserm.fr/MD/api/variant/373349/browser/

Values expected :
exome non-cancer : 0.4693 (0.5368 => only South Asian)
genome non-cancer : 0.4163

there seems to be a connection problem with the variant validator on the web interface. In the example below I had to enter the variant several times to get the result.

current version is 154, need to update asap

When submitting a variant in non canonical isoforms, errors returned by VV are not handled, therefore lead to 500 error.
e.g. NM_001142764.1:c.5343C>A

It seems to be a great idea to add some additional informations into the report as :

• pubmed links
• radar plots
• colors...

When using rs ids (e.g. rs9639594) to annotate variants via the search engine, mobiDetails returns an error:
MobiDetails returned an unexpected error for your request
only in production environment.

When trying to annotate this variant, NM_000552.4(VWF):c.3485_3486delinsTG, MobiDetails returns a 500 error.

It appears that this indel is in fact an inversion as reported by VariantValidator: NM_000552.4:c.3485_3486inv - NC_000012.12:g.6022792_6022793inv

MobiDetails cannot currently handle inv - needs to be fixed.

Hi,
I used to prefer a single-click process for adding a variant to my ClinVar list. Could it be possible to notify the user without requiring two clicks on the OK button?
I find this clinvar feature so helpful, many thx
JM

If an isoform was previously select, reloading the page does not reinitialize the select form. To be fixed in md_gene.js.

For this variant:

https://mobidetails.iurc.montp.inserm.fr/MD/api/variant/360628/browser/

no uniprot domain is reported, however, the region is DNA-binding:

https://www.uniprot.org/uniprotkb/Q13285/entry#function

The domain is not reported in the family&domain section of the uniprot entry, therefore missed by MD:

https://www.uniprot.org/uniprotkb/Q13285/entry#family_and_domains

Dear mobidetails,
it would be awesome to have the variant link to TOPMed data, even if there is a google account login requirement.
e.g. https://bravo.sph.umich.edu/freeze8/hg38/variant/snv/22-16389447-A-G
thanks!
JM

Bug with IGV.js

A bug appear when you activate the translation sequence on IGV.js.

When you zoom out and zoom in (tested on chrome and firefox on macos) the translation sequence does not shift properly.

Furthermore the pdf export is completely shift...

hi,
I would love to have some condensed gene informations on the variant page (in the gene line of the "nomenclatures" paragraph?)

• loeuf coloring
• omim disease flag,
• panelapp flag

For example:
$\textcolor{red}{\textsf{KAT6A}}$ (🔺disease in omim, panelapp)
$\textcolor{orange}{\textsf{GJD2}}$ (no disease in omim, panelapp)