Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Rolf Huehne
On 02/19/2010 06:20 AM, Otis Rothenberger wrote:
 Hello-
 
 I'm working on an atom append script to click append a C atom (methyl group
 actually) to an existing atom in a Jmol model. The following JavaScript
 function works, but it is far from elegant. I'm fairly sure that there are
 Jmol math approaches to deal with some specific script actions that I'm
 attempting, but I could use some guidance. I'm new to Jmol math. The
 function and my questions:
 
 function appendC(x) {
 var scpt = select;set appendNew false;data 'append'|1|add|At 2 2 2|end
 'append';show data;select astatine;
 scpt += {selected}.element='C';connect (selected)(atomIndex= + x +
 );select *;wireframe 0.15; spacefill 23%;boundbox {*};
 scpt += centerat boundbox;delete hydrogens;minimize addHydrogens;
 jmolScript(scpt, 01);
 }
 
 x is the atomIndex of the clicked atom via a pickCallback function.
 
I think you could define this javascript function also as a Jmol script
function. Then you could use for example the boundbox information more
easily to set the position of the new atom (see below).

 1) The ridiculous addition of astatine relates to my inability to use
 getProperty for the atomIndex of the newly appended atom, so I appended a
 very rare element, selected it, and changed it to carbon. Is there a way to
 get this atomIndex a bit more gracefully?
Isn't the atomIndex just a sequential number? If this is true I would
expect that it will be the current (before the addition) maximum
atomIndex + 1. But I don't know how atom deletions might interfere here.

 
 2) The 2 2 2 coordinates were selected to get the appended atom away from
 existing atoms in ammonia. I'd really like a general approach to get this
 atom outside of the VDW surface of any molecule. I know how to calculate the
 isosurface area if I generate it, but I really don't want a surface painted
 on the screen. Further, I'm not sure the area will help. I could calculate a
 diameter, but in a long molecule, I would still be in trouble. Is there any
 Jmol math approach that will calculate a safe distance for this appended
 atom?
 
You could use the boundbox to determine the outer borders of the
molecule and then add some offset. I use the following script to
determine the boundbox values:

  boundbox_selection_expression = NOT WATER;
  boundbox (@{boundbox_selection_expression});
  bound_box = getProperty(boundboxInfo, vector);
  vector_x  = bound_box.x;
  vector_y  = bound_box.y;
  vector_z  = bound_box.z;


 3) One approach is to really put the appended atom into orbit. The
 coordinates 50 50 50 actually work with ammonia. By using a zoom 2000, you
 can even see the result. The function really works very nicely if you get
 the appended atom away from existing atoms. If you do not, then the minimize
 produces chemical nonsense even though I explicitly connect only the two
 atoms. If this orbit approach turns out to be the best approach, then a
 scaling factor that normalizes molecule size would be useful. One
 possibility is using math with zoom 100 and the orbit coordinates, 50 50 50.
 Is this math doable with zoom? Is there another math approach that can be
 used to redefine zoom 100?
 
I am not sure if I understand what the problem is here.
Is it that you want to display everything except the appended atom at
50 50 50 filling the view?
If this is the problem you could try zoomto (atom expression).

Regards,
Rolf

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Rolf Huehne
On 02/19/2010 11:19 AM, Rolf Huehne wrote:
 I am not sure if I understand what the problem is here.
 Is it that you want to display everything except the appended atom at
 50 50 50 filling the view?
 If this is the problem you could try zoomto (atom expression).
 
Sorry, I forgot the important 0 at the end:

zoomto (atom expression) 0

Regards,
Rolf

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Rolf Huehne
On 02/19/2010 06:20 AM, Otis Rothenberger wrote:
 1) The ridiculous addition of astatine relates to my inability to use
 getProperty for the atomIndex of the newly appended atom, so I appended a
 very rare element, selected it, and changed it to carbon. Is there a way to
 get this atomIndex a bit more gracefully?
 
You could store all pre-existing atoms in a varaible and after the
addition use this set to select only the new atom:

define old_atoms all
...add atom...
select not old_atoms

Regards,
Rolf

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Robert Hanson
On Thu, Feb 18, 2010 at 11:20 PM, Otis Rothenberger o...@chemagic.comwrote:

 Hello-

 I'm working on an atom append script to click append a C atom (methyl group
 actually) to an existing atom in a Jmol model. The following JavaScript
 function works, but it is far from elegant. I'm fairly sure that there are
 Jmol math approaches to deal with some specific script actions that I'm
 attempting, but I could use some guidance. I'm new to Jmol math. The
 function and my questions:

 function appendC(x) {
 var scpt = select;set appendNew false;data 'append'|1|add|At 2 2 2|end
 'append';show data;select astatine;
 scpt += {selected}.element='C';connect (selected)(atomIndex= + x +
 );select *;wireframe 0.15; spacefill 23%;boundbox {*};
 scpt += centerat boundbox;delete hydrogens;minimize addHydrogens;
 jmolScript(scpt, 01);
 }

 x is the atomIndex of the clicked atom via a pickCallback function.

 1) The ridiculous addition of astatine relates to my inability to use
 getProperty for the atomIndex of the newly appended atom, so I appended a
 very rare element, selected it, and changed it to carbon. Is there a way to
 get this atomIndex a bit more gracefully?

 The next atom to be added will have the atomIndex equal to the number of
atoms present originally:

{*}.length



 2) The 2 2 2 coordinates were selected to get the appended atom away from
 existing atoms in ammonia. I'd really like a general approach to get this
 atom outside of the VDW surface of any molecule. I know how to calculate the
 isosurface area if I generate it, but I really don't want a surface painted
 on the screen. Further, I'm not sure the area will help. I could calculate a
 diameter, but in a long molecule, I would still be in trouble. Is there any
 Jmol math approach that will calculate a safe distance for this appended
 atom?


Why not just put it where you want it to go?



 3) One approach is to really put the appended atom into orbit. The
 coordinates 50 50 50 actually work with ammonia. By using a zoom 2000, you
 can even see the result. The function really works very nicely if you get
 the appended atom away from existing atoms. If you do not, then the minimize
 produces chemical nonsense even though I explicitly connect only the two
 atoms. If this orbit approach turns out to be the best approach, then a
 scaling factor that normalizes molecule size would be useful. One
 possibility is using math with zoom 100 and the orbit coordinates, 50 50 50.
 Is this math doable with zoom? Is there another math approach that can be
 used to redefine zoom 100?

 Any help with the above questions would be appreciated.

 Otis

 --
 Otis Rothenberger
 http://chemagic.org


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 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
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Otis Rothenberger
Thanks Bob and Rolf.

{*}.length to get the atomIndex of the appended atom makes the embarrassing
astatine trick go away. It also has some general utility.

Bob, putting the appended atom anywhere in the reach of other atoms seems to
always get it mired in a web of strange bonds after minimize addHydrogens.
This happens even if I omit the delete hydrogens.

I'm also not sure where I want the appended atom in the general case - some
offfset from the clicked atom's coordinates? What I'm doing as an
alternative is placing the appended atom outside the reach of other atoms
and then letting minimize sort it out.

Rolf, I'll pursue the zoom suggestions that you made. The problem is that
zoom 100 seems to be redefined by the absurdly long bond that I'm forming.
Your suggestion may allow me to redefine it again after the minimization.

Writing this just gave me a thought. I wonder if the appended carbon atom is
still being viewed with astatine's radius. That might explain the web of
strange bonds.

Whatever the situation, I have some direction now. Thanks for the help.

Otis

-- 
Otis Rothenberger
http://chemagic.org
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Otis Rothenberger
Bob and Rolf,

A fairly lengthy data list is appended to this email.

It looks like atomIndex assignment has problems with my approach. The
JavaScript function is now:

function appendC(x) {
var scpt = select;var z={*}.length;set appendNew false;data
'append'|1|add|C 5 5 5|end 'append';show data;;
scpt += connect (atomIndex = @{z})(atomIndex= + x + );select
*;wireframe 0.15; spacefill 23%;boundbox {*};
scpt += centerat boundbox;delete hydrogens;minimize addHydrogens;
jmolScript(scpt, 01);
}

Ammonia (starting molfile) to methyamine works fine.

Subsequent methylamine to ethylamine adds the carbon atom, but it will not
connect, nor will it add hydrogens. Checking all three atomInfo's shows the
problem. There is atomIndex confusion with all the deleting and adding going
on. The array lengths are correct, but atomIndex problems start with the
generated methylamaine. They run 0,4,5,6,7,8,9. It looks like deleted H's
are taken out of the counting sequence.

I suspect this was happening in my atom substitution approach which also
deleted H's, but there I was selecting atoms by picking only - not
calculation.

The astatine trick bypassed this problem also, though that's not the reason
that I used it.

Any thoughts?

Otis

Three atomInfo data sets:

