[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Phraenquex VD <loretta@scripps.edu>*Subject*: Re: [ccp4bb]: xyzlimit*From*: Anastassis Perrakis <perrakis@embl-grenoble.fr>*Date*: Tue, 28 Nov 2000 11:09:25 +0100*CC*: Bernhard Rupp <br@llnl.gov>, ccp4bb@dl.ac.uk*References*: <Pine.SGI.3.96.1001127221033.28773B-100000@patterson>*Reply-To*: perrakis@embl-grenoble.fr*Sender*: owner-ccp4bb@dl.ac.uk

Not that I really know how it works, but here's an absolutely filthy fixif you have limits ( 0 64 )

that seems to work, at least for the spacegroups which I tried. If you

specify GRID SAMPLE in FFT, then there's a line in the log file that says

"Map limits in grid points on xyz"

and some numbers. Add 1 (one) to those numbers and give them to EXTEND as

grid, then ARP is happy.I wish I knew why.

that is 65 grid points total, thats where the magic 1 comes from ...

(but in any case Bernhard had 192 grid points too little on c ..ie totally wrong

au limits for ARP definitions)

BUT, again, the easiest is simply to define the AU limits

in fractional coors in mapmask ... just take care in trigonal and cubic
sg's

to use 0.334 instead of 0.333333 and 0.0834 instead of 0.08333333

There are consistent inconsistencies with real space asymmetric units between the various programs :-(

Ah, yes, this is an ellegant description of the situation.

I actually think that only ARP is 'inconsistent', but its very

polite on telling you what it really needs as AU limits.

A.

**Follow-Ups**:**Re: [ccp4bb]: xyzlimit***From:*Clemens Vonrhein <vonrhein@GlobalPhasing.com>

**References**:**Re: [ccp4bb]: xyzlimit***From:*Phraenquex VD <loretta@scripps.edu>

- Prev by Date:
**[ccp4bb]: Re: xyzlimit** - Next by Date:
**Re: [ccp4bb]: Re: xyzlimit** - Prev by thread:
**Re: [ccp4bb]: xyzlimit** - Next by thread:
**Re: [ccp4bb]: xyzlimit** - Index(es):