Egon wrote: > when doing the crystal stuff, I noticed that Atom's only > have an 'int' field for charge... but atoms also often have > 'partial atomic charges' which is an estimate of the electron > density on that atom... but this is a float... > can I add this?
Yes, go ahead and change the charge in the ModelAdapter API to a float ... I realize that you want/need it for CDK. However, I do have a little reluctance and I would like to understand something. None of the file types that I have seen to date have fractional charges. And that includes CML. I understood Peter to say that CML only defines formalCharge ... an integer value. Why is this? > Including coloring by partial charge, with option in menu? This part will be a little more difficult to do. There are several issues involved. The charge value defined by the ModelAdapter is an int. But by the time it gets into the Jmol code, that int gets packed in with some other things into a byte value called 'chargeAndFlags'. Since most models (particularly the large ones) don't have float charges I would rather not add a float to the Jmol Atom data structure. --- Actually, that is not a big deal ... you could add the float and I could *optimize* it later. The other issue is this ... Jmol supports covalent radii. But that is all based upon integer formal charges. We need to figure out what to use for a covalent radius when presented with a fractional charge. Do you do a linear interpolation between the two formal charge radii? The color interpolation should be straightforward. There is currently a table of RGB values in JmolConstants for looking up integer charge values between -4 and +7 inclusive. I would do it in a few stages: Stage 1 - ModelAdapter changes * go ahead and change the model adapter API to return a float * change the smarter.Model.charge field to be a float * to keep the Jmol code running, cast the float to be an int in viewer.datamodel.FrameBuilder.java * test everything and check it in Stage 2 - jmol.viewer.datamodel.Atom changes * add a float charge field to the datamodel.atom data structure * pass the float through the FrameBuilder and store it * cast the float to an int in Atom.getAtomicCharge() * test everything and check it in Stages 3-? - broader impact within Jmol * introduce a new method which returns a float ... Atom.getCharge() * find everyone who is calling the int getAtomicCharge() and change them one-by-one * I would test and check in after each caller was changed * Finally, delete the existing getAtomicCharge() method > Not sure if I can do this tomorrow, as it is an official day off friday... > Queen's Day... (birthday of queen mum). With all due respect ... didn't the Dutch queen mum pass away recently? Miguel ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
