>> So, it appears that tLeap has a few issues reading in the correct name
>> for the metal centers, reading only the first letter of the atomic
>> symbol.
>Sorry if I missed the earlier part of this thread. Can you provide a small
>example of the tleap error? What happens when it mis-reads the element?
Sure that would definitely clarify things:
Suppose a mol2 with a single atom, as generated by antechamber (no charges):
1 Pd 17.3460 0.7760 -3.2570 Pd 36 CEN 0.000000
Loading this in tleap with the loadmol2 command, results in an entry as
such:
ATOM
Name: Pd
Type: Pd
Charge: 0.0000
Polarization: 0.0000
Element: P
Atom flags: (decimal 131072 hex 0x20000)
posfxd n posblt n posdrwn n selected n
pert n notdisp n touched n posknwn Y
internal n needsmin n needsbuild n
Atom position: 17.346000, 0.776000, -3.257000
Atom velocity: 0.000000, 0.000000, 0.000000
NO BONDS
Correcting this with "set <unit> element Pd" works fine, so it is clearly
worked around. The issue might be processing input as a fixed width rather
than character delimited, and simply reading ' P' rather than 'Pd'.
> so the interface wrote nulls to the g09 input which caused it to die.
Yes, but with it worked around I am running QM/MM/MD and QMMD just fine.
>This sounds like the problem is with sander, not tleap (since sander is the
>code that writes the g09 input). In either case, having a specific example
>would help--we do external QM/MM calculations with two-letter atomic
symbols
>routinely, so it would help to have some specifics here.
Sander and the interface seem fine. I think the input into tleap could use
a bit more idiot proofing lest someone run a bunch of metal centers and
then get the QM results for P, C, or F in place of the desired input.
>...thanks!....dac
Nah, thank you, I've gotten help from your comments to others more than a
handful of times.
-David
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Dec 20 2016 - 12:30:03 PST
