Parser JSmol

From NMReDATA
Revision as of 12:47, 4 May 2019 by Angel.herraez (talk | contribs) (recording features that are implemented in the reader page using JSmol)
Jump to: navigation, search

Parser for NMReDATA zipfiles in a web page using JSmol

This is a copy of contents in Parser and portions of NMReDATA tag format with added annotations of what is being implemented in the HTML reader page that uses JSmol.

Reading the SDF file

Data-parser-ok.png The content of the input should be kept in memory so that it can be written later.

Several models

The SDF file may contain more than one structure, each one (molblock) with its own tags. We expect that the NMReDATA tags will be included only on the first model, but it might be otherwise.

Data-parser-ok.png All tags for all models are displayed in the central section. If needed, a number is added in front to identify the model number.

The first model will usually be 2D. It is desirable to be 3D but this will not always happen.

We expect that a second model might be the 3D structure.

Data-parser-ok.png All models are displayed in the JSmol panel. Buttons are added below to switch the display from one model to another. The 2D or 3D nature is detected using two methods: the code in line 2 of the molblock (characters 21,22, according to the MOL/SDF V2000 format specification) and the Z coordinates of all atoms. The first takes precedence, but any discrepancies raise a warning.

It is important to keep any stereochemical information. Even in 2D data the atoms may have extra information, i.e. for explicit hydrogen atoms the chirality is given by the fourth column of the bond list in the molblock (more precisely, characters 10 to 12, according to the MOL/SDF V2000 format specification).

Data-parser-ok.png Explicit H atoms with stereo information in their bond are coloured light salmon (bisque, bond up) or light blue (powderBlue, bond down) in the JSmol structure.

Tags

The SDF files may contain divers tags (not only the NMREDATA tags).

Data-parser-ok.png Be ready for the tags to appear in any order.

All tags should be written in the output SDF file. We recommend to write tags then in the same order.

Determine how to read the NMREDATA tags

Data-parser-ok.png Scan the tags and list the index of the ones including NMREDATA_ in their name. Read the NMReDATA tags.

Data-parser-ok.png Keep in mind the end of line problem.

  1. If present, backslash + <NL> pair is replaced with <NL> for display
  2. If present, backslash only is replaced with <NL> for display
  3. When saving, backslash will have to be added before any <NL>
  4. No need to check the value of VERSION (although possible).

Read the NMREDATA tags

Many simple tags have no particular format. (NMREDATA_SOLVENT, NMREDATA_VERSION, etc.)

But most "complex" tags (NMREDATAT_ASSIGNMENT, NMREDATA_J, NMREDATA_1H, etc.) all have a common general structure:

Two type of lines should be distinguished:

  • Property lines
  • Item from a list

The "property lines" contain a serie of characters (letters) followed the "=" sign followed by the value of the variable. They can be directly used as name and value of object properties. The value should be read as text , because they have to be revritten later when writing the .sdf file ...

The "property lines" should be identified as such to distinguish them from element of a list. Property lines should be located before the list, but some may follow the list (not recommended, but possible).

IMPORTANT: Note that a property may appear more than once. In this case, it should be read into an array (and be written in the same order when writing the file).

The "Item from a list" have a format that depends on the tag. We have four types of tags:

  • NMREDATA_ASSIGNMENT
  • NMREDATA_J
  • NMREDATA_1D_ ...
  • NMREDATA_2D_ ...

For NMREDATA_1D_ and NMREDATA_2D_ see 1D_attributes and 2D_attributes.

We recommend the store the list as an array of array of characters, and analyse it later. We suggest that when analysing a tag, each line is tested to see if it is a "property line" (see the format above). If it is not a property line, it is a item from a list.

This allows to have a single functions testing properties.

Analyse the individual NMR tag

Depending on the program, what data will be extracted will vary, but all Properties (whether they are understood or not) should be send to the output when writing the file. They don't need to be analysed. Same argument for the properties of peaks. They should all be stored (even if not understood) to be written later.

<NMREDATA_ASSIGNMENT>

Data-parser.png List of assignments is read and displayed n the structure using labels on each atom referenced. Labels for implicit Hydrogens are added to those of the heavy atom.

Data-parser-ok.png Labels will be enclosed in <""> when they include "," "/" "\" "|" or "&" characters. All these have been tested and are properly working:

a
H-C(1)
Proton_1
H'
H
Ha or Hb
<"Ha,Hb">
<"Ha/Hb">
<"Ha\Hb">
<"Ha|Hb">
<"Ha&Hb">
<"Ha & Hb">
<"Ha,Hb,Hc">
<"Ha/Hb/Hc">
<"Ha\Hb\Hc">
<"Ha|Hb|Hc">
<"Ha&Hb&Hc">
<"Ha & Hb & Hc">

Data-parser.png The possibility that the assignment may be vague. Interchangeable or ambiguous assignment, with the keyword "Interchangeable=".

  • Pre-implemented: it is not displayed, but it is detected and a warning alert is displayed (with a count).

Data-parser.png Equivalent spins, with the keyword "Equivalent=".

  • Pre-implemented: it is not displayed, but it is detected and a warning alert is displayed (with a count).

<NMREDATA_ALATIS> (optional but desired)

Here should come the ALATIS code of the compound. (If possible, it should be included!)

Data-parser.png Pre-implemented: access the ALATIS server, send the 2D SDF moldata and retrieve the 3D structure, the ALATIS Key code and the InChI. These might be stored adding them to new tags in the file.