Timothy Driscoll wrote:
>
>>set dataFormat n # take data from nth column
>>
>>set dataFormat -n # take data from nth column, reading atom values in
>>column 1.
>>
>>That might be pretty powerful. Very simple to implement.
>>
>>
>>
>that syntax sounds good to me (though maybe something like dataCol or
>dataSrc instead?). and I agree it could be extremely useful. so the
>column separator would be any number of consecutive whitespace/tab
>chars, I presume?
>
>
>
absolutely. We have built in parsers for that; very simple. Right now
you can have two columns,
you just have to make sure that the first column isn't readable as a number:
not
1 3.434
2 1.234
but
_1 3.434
_2 1.234
and those numbers are ignored. But this idea would make that idea
obsolute -- it would just read the
given columns.
with
dataFormat = 0
I think we would support the current default -- just whitespace, no
columns or anything:
3.434 1.234 5.3434
3.4 this is ignored 3.456 6.543
>
>
>>I think you would still have to apply this as a filter to the selected
>>set, because in a
>>multifile setting you don't want to have to worry about which file was
>>loaded first.
>>
>>
>>
>I think I agree; like this?
>
>x = load("charges.dat")
>set dataFormat -2
>data "property_charge @x"
>select myset
>color property_charge
>
>
>
Almost. The select has to come before the data statement, like this:
x = load("charges.dat")
set dataFormat -2
select myset
data "property_charge @x"
color property_charge
Because the data statement has to create an array encompassing the
entire atom set (all atoms in all files), so it is there you need to
know what atoms to skip.
I'm thinking that if you are going to identify an atom by its number in
this file, then you want the numbers to correlate with the "atomno="
number, and that number starts over for every model.
So selecting a model is the easiest way to implement that:
select 2.3 # file 2; model 3
data "property_charge @x"
color atoms property_charge
That sort of thing.
>>
>>
>I ran into two problems. first, I wanted to color backbone atoms by
>property_charge, but I was building my dat file outside of Jmol.
>trying to pre-compile an exact list of atoms was not feasible for
>complex sets. second, once the dat file is written, it can't be used
>for any other set of atoms. I think your idea above would be an
>excellent refinement that would solve both of these problems.
>
>
>
Sure, I see. Then we definitely need those atom numbers in the file.
Do you like the idea of them being the same as "atomno=" ?
In other words, say you have several models loaded. You would first
select the model
you want to apply the data to, then read the data in. If you happened to
select more than one model,
then we would just apply the data to the FIRST matching atom number in
each case -- never to more than
one model, I think. If you wanted that, you could just repeat the
commands with a different model selected.
Bob
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
