Menu
▾
▴
Re: [Jmol-users] Strategies and problems in Jmol integration
|
From: Robert H. <ha...@st...> - 2009-06-29 15:05:24
|
On Mon, Jun 29, 2009 at 10:01 AM, Robert Hanson <ha...@st...> 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 <sab...@si...>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
>> Jmo...@li...
>> 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
|