Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Topology parser (.itp) sensitive to underscores #18

Open
marcvdijk opened this issue Mar 14, 2019 · 0 comments
Open

Topology parser (.itp) sensitive to underscores #18

marcvdijk opened this issue Mar 14, 2019 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@marcvdijk
Copy link
Member

Parsing a GROMACS .itp topology file by the pyparsing itp_parser (lie_md.parsers.itp_parsing) fails when a filename in the .itp file contains an underscore.

Example .itp file content that fails:

; lig_30_GMX.itp created by acpype (Rev: 0) on Thu Mar 14 13:31:00 2019

[ atomtypes ]
;name   bond_type     mass     charge   ptype   sigma         epsilon       Amb
 oh       oh          0.00000  0.00000   A     3.06647e-01   8.80314e-01 ; 1.72  0.2104
 n2       n2          0.00000  0.00000   A     3.25000e-01   7.11280e-01 ; 1.82  0.1700
 ce       ce          0.00000  0.00000   A     3.39967e-01   3.59824e-01 ; 1.91  0.0860
 cc       cc          0.00000  0.00000   A     3.39967e-01   3.59824e-01 ; 1.91  0.0860
 os       os          0.00000  0.00000   A     3.00001e-01   7.11280e-01 ; 1.68  0.1700
 cd       cd          0.00000  0.00000   A     3.39967e-01   3.59824e-01 ; 1.91  0.0860
 ca       ca          0.00000  0.00000   A     3.39967e-01   3.59824e-01 ; 1.91  0.0860
 nb       nb          0.00000  0.00000   A     3.25000e-01   7.11280e-01 ; 1.82  0.1700
 ho       ho          0.00000  0.00000   A     0.00000e+00   0.00000e+00 ; 0.00  0.0000
 h4       h4          0.00000  0.00000   A     2.51055e-01   6.27600e-02 ; 1.41  0.0150
 ha       ha          0.00000  0.00000   A     2.59964e-01   6.27600e-02 ; 1.46  0.0150

[ moleculetype ]
;name            nrexcl
 lig_30           3

[ atoms ]
;   nr  type  resi  res  atom  cgnr     charge      mass       ; qtot   bond_type
     1   oh     1   UNL     O    1    -0.360500     16.00000 ; qtot -0.361
     2   n2     1   UNL     N    2    -0.396200     14.01000 ; qtot -0.757
     3   ce     1   UNL     C    3     0.351200     12.01000 ; qtot -0.406
     4   cc     1   UNL    C1    4     0.189400     12.01000 ; qtot -0.216
     5   os     1   UNL    O1    5    -0.316800     16.00000 ; qtot -0.533
     6   cc     1   UNL    C2    6     0.325200     12.01000 ; qtot -0.208
     7   cd     1   UNL    C3    7    -0.234300     12.01000 ; qtot -0.442
     8   cd     1   UNL    C4    8    -0.176300     12.01000 ; qtot -0.618
     9   ca     1   UNL    C5    9    -0.238800     12.01000 ; qtot -0.857
    10   ca     1   UNL    C6   10    -0.048000     12.01000 ; qtot -0.905
    11   ca     1   UNL    C7   11    -0.215300     12.01000 ; qtot -1.120
    12   ca     1   UNL    C8   12     0.408200     12.01000 ; qtot -0.712
    13   nb     1   UNL    N1   13    -0.600001     14.01000 ; qtot -1.312
    14   ca     1   UNL    C9   14     0.417200     12.01000 ; qtot -0.895
    15   ho     1   UNL     H   15     0.418000      1.00800 ; qtot -0.477
    16   h4     1   UNL    H1   16    -0.007200      1.00800 ; qtot -0.484
    17   ha     1   UNL    H2   17     0.137000      1.00800 ; qtot -0.347
    18   ha     1   UNL    H3   18     0.142000      1.00800 ; qtot -0.205
    19   ha     1   UNL    H4   19     0.118000      1.00800 ; qtot -0.087
    20   ha     1   UNL    H5   20     0.117000      1.00800 ; qtot 0.030
    21   h4     1   UNL    H6   21    -0.016900      1.00800 ; qtot 0.013
    22   h4     1   UNL    H7   22    -0.012900      1.00800 ; qtot 0.000

The parser stops parsing when it encounters "lig_30" in [ moleculetype ] breaking follow up code that expects an [ atoms ] card. When replacing "lig_30" with the default ACPYPE file name "input" the parser continues parsing till the end of the file

@marcvdijk marcvdijk added the bug Something isn't working label Mar 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants