Hi, Ricardo. This sounds like a superb project. Much of it should be simpler than you imagine, I think. I like the way you are using scripts from your application. That is definitely the way to go. As you work on this, we may find ways to improve Jmol for similar uses. Feel free to communicate and ask as many questions as you need to. -- on jmol-developers, please.
Strategy suggestions embedded below. On Mon, Jun 29, 2009 at 3:45 AM, Riccardo Sabatini <[email protected]>wrote: > > The software will be able to open files containg several > different atomic configurations. All the editing and modelling part is > done with tables of atomic positions and with other tools (not visual) > and JMol is used only as a visualization tool and as a picking tools > (trough findNearestAtomIndex(x, y)). > If you are using this method, they you are creating a Viewer object instead of a JmolViewer object. If something isn't in JmolViewer that you need, please let me know. I think what you really want there is a pickCallback. We could talk about that.... > > In the DFT calculation is very common to import tens, or even > hunderds, of different configurations and then scroll along all of > them. Plus in the software i'm finishing i've implemented a way to > store objects or visualization details (specific atoms color, > distances....) in a specific configuration. To let this work properly > and without annoying time delays i've implemented this conceptual > architecture. > > ------------------------------------------------ > > 1) loads the new conf [not jmol] > 2) if the conf is connected to the one visualized (same atoms, same > cell): > 2.a) delete drawing objects "draw ID * DELETE" [evalString() > method] > 2.b) store the view point getProperty("getProperty", > "orientationInfo", "") [evalString() method] > 2.b) calculate the translation vector for each atom > 2.c) translate the atomos with "atomno=***; translateSelected > {x,y,z}" [evalString() method] > 2.d) paint the objects contained in the new conf [evalString() > method] > 2.e) restore the viewpoint and other view directives > contained in the new conf [evalString() method] > steps 2.b(storing) and 2.e should not be necessary. > > 3) if the conf is completely new > 3.a) produce a new string in the XYZ format and send it to > the code trough openStringInline() method > 3.b) paint new objects [evalString() method] > 3.c) set the conf. specific visualization options > [evalString() method] > The evalString() can be replaced with JmolViewer.script(String script); > > ------------------------------------------------ > > Now, BEFORE and AFTER any evalString() and openStringInline() > i've decided to check if jmol object was running or busy trough a very > easy call > > public void waitUntilFree() { > > while (jmolViewer.isScriptExecuting()) { > try { > Thread.sleep(100); > } catch (InterruptedException e) { > e.printStackTrace(); > } > } > > } > This should be totally unnecessary. Jmol will be queuing the script commands. > > This architecture works quite good and let's me scroll very fast > between different configurations (new ones and the ones only with the > atoms displaed in new positions). But still some problems appear when > a configuration has some obects to draw. Sometimes the code breaks and > gives this specific error > > Exception in thread "QueueThread0" java.lang.NullPointerException > at org.jmol.viewer.Viewer.loadShape(Unknown Source) > If you look in build.xml, there's a place there where you can set the debug flag to true. Then you get the source line numbers instead of "Unknown Source") There's your problem. Dont' mix openStringInline() with queued scripting. Just create a DATA command. That's what it is for. data "model x"\n xyzdatahere\n end "model x"\n and send that to JmolViewer.script() or Viewer.evalScript() That loads the model inline exactly the way you would like. > This happens when i try to send in the openStringInline() method > and i can't reproduce it with everytime. Sometimes happens, some other > times the code works flawlessy !! > right --- it's a threading issue. > > Do you have any idea why this error comes out ? > And, in general, do you have any reccomandations how to implement > in a better way the integration between jmol, maybe with threads ? > And, very last question, i saw in the last cvs version the > findNearestAtomIndex(x, y) was not anymore a public function and i had > to redeclare it, is there any plans to remove it ? I REALLY REALLY > hope not, it's extremeluy important for integratin jmol !! none of the public methods in Viewer are really "public" -- that is there only when other packages within Jmol are needing the method. The public methods are all in JmolViewer interface. Certainly I can add that (I just did -- see Jmol 11.7.46_dev) -- but you should think about using a pickCallBack method within a JmolStatusListener instead. See how that is done in Jmol.java. Bob > > > Thanks for the help, > > Riccardo > > > ---------------------------------------------------------------- > SISSA Webmail https://webmail.sissa.it/ > Powered by Horde http://www.horde.org/ > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jmol-users mailing list > [email protected] > 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
------------------------------------------------------------------------------
_______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
