Bob, Angel,

> Well, at this point you have announced your P2N format, so I'm not sure you
> have the flexibility to modify it.

adding "REMARK P2N FILE FORMAT JMOL COMPATIBLE" or whatever message  
you think (1st line of the file) is quite simple...

moreover, if this line is absent the P2N file can still be used by our tools.

> 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.

We can move this second column of atom names after the column 80; no  
problem for us - except that it will not be convenient to send P2N  
files in emails; each line will be cut; so, I would prefer keeping  
this second column of atom names before this column 80 even if it  
overwrites some features of the PDB file format (the P2N file format  
is very specific to our tools and used only for small molecules where  
B-Factor does not matter; I think).

> 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.

Yes, so far this P2N file format is only used by our tools; and we use  
Jmol in web.

> But having a very specific
> first line would be advantageous. The PQR format has a line
>
> REMARK   1 PQR

ok we could strictly follow this idea.

> 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.

ok

> 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.

We already use REMARK TITLE & it is not mandatory.

REMARK   1 P2N
or
REMARK P2N FILE FORMAT JMOL COMPATIBLE
as you prefer. Is it ok?

> --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)

This is a _key point_ here. I just sent to the Jmol mailing list an  
email about PDB file format & Jmol.

adding element symbols in the PDB file format is quite simple for us;
this might not be that straightforward for the P2N file format.

> --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

If you give me the choice I would prefer keeping this 2nd column of  
atom names before the column 80. However, you decide.

> --I would recommend your tutorial refer to "four simple rules" for the
> original atom name position:

ok

> 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.

ok

> 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.

thanks,

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

Reply via email to