Atomic number set to 0

[xiki-tempula]

In my test case, I got the atomic number in atomtypes to zero.

[ atomtypes ]
;   name  at_num     mass   charge  type        sigma      epsilon
      ca       0   0.0000   0.0000     A  3.31521e-01  4.13379e-01
      cc       0   0.0000   0.0000     A  3.31521e-01  4.13379e-01
      no       0   0.0000   0.0000     A  3.36510e-01  3.58987e-01
      c3       0   0.0000   0.0000     A  3.39771e-01  4.51035e-01
      hc       0   0.0000   0.0000     A  2.60018e-01  8.70270e-02
      na       0   0.0000   0.0000     A  3.20581e-01  8.54373e-01
      nd       0   0.0000   0.0000     A  3.38417e-01  3.93714e-01
      h1       0   0.0000   0.0000     A  2.42200e-01  8.70270e-02
      cd       0   0.0000   0.0000     A  3.31521e-01  4.13379e-01
      nh       0   0.0000   0.0000     A  3.18995e-01  8.99560e-01
      ha       0   0.0000   0.0000     A  2.62548e-01  6.73620e-02
       o       0   0.0000   0.0000     A  3.04812e-01  6.12119e-01

The setting file is like

[ff]
lennard_jones = gaff2
ext_charges = True
charge_scaling = 1.0
[qm]
memory = 16000
n_proc = 4
software = orca
[qm::software(orca)]
opt_method = r2SCAN-3c
[scan]
method = gromacs
gromacs_exec = gmx

I wonder if this is a TODO or is a bug? I could try to make an example if this is not something that I would expect.

[selimsami]

That number is not relevant as the correct values are set in the [atoms] section.

[xiki-tempula]

@selimsami Thanks for the explanation, I use parmed to load the topology and want to do some modifications to it.
parmed will load the atomic number from the atom type section and it will regard an atomic number of 0 to be a virtual site so an atomic number of zero can cause problems if one were to load the topology with parmed.

[selimsami]

Oh, that is not great. This is the line that needs to be changed to fix this issue.

[xiki-tempula]

@selimsami It seems that the problem is here

qforce/qforce/molecule/non_bonded.py

Line 579 in 6fb8fe1

atomic_numbers[atype] = 0

.

So if line[-6].isdigit() is not a digit, the atomic number is set to zero.

So the definition of atomic number in Gromacs atomtype is optional, so gaff and gaff2 currently don't have the atomic number defined. This is because the atomic number is not defined in the amber topology.

I think there could be two ways of solving this problem.

1. I could add the atomic number to the gaff.dat and gaff2.dat.
2. Or the atom type could be updated when reading the hessian.

I wonder what do you think?

[selimsami]

I like option 1 more. but please see my comment to #21

[selimsami]

This issue is fixed with merging of #21