Francois and Piotr,
Well, at this point you have announced your P2N format, so I'm not sure you
have the flexibility to modify it. I agree with Angel, though. The PQR
format works because they are replacing numerical data with numerical data.
Your format could easily break all sorts of programs that are expecting
numerical data in columns 61-66. It is a fine idea to add
alternative/additional information like this to the PDB format for your own
specific purposes; the only problem is when you overwrite legitimate fields,
thus making your files potentially unreadable to other programs.
But I guess if you really don't ever use this for OUTPUT and instead only
for INPUT and you won't ever want PQR file data (user-defined partial
charges and/or radii) as part of this, and you really don't intend any other
program but Jmol to read it, we can work with it. But having a very specific
first line would be advantageous. The PQR format has a line
REMARK 1 PQR
For example (which actually breaks the PDB format anyway, but....)
If it is at all possible to change this file format at this time, I suggest:
--add any information you want in the REMARK section in the first line --
that identifies this file type. I suggest some sort of version information
so you can adapt or extend if needed. "REMARK TITLE" is probably good
enough, I suppose, because it clearly breaks the PDB format of having a
number after the word REMARK. Too bad you didn't use standard PDB REMARK
convention for this.
--use proper REMARK format, with an identifying number in the proper column.
Jmol is cataloging this information, so that could be a benefit for you.
--add element symbols in columns 77/78 (right justified, upper case)
--your data in columns 81-84 (perhaps -- be sure to indicate the width in
your specification), thus allowing for B-Factor or radius information in
columns 61-66
--I would recommend your tutorial refer to "four simple rules" for the
original atom name position:
It also would have been useful if your first atom name field would have
followed the PDB example of starting in column 13 if they are four
characters long or if they have atomic symbols with two-character (Mg, Ca,
Fe, etc.), and starting in column 14 otherwise. Although I think perhaps
that's not really in the PDB specification.
Not that you said this was a "request for comments".... If it's really
important that the file format not be changed at this point, we could
manage.
Bob
On Thu, Nov 11, 2010 at 12:04 AM, FyD <f...@q4md-forcefieldtools.org> wrote:
> Dear Bob,
>
> > 1) There's no header information that distinguishes this from PDB files
> > 2) The atom name field overlaps with the B-Factor field. (Kind of amazing
> to
> > me that you
> > would just invalidate that field that way instead of using the
> > available columns just after it.)
> > 3) There's no element listed in columns 77-78
> >
> > We don't particularly need (3), but I certainly need (1). I'm not going
> to
> > have Jmol check the B-Factor field for a non-number just to do this!
>
> - What if you check for this second column of atom names only for
> files with the .p2n or .P2N extension.
>
> - or we can add a header in the P2N file to distinguish it from the
> PDB file format; for instance:
> REMARK P2N FILE FORMAT JMOL COMPATIBLE
>
> - We can also adapt the format of the P2N file; if you need to have
> this second column of atom names located in another set of columns; no
> problem for R.E.D. which only takes the last column available.
>
> ATOM 1 CO1 CHC 1 0.000 0.000 -0.000 CO
> ATOM 2 N2 CHC 1 1.186 0.866 0.332 N1
> and
> ATOM 1 CO1 CHC 1 0.000 0.000 -0.000
> CO
> ATOM 2 N2 CHC 1 1.186 0.866 0.332
> N1
> and
> ATOM 1 CO1 CHC 1 0.000 0.000 -0.000 CO
> ATOM 2 N2 CHC 1 1.186 0.866 0.332 N1
> are all recognized by R.E.D.
>
> - the chemical element can be deduced from the one of the two columns
> of atom names.
> 1H2 -> H; CB -> C; NH -> N; C'1 -> C; C*1 -> C etc...
> The ambiguity is for Calcium; we use as name XX
>
> Just tell me what you prefer...
>
> regards, Francois
>
>
> > On Wed, Nov 10, 2010 at 9:51 AM, FyD <f...@q4md-forcefieldtools.org>
> wrote:
> >
> >> Dear Jmol developers,
> >>
> >> I have a request for the Jmol developers...
> >>
> >> Jmol handles atom names, charge values, force field atom types & more;
> >> it recognizes among others the PDB & mol2 file formats.
> >>
> >> With the R.E.D. tools & R.E.D. Server we have introduced a new file
> >> format named P2N file format.
> >> See http://q4md-forcefieldtools.org/Tutorial/Tutorial-1.php
> >> http://q4md-forcefieldtools.org/Tutorial/Tutorial-1.php#3
> >>
> >> This P2N file format derives from the PDB file format; the main
> >> difference is that this P2N file format can handle two types of atom
> >> names:
> >> - the first one reflects chemical equivalencing used in RESP input
> >> generation and RESP/ESP charge derivation
> >> - the second one conserves atom naming conventions
> >>
> >> Do you think Jmol could recognize this P2N file format i.e. could Jmol
> >> display these two types of atom names independently?
> >>
> >> You can find an example of P2N file format @
> >> http://q4md-forcefieldtools.org/Tutorial/P2N/Metal-complex/Mol_red1.p2n
> >>
> >> The idea would be to allow displaying these two types of atom names as
> >> Jmol already does for the regular atom names, the charge values and
> >> the force field atom types using the mol2 file format - such as in the
> >> follow applet:
> >> http://q4md-forcefieldtools.org/RED/popup/javaapplet.php
> >> Atomic charges -> displayed or not displayed
> >> Force field atom types -> displayed or not
> >> Atom names -> displayed or not
> >>
> >> We could imagine the same approach for the P2N file format i.e. for
> >> the files with the .p2n and P2N extensions:
> >> Atom names (1st column) -> displayed or not displayed
> >> Atom names (2nd column) -> displayed or not
> >>
> >> As this P2N file format is only used by the tools from
> >> q4md-forcefieldtools.org, I would understand Jmol developers would not
> >> be motivated by this request ;-) no problem with that.
> >>
> >> Thank you,
> >> regards, Francois
> >>
>
>
>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
