Thanks to Ian and Marcus. However, it turned out not to be a pltdev problem at all...
It looked like polarrfn was generating maps OK, but I guess not. When I ran the same thing on a Mac OSX everything worked. Great. I have some peaks. Now I need to think. Hmmm. Not sure what the problem was - other CCP4 things are running fine on the Suse box. For the moment, I have peaks and I guess I will ignore the problem and happily, blindly, carry on... Thanks Ed -----Original Message----- From: Ian Tickle [mailto:[EMAIL PROTECTED] Sent: Thu 3/6/2008 1:34 PM To: Thomas Edwards Cc: ccp4bb Subject: RE: polarrfn, pltdev Hi Thomas I normally run pltdev on the whole map, did you try that? There may be a problem just plotting one section because I think it may rescale the SRF values to the origin value on the first section, so if that happens to be zero on the kappa=180 section you'll get division by zero. The origin peak on the kappa=0 section cannot be zero! BTW I would recommend using E's instead of sharpening (via ECALC), since your B = -20 is completely arbitrary and may not be sufficient. Also you shouldn't specify resolution cutoffs at all, the low res cutoff is only needed if you don't have sharpening of any kind (otherwise the big F's at low res dominate). The high res cutoff isn't needed either because the SRF isn't like the cross-RF where differences in the model will give errors at high res. For the SRF there is no model! Sharpening & using all data helps to resolve peaks if the NCS is complicated or is close to the space group peaks (of course if you're only expecting 1 peak well separated from the space group peaks, it's not likely to affect to your conclusions). Finally having the radius cutoff too small may reduce the signal/noise ratio (both signal and noise increase with increasing R, the question is which one increases faster). I would suggest you try R=25 and R=30 as well as R=20 and see what happens. HTH Cheers -- Ian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Edwards > Sent: 06 March 2008 12:42 > To: ccp4bb > Subject: polarrfn, pltdev > > Dear CCP4BB, > > I'm trying to genereate some self rotations with polarrfn to > decide on the NCS and number of molecules in my AU. > > using polarrfn script (copied from the examples on the web): > > # > # Self-rotation function > # > set resolution = 15 3.5 > set radius = 20 > > # Calculate whole map, & search for peaks > polarrfn hklin p2221_33A mapout p2221_self << eof-1 > title p2221 Self-Rotation function, resolution ${resolution} > radius ${radius} > self ${radius} > resolution ${resolution} > crystal file 1 bfac -20 > labin file 1 F=F SIGF=SIGF > map > find 5 100 > eof-1 > > # Now plot just the kappa = 180 deg section > plot: > polarrfn hklin p2221_33A mapin p2221_self plot p2221_self << eof-2 > title p2221 Self-Rotation function, resolution ${resolution} > radius ${radius} > self ${radius} > resolution ${resolution} > crystal file 1 bfac -20 > labin file 1 F=F SIGF=SIGF > read 180 180 > plot 10 10 > eof-2 > > > As you can guess, I think I'm in p2221... The script seems to > run fine and spits out map and .plo files. > However, when I try to run pltdev to generate a postscript > file (this used to work in Unix in a previous lab...) > > pltdev -i p2221_self.plo > I get a file (plot84.ps) with lots of nan records (see below). > I'm running Suse 10.3, CCP4 6.0.2 > Any pointers in the right direction much appreciated. > > Thanks > Ed > > > %!PS-Adobe-3.0 > %%Creator: pltdev > %%Pages: 1 > %%BoundingBox: -2147483648 -2147483648 -2147483648 -2147483648 > %%EndComments > %%BeginProlog > /L {lineto} bind def > /M {moveto} bind def > /S {stroke} bind def > /N {newpath} bind def > %%EndProlog > %%Page: 1 1 > %%PageBoundingBox: -2147483648 -2147483648 -2147483648 -2147483648 > 0.8 setlinewidth 1 setlinejoin N 0 0 M > S N nan nan M > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > nan nan L > > Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [EMAIL PROTECTED] and destroy all copies of the message and any attached documents. Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof. Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
