Perhaps. But really I suspect it's something different. The isosurfaces
should be completely different objects -- they are initiated independently
and then merged at parallel function exit.
I'm headed in to where my MacBook is now.
On Mon, Aug 9, 2010 at 6:00 AM, Charles Shubert <cshub...@mit.edu> wrote:
> Hi Bob,
>
> Sounds like the conference was a success.
>
> As I noted in an earlier email, I'm generating the script and I don't
> exactly know when a particular script will be generated, so I then to
> sprinkle extra "subset"s and "select"s around to make sure that I know the
> selection state when I send a script to the Jmol interpreter.
>
> The important thing with this problem is to have multiple chains. I tend
> to use 1A3N (hemoglobin) because it has 4. I'm guessing that some of the
> recently added isosurface variables are either not being initialized or
> being overwritten when a parallel process executes. It has a
> not-thread-safe quality about it.
>
> I hope you got some vacation in,
>
> --Chuck
>
> ----- Original Message -----
> *From:* Robert Hanson <hans...@stolaf.edu>
> *To:* jmol-users@lists.sourceforge.net
> *Sent:* Monday, August 09, 2010 1:15 AM
> *Subject:* Re: [Jmol-users] BUG: Parallel isosurfaces changed between RC26
> and12.0.2
>
> Sorry for the delay -- was at the BCCE conference --
>
> "subset" and "select" are global settings -- you wouldn't want any of that
> in the process blocks. In addition, unless you have previously used subset,
> issuing it here has no effect. Just put it before the first process{}
> command.
>
> Also, select here has no effect on the isosurface command, since you have a
> select option there. And "A" is probably not defined anyway, so that's why
> you are getting 0 atoms selected.
>
> I'll check on my MacBook when I return to my office, as it uses 2
> processors and this laptop doesn't.
>
> Bob
>
>
> On Thu, Aug 5, 2010 at 1:45 PM, Charles Harrison Shubert <cshub...@mit.edu
> > wrote:
>
>> BUG: Parallel isosurfaces changed between RC26 and 12.0.2
>>
>> This looks to me like the cutoff, min, max variables are probably not
>> being initialized in the parallel threads as I would expect the parser to
>> whine if my syntax needed new extra stuff.
>>
>> When I run the following:
>>
>> load "/Users/cshubert/Downloads/1A3N.pdb";
>>
>> parallel makeIsos{
>> process{ subset; select {A and PROTEIN}; isoSurface surfaceA
>> select(within(chain,*:A)) ignore (within(chain,not *:A)) VDW 96 % color
>> TRANSLUCENT 0.0 [192,208,255] FILL;}
>> process{ subset; select {B and PROTEIN}; isoSurface surfaceB
>> select(within(chain,*:B)) ignore (within(chain,not *:B)) VDW 96 % color
>> TRANSLUCENT 0.0 [176,255,176] FILL;}
>> process{ subset; select {C and PROTEIN}; isoSurface surfaceC
>> select(within(chain,*:C)) ignore (within(chain,not *:C)) VDW 96 % color
>> TRANSLUCENT 0.0 [255,192,200] FILL;}
>> process{ subset; select {D and PROTEIN}; isoSurface surfaceD
>> select(within(chain,*:D)) ignore (within(chain,not *:D)) VDW 96 % color
>> TRANSLUCENT 0.0 [255,255,128] FILL;}
>> };
>> set multiProcessor true; show mulitProcessor;
>> makeIsos;
>> subset;
>>
>>
>> In RC 26 I get isosurfaces being drawn for the 4 chains of this hemoglobin
>> molecule and the following console output:
>>
>> $
>>
>> multiProcessor = true
>> mulitprocessor = <not defined>
>> 0 atoms selected
>> 0 atoms selected
>> 0 atoms selected
>> 0 atoms selected
>> surfaced created with cutoff=0.0; number of isosurfaces = 1
>> surfaceb created with cutoff=0.0; number of isosurfaces = 1
>> surfacec created with cutoff=0.0; number of isosurfaces = 1
>> surfacea created with cutoff=0.0; number of isosurfaces = 1
>> $
>>
>> In 12.0.2 I don't get the isosurfaces for the chains and I get the
>> following console output:
>>
>> $
>>
>> multiProcessor = true
>> mulitprocessor = <not defined>
>> 0 atoms selected
>> 0 atoms selected
>> 0 atoms selected
>> 0 atoms selected
>> surfacea created with cutoff=NaN min=0.0 max=0.0; number of isosurfaces
>> = 0
>> $
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> 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
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> 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
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
