third read, different again
On Mon, Sep 8, 2014 at 7:40 AM, Robert Hanson <hans...@stolaf.edu> wrote:
> yes. First one -- first load, garbage, second load maybe OK, but probably
> partially garbage. Not sure about that flat "surface"
>
> On Mon, Sep 8, 2014 at 7:31 AM, <chris.w...@stfc.ac.uk> wrote:
>
>> A couple of (perhaps not very useful) answers:
>>
>> - it is only a single machine
>> - the file is a static file that I uploaded - it's not being calculated
>> on the fly
>>
>> I've just uploaded another 2 mrc files to the server - do you get the
>> same problems with these?
>> http://www.ccpem.ac.uk/jsmol_test/data/emd_1494.mrc and
>> http://www.ccpem.ac.uk/jsmol_test/data/emd_1998.mrc
>>
>> Chris
>>
>>
>>
>>
>> From: Robert Hanson [hans...@stolaf.edu]
>>
>> Sent: 08 September 2014 13:13
>>
>> To: jmol-users@lists.sourceforge.net
>>
>> Subject: Re: [Jmol-users] Setting cutoff with some maps causes map to
>> fail to load
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> OK, here's a twist: When I download the file and then read it from disk,
>> it reads perfectly. When I load it as "
>> http://www.ccpem.ac.uk/jsmol_test/data/1akeA_10A.mrc";
>> Jmol reads trash.
>>
>>
>>
>>
>> Actually, the problem is intermittent. One time I read the following
>> (blocks of 8 bytes, shown starting at byte 12828). This is correct and
>> leads to a good isosurface:
>>
>>
>>
>> bindoc 12828 [-40,95,-126,42,0,0,0,0]
>>
>> 713187288
>>
>> bindoc 12832 [86,-70,32,46,0,0,0,0]
>>
>> 773896790
>>
>> bindoc 12836 [120,-11,-123,48,0,0,0,0]
>>
>> 814085496
>>
>>
>>
>>
>> and then a minute later, when I read the same file from that address, I
>> got this:
>>
>>
>>
>> bindoc 12828 [0,0,-40,95,0,0,0,0]
>>
>> 1607991296 (3.112888E19)
>>
>> bindoc 12832 [-126,42,86,-70,0,0,0,0]
>>
>> -1168758142
>>
>> bindoc 12836 [32,46,120,-11,0,0,0,0]
>>
>> -176673248
>>
>>
>>
>>
>> I think you can see how the bytes are very strangely shifted. I can't
>> imagine this is a problem on the Jmol end. Maybe there are two machines on
>> the ccp4 end, and one is failing.
>>
>>
>>
>>
>>
>> ah-- I just tried it again, and I got a different set of garbage. The
>> fact that the shifting is only in the first 4 of the 8 bytes of the float
>> value suggests that some program on your end is calculating these on the
>> fly and has a bug.
>>
>>
>>
>>
>>
>>
>>
>> Who manages this server?
>>
>>
>>
>> Bob
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Department of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> 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
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
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
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
