[Ivan, I'm opening up this discussion to Jmol Developers who also might have
an interest in parallelization. Others -- Ivan has demonstrated creating
multiple isosurfaces on multiple processors with Jmol. We are now interested
in fleshing out a general way to do this. I know Miguel is interested in
this....]
Ivan,
Progress! OK, so we can demonstrate a big improvement in speed for
situations where one wants a set of different isosurfaces -- say, one per
model. If this doesn't take too much work, we should get it into Jmol 12.0
-- it is a radical improvement, definitely the stuff of whole new versions.
We want a general solution for any parallelization, not just for
isosurfaces. The select, ignore, etc. options are no problem, provided we
run these in distinct instances of ScriptEvaluator. My idea looks something
like this:
parallel{
...commands...
process{...process 1 commands...}
...commands...
process{...process 2 commands...}
...commands...
process{...process 3 commands...}
...commands...
}
Intent:
parallel { commands }
Indicates that parallel processes will be part of this segment of code and
that at the close of this group, we must wait for all processes to complete
and then do whatever is necessary (command-dependent) to merge the results
into our actual model set. Even LOAD commands could in principle be done
this way. I have to think about that.
process{ commands }
Only valid within a parallel context. Indicates that all commands in this
set are to be executed by a new independent thread (if available).
[Q: can we test this on non-parallel machines just be starting independent
threads on one CPU?]
How about these for basic guidelines?
1) Within a parallel { } block, variables in @{...} expressions will be
evaluated as usual based on the current variable settings assuming the
process { } commands have NOT been executed. That is, the process { }
commands will be precompiled, including all @{...} variable evaluation PRIOR
to running any of them.
2) Local variables ("var" keyword) within process{ } sets will be local to
that process.
3) Global variables may be used but not set within process{ } sets.
4) The flow of execution within parallel{ } and process{ } is as usual,
including evaluation of @{...} expressions within the commands. Thus, FOR,
WHILE, and IF all will work properly as a way to "set up" the parallel
process. However, the commands themselves within the process { } sets will
not be executed until the final closing } from the parallel block is
reached. Until then, they will only be compiled, meaning their @{...}
expressions will be evaluated PRIOR to ANY process{ } commands being run in
ANY process{ } set of a given parallel{ } block.
5) Certain commands such as SET, DELAY, and REFRESH will not be allowed
within process {} sets.
6) We will start with isosurface and go from there. As other commands are
parallelized, they will be added seamlessly.
Bob
Ivan
>
> P.S. When I was debugging Java 1.5 code, I noticed that Jmol does not print
> exceptions on the system console or jmol console. I traced it back to
> System.setOut() and System.setErr() methods.
> Two suggestions in that space: I noticed that you use Logger all
> over the code, so this seems to be legacy set of statements..
Logger is our preferred mechanism -- it's not a Java Logger, it's a Jmol
class -- org.jmol.util.Logger. It's very flexible, and it could use some
improvements.
--
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® 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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
