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 >
