On Mon, Jun 29, 2009 at 10:01 AM, Robert Hanson <[email protected]> wrote:
> 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 > -- 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