atomInfo*Vector[4]
atomInfo[1].elementnitrogen
atomInfo[1].visibletrue
atomInfo[1].model1
atomInfo[1].radius0.7416667
atomInfo[1].visibilityFlags13
atomInfo[1].clickabilityFlags12
atomInfo[1].bondCount3
atomInfo[1].atomno1
atomInfo[1].elemno7
atomInfo[1].z-0.02149
atomInfo[1].y0.47149998
atomInfo[1].x-0.15370001
atomInfo[1].partialCharge-0.3437
atomInfo[1].symN
atomInfo[1].colix-32761
atomInfo[1].spacefill0.3565
atomInfo[1].coord{-0.15370001 0.47149998 -0.02149}
atomInfo[1].color[x3050f8]
atomInfo[1].info[SUBUNIT]1:A.N1 #1
atomInfo[1].atomIndex0
atomInfo[1]._ipt0
atomInfo[1].formalCharge0
atomInfo[2].elementhydrogen
atomInfo[2].visibletrue
atomInfo[2].model1
atomInfo[2].radius0.525
atomInfo[2].visibilityFlags13
atomInfo[2].clickabilityFlags12
atomInfo[2].bondCount1
atomInfo[2].atomno2
atomInfo[2].elemno1
atomInfo[2].z-0.72179997
atomInfo[2].y0.55750006
atomInfo[2].x0.55189997
atomInfo[2].partialCharge0.1146
atomInfo[2].symH
atomInfo[2].colix-32767
atomInfo[2].spacefill0.253
atomInfo[2].coord{0.55189997 0.55750006 -0.72179997}
atomInfo[2].color[xff]
atomInfo[2].info[SUBUNIT]1:A.H2 #2
atomInfo[2].atomIndex1
atomInfo[2]._ipt1
atomInfo[2].formalCharge0
atomInfo[3].elementhydrogen
atomInfo[3].visibletrue
atomInfo[3].model1
atomInfo[3].radius0.525
atomInfo[3].visibilityFlags13
atomInfo[3].clickabilityFlags12
atomInfo[3].bondCount1
atomInfo[3].atomno3
atomInfo[3].elemno1
atomInfo[3].z0.86950004
atomInfo[3].y0.3621
atomInfo[3].x0.2819
atomInfo[3].partialCharge0.1146
atomInfo[3].symH
atomInfo[3].colix-32767
atomInfo[3].spacefill0.253
atomInfo[3].coord{0.2819 0.3621 0.86950004}
atomInfo[3].color[xff]
atomInfo[3].info[SUBUNIT]1:A.H3 #3
atomInfo[3].atomIndex2
atomInfo[3]._ipt2
atomInfo[3].formalCharge0
atomInfo[4].elementhydrogen
atomInfo[4].visibletrue
atomInfo[4].model1
atomInfo[4].radius0.525
atomInfo[4].visibilityFlags13
atomInfo[4].clickabilityFlags12
atomInfo[4].bondCount1
atomInfo[4].atomno4
atomInfo[4].elemno1
atomInfo[4].z-0.2147
atomInfo[4].y-0.3345
atomInfo[4].x-0.70919997
atomInfo[4].partialCharge0.1146
atomInfo[4].symH
atomInfo[4].colix-32767
atomInfo[4].spacefill0.253
atomInfo[4].coord{-0.70919997 -0.3345 -0.2147}
atomInfo[4].color[xff]
atomInfo[4].info[SUBUNIT]1:A.H4 #4
atomInfo[4].atomIndex3
atomInfo[4]._ipt3
atomInfo[4].formalCharge0



atomInfo*Vector[7]
atomInfo[1].elementnitrogen
atomInfo[1].visibletrue
atomInfo[1].model1
atomInfo[1].radius0.7416667
atomInfo[1].visibilityFlags13
atomInfo[1].clickabilityFlags12
atomInfo[1].bondCount3
atomInfo[1].atomno1
atomInfo[1].elemno7
atomInfo[1].z2.0656333
atomInfo[1].y4.430047
atomInfo[1].x1.8383527
atomInfo[1].partialCharge-0.3437
atomInfo[1].symN
atomInfo[1].colix-32761
atomInfo[1].spacefill0.3565
atomInfo[1].coord{1.8383527 4.430047 2.0656333}
atomInfo[1].color[x3050f8]
atomInfo[1].info[SUBUNIT]1:A.N1 #1
atomInfo[1].atomIndex0
atomInfo[1]._ipt0
atomInfo[1].formalCharge0
atomInfo[2].elementcarbon
atomInfo[2].visibletrue
atomInfo[2].model1
atomInfo[2].radius0.8084
atomInfo[2].visibilityFlags13
atomInfo[2].clickabilityFlags12
atomInfo[2].bondCount4
atomInfo[2].atomno1
atomInfo[2].elemno6
atomInfo[2].z3.1071622
atomInfo[2].y4.0599203
atomInfo[2].x2.781368
atomInfo[2].partialCharge0.0

Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Rolf Huehne
Otis Rothenberger schrieb:
 Subsequent methylamine to ethylamine adds the carbon atom, but it will 
 not connect, nor will it add hydrogens. Checking all three atomInfo's 
 shows the problem. There is atomIndex confusion with all the deleting 
 and adding going on. The array lengths are correct, but atomIndex 
 problems start with the generated methylamaine. They run 0,4,5,6,7,8,9. 
 It looks like deleted H's are taken out of the counting sequence.
 
