PS in the computerese jargon this is called "backwards compatibility" :)
I. On 11 December 2012 09:08, Ian Tickle <ianj...@gmail.com> wrote: > Hi Edward > > I agree with you that this can't be right. First, the rotation function > should allow 2 different cells: in fact that's how it's normally run: the > model from the known structure is placed in a large unit cell that is > unrelated to the unit cell of the unknown structure (in order to avoid > self-vectors). Second, if the unit cells are different then ALMN certainly > shouldn't make them equal! > > Looking at the code the warning message that you reported actually comes > from s/r RBFRO1 in the RWBROOK library that is normally used for reading & > writing PDB files: however in the case of ALMN there are no PDB files, just > 2 MTZ files! RBFRO1 is just being used to compute the orthogonalisation > matrices for each MTZ file. Unfortunately in RBFRO1 there's also a > potentially nasty side effect: if it's given 2 unit cells in separate calls > it makes the 2nd one equal to the 1st! This is probably designed for the > situation where you want to read multiple PDB files and you want them all > in the same unit cell. > > I suspect what's happened is that RBFRO1 has been changed to check for > multiple cells since ALMN was last updated, but the wider consequences of > the change weren't realised. I have always campaigned to have the names of > library subroutines changed whenever the external functional effects of the > s/r call change. That explains e.g. why we have MSYMLB, MSYMLB1, MSYMLB2 & > MSYMLB3 all superficially doing the same thing but in fact they are subtly > different in function (or at least we used to have 4 versions, it seems we > have only the #2 & #3 versions now - I trust no-one's programs are still > using the now unsupported versions!). So the functionally changed version > of RBFRO1 should have been called e.g. RBFRO2. This would have meant that > the changes to the library routines would not affect existing programs like > ALMN (and more particularly my own programs!). I think the library > maintainers don't always appreciate that these library routines are used by > many 'jiffy' programs that never get submitted to CCP4 - it's not just the > programs in the CCP4 distribution that are potentially affected by this! > > I think there's an easy and harmless way to fix this in the ALMN code: > RWBROOK has an initialisation call XYZINIT which resets the COMMON > blocks,so if this is called before RBFRO1 it won't try to make the cells > equal. > > Cheers > > -- Ian > > > > On 10 December 2012 21:47, Edward A. Berry <ber...@upstate.edu> wrote: > >> I am experimenting with ALMN cross-rotation using some old known >> structures. >> I was surprised to see what seems to be a requirement for the cell >> dimensions >> of the two crystals to be the same. Is that the case? >> Excerpts from the log follow. >> eab >> >> Data line--- CROSS 5 30 >> . .. >> OPENED INPUT MTZ FILE >> Logical Name: HKLIN Filename: /a/denzo/als060729/azx02/** >> chbc1azx02r12.mtz >> . . . >> * Cell Dimensions : (obsolete - refer to dataset cell dimensions above) >> 170.1490 181.3120 240.5010 90.0000 90.0000 90.0000 >> . . . >> OPENED INPUT MTZ FILE >> Logical Name: HKLIN2 Filename: /a/denzo/ant101master/ant101_** >> complete.mtz >> . . . >> * Cell Dimensions : (obsolete - refer to dataset cell dimensions above) >> 128.7980 168.5290 231.6520 90.0000 90.0000 90.0000 >> . . . >> Inconsistency in Cell Dimensions - replacing old: >> Old cell: 170.14900 181.31200 240.50101 90.00000 90.00000 90.00000 >> New cell: 128.79800 168.52901 231.65199 90.00000 90.00000 90.00000 >> >> If it is really changing the cell parameters of one of the datasets, >> won't that distort the patterson and interfere with correlation? >> Am I doing something wrong? >> The two files are specified as HKLIN and HKLIN2 >> > >
