Miguel wrote:
The conversion should only be done for PDB files, because
only in that case is it reading the MODEL line,
which must be a number.
That is not necessarily true.
Most formats use the modelTag. Other formats could place a number in that
field. I could easily create a .xyz file and use numbers to identify the
models.
perhaps, but you shouldn't, and it is totally improper to assume that a number
there somehow identifies a model.
A less-contrived example is pdbxml.
(I didn't check into what CIF
files do or if .isPDB is absolutely inclusive.)
It is not. (If it is, then the flag is mis-named)
The issue was the distinction between PDB model
number listed and sequential model number.
I disagree slightly. I don't see that the issue is specific to .PDB files.
then rename the tag, but do not pull this number for XYZ files.
I think the question is ... If any file format uses numbers to distinguish
between the models then would you want to use that number as the
modelTagNumber so that you would see it formatted with %M ?
Only if the file format REQUIRES this (as in PDB)
Look, if the tag presented by other file types is not a number then the
behavior will be exactly the same as you desire. If you believe that no
other file type will ever use a number for a model identifier then the
behavior will be exactly the same as you desire.
The documentation is correct; %M should deliver the model number. This must be
the number that is used for selecting a model with the /n designator. Any other
number in that %M field is improper and misleading.
The key is the connection between %m and select.
For PDB files or other formats that allow for "Model number" to be EXPLICITLY
indicated, this number should be determined at the time of file load, not simply
placed into the modelTag field for later possible retrieval. If a place is not
there for modelNumber in AtomSet (and, in the case of simple files, I think,
AtomSetCollection -- not sure there) then it should be added. For all other file
formats, this field should hold (modelIndex + 1).
In particular, an integer that just happens to be on the second line of an XYZ
file must not be used here. That's just a comment field; typically it holds
information such as energies and all sorts of other things, but it is not up to
Jmol to decide what should be there for selecting a specfic model.
I am not saying that I know the absolutely correct answer to this, because
I have struggled with it. But I see no reason to make the change to
restrict the behavior to .pdb files at this point.
Miguel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