I wwas suspecting that deletions might interfere. That's why I proposed 
(unlike Bob) to determine the current maximum atomIndex and then add 1 
to it. Unless deleted atomIndex numbers are refused this should work.

Have you tried my other proposal to store the old atoms as an atomset 
and use the set to determine the new atom?
This should work in any case.

Regards,
Rolf

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Otis Rothenberger
Rolf,

Yup, that seems to work for getting the atomIndex. It just took a while for
me to find the correct dot notation by playing with:

var z={*}.atomIndex.max;echo @z;

I'm new to the math component of Jmol, so I'm doing a lot of trial and error
with math notation right now.

I have not tried your other approach yet because I think it just sunk in as
I read you last note. Did you mean

select{*).

add the carbon atom code here

select unselected

???

Otis



On Fri, Feb 19, 2010 at 2:37 PM, Rolf Huehne rhue...@fli-leibniz.de wrote:

 Otis Rothenberger schrieb:
  Subsequent methylamine to ethylamine adds the carbon atom, but it will
  not connect, nor will it add hydrogens. Checking all three atomInfo's
  shows the problem. There is atomIndex confusion with all the deleting
  and adding going on. The array lengths are correct, but atomIndex
  problems start with the generated methylamaine. They run 0,4,5,6,7,8,9.
  It looks like deleted H's are taken out of the counting sequence.
 
 I wwas suspecting that deletions might interfere. That's why I proposed
 (unlike Bob) to determine the current maximum atomIndex and then add 1
 to it. Unless deleted atomIndex numbers are refused this should work.

 Have you tried my other proposal to store the old atoms as an atomset
 and use the set to determine the new atom?
 This should work in any case.

 Regards,
 Rolf


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Jmol-users mailing list
 Jmol-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jmol-users





-- 
Otis Rothenberger
http://chemagic.org
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Rolf Huehne
Otis Rothenberger schrieb:
 Rolf,
 
 Yup, that seems to work for getting the atomIndex. It just took a while 
 for me to find the correct dot notation by playing with:
 
 var z={*}.atomIndex.max;echo @z;
 
 I'm new to the math component of Jmol, so I'm doing a lot of trial and 
 error with math notation right now.

I wasn't totally sure about the syntax so I didn't want to make a 
specific code proposal.


 I have not tried your other approach yet because I think it just sunk in 
 as I read you last note. Did you mean
 
 select{*).
 
 add the carbon atom code here
 
 select unselected
 
 ???
 
Yes, this would be a similar approach. I just added a storage step 
because I didn't know if the append command would affect the selection.

Regards,
Rolf

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] Help with Jmol Math

2010-02-19 Thread Robert Hanson
I think you should always be able to know where the atom is to go. If it
were me, I would always do atom replacement, so when, say, I click on an H
atom, it becomes a CH3. Isn't that the way Spartan does it? I would just
follow their lead on that. No need to reinvent the wheel here.

Bob

On Fri, Feb 19, 2010 at 11:21 AM, Otis Rothenberger o...@chemagic.comwrote:

 Thanks Bob and Rolf.

 {*}.length to get the atomIndex of the appended atom makes the embarrassing
 astatine trick go away. It also has some general utility.

 Bob, putting the appended atom anywhere in the reach of other atoms seems
 to always get it mired in a web of strange bonds after minimize
 addHydrogens. This happens even if I omit the delete hydrogens.

 I'm also not sure where I want the appended atom in the general case - some
 offfset from the clicked atom's coordinates? What I'm doing as an
 alternative is placing the appended atom outside the reach of other atoms
 and then letting minimize sort it out.

 Rolf, I'll pursue the zoom suggestions that you made. The problem is that
 zoom 100 seems to be redefined by the absurdly long bond that I'm forming.
 Your suggestion may allow me to redefine it again after the minimization.

 Writing this just gave me a thought. I wonder if the appended carbon atom
 is still being viewed with astatine's radius. That might explain the web of
 strange bonds.

 Whatever the situation, I have some direction now. Thanks for the help.


 Otis

 --
 Otis Rothenberger
 http://chemagic.org


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 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
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users