Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Huw, When I was at the workshop, I have to admit that after ccp4i2 refused to do it I switched to Phenix and used phenix.reflection_file_converter! It would be better if i2’s reindex or change spacegroup task didn’t refuse, and I guess this might improve after the overly-zealous consistency checking is relaxed, or cad could be used following your suggestion. As for how to report this in a publication, we actually ran into this when working on a Hyp-1 complex structure with Mariusz Jaskolski and Zbyszek Dauter, where the crystals were apparently perfectly tetartohedrally twinned. The apparent space group was some variant of P422 (which is how the data were processed and merged) but the true space group was identified as one choice of C2. Merging in the correct space group gave only 73% completeness, but the statistics for the data processed in higher symmetry were very similar so the expanded data set was used and deposited (https://doi.org/10.1107/s1399004713030319). Statistics for processing in both space groups were presented in Table 1. Best wishes, Randy > On 23 Feb 2024, at 13:45, Huw Jenkins wrote: > > Hi Randy, > >> On 23 Feb 2024, at 11:49, Randy John Read wrote: >> >> Why would we want to impose an arbitrary restriction on users for this >> relatively common scenario. > > If the user has the unmerged data this can be imported into CCP4i2 via the > data reduction task and merged in P1. How would you expand the merged data to > P1 - using cad from a script? Perhaps this should be made possible in CCP4i2 > after the merged data were imported. i2 already has a "Reindex or change > spacegroup" task (using POINTLESS) but it won't do this: > > "FATAL ERROR: > Specified SPACEGROUP P1 must belong to same crystal system and point group > as the input space group P 41 21 2" > >> >> Note that this kind of confusion between twinning and true symmetry will >> mostly arise when the twin fractions are close to equal. Then: a) the >> twin-related intensities should really be measurements of the same thing, >> and you get more precise data by making them equal; b) the superimposed >> diffraction patterns will obey the higher symmetry, although the spots might >> start to split at higher resolution. >> >> I would also argue that, if the twin fractions are experimentally >> indistinguishable from being equal, processing in higher symmetry and >> expanding the data to the correct lower symmetry is the correct approach to >> take for your final data set. > > That's a fair comment. In that case would you then report the merging > statistics for the higher symmetry data in "Table 1" and note that the merged > data were subsequently expanded to the correct lower symmetry? > > > Huw - Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: +44 1223 336500 The Keith Peters Building Hills Road E-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Randy, > On 23 Feb 2024, at 11:49, Randy John Read wrote: > > Why would we want to impose an arbitrary restriction on users for this > relatively common scenario. If the user has the unmerged data this can be imported into CCP4i2 via the data reduction task and merged in P1. How would you expand the merged data to P1 - using cad from a script? Perhaps this should be made possible in CCP4i2 after the merged data were imported. i2 already has a "Reindex or change spacegroup" task (using POINTLESS) but it won't do this: "FATAL ERROR: Specified SPACEGROUP P1 must belong to same crystal system and point group as the input space group P 41 21 2" > > Note that this kind of confusion between twinning and true symmetry will > mostly arise when the twin fractions are close to equal. Then: a) the > twin-related intensities should really be measurements of the same thing, and > you get more precise data by making them equal; b) the superimposed > diffraction patterns will obey the higher symmetry, although the spots might > start to split at higher resolution. > > I would also argue that, if the twin fractions are experimentally > indistinguishable from being equal, processing in higher symmetry and > expanding the data to the correct lower symmetry is the correct approach to > take for your final data set. That's a fair comment. In that case would you then report the merging statistics for the higher symmetry data in "Table 1" and note that the merged data were subsequently expanded to the correct lower symmetry? Huw To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
On Fri, Feb 23, 2024 at 9:58 AM Winter, Graeme (DLSLtd,RAL,LSCI) < 6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > While I get where you are coming from, it is still from a mathematical > standpoint correct to consider e.g. a tetragonal crystal as monoclinic - > P21 is a subgroup of P43212 (say) so strictly it is possible and correct - > if experimentally unlikely - to have the situation we are discussing here > occur. > Actually all values of beta are equally likely (up to a certain point, larger angles, say > 120, obviously become much less likely because it's likely that the cell can be transformed into one with a smaller angle). 90. is just as likely as 90.0001, and 90.0002, and 90.0003 ... . If I ask what's the chance that the next structure determination in monoclinic will have beta = 91.2345 it's exactly the same chance as it will have beta = 90. . Logically if we exclude 90. on the grounds that it's very unlikely we should exclude all values! Obviously if I ask what's the chance beta will be _anything_ other than 90, that's a false comparison. 10 heads in a row has a chance of 2^-10 and so does any random sequence I name before the toss (say HHHTTHHTHT): the point is I'm doing the choosing. Cheers -- Ian To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Harry, I remember the C222/P622 confusion from some of Phil's old slides, and I thought that was an impressive case! It probably appears in a few places on the internet, but one I found just now is slide 15 of this presentation: https://www.ccp4.ac.uk/schools/DLS-2015/course_material/Datareduction2015.pdf Cheers -- David On Fri, 23 Feb 2024 at 10:17, Harry Powell < 193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote: > Hi Graeme (I may well have mentioned this when we shared an office) et al > > I’ll add something from my small-molecule crystallography days, when we > used point detectors - so this would be pre-1996 which was the last time I > used one of these machines. > > I don’t remember which structure it was (feel free to go through the CSD > to check on my behalf, but many structures were not deposited in those days > and languish in a PhD thesis!); I had a dataset with three 90º angles, but > the processing statistics (and overall cell volume) indicated quite plainly > that it was monoclinic (probably P21). I re-refined the unit cell as if it > were triclinic and the “best” 90 degree angle with the smallest ESD was the > one that corresponded to the monoclinic beta; the two 90º angles refined > away from their true value more. > > A result of that experiment was that (since then) I never assumed that the > values of the angles from the data processing showed unambiguously that I > had a high symmetry solution. I believe that Pointless arose after a > hexagonal/C-centred orthorhombic ambiguity arose (but my memory could be > faulty here). > > Best wishes > > Harry > > > On 23 Feb 2024, at 09:58, Winter, Graeme (DLSLtd,RAL,LSCI) < > 6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > > > Hi Huw > > > > (first: thank to Phil for picking this up; it caused much confusion) > > > > While I get where you are coming from, it is still from a mathematical > standpoint correct to consider e.g. a tetragonal crystal as monoclinic - > P21 is a subgroup of P43212 (say) so strictly it is possible and correct - > if experimentally unlikely - to have the situation we are discussing here > occur. > > > > Also, under merging data to investigate twinning is a current bb topic. > > > > Telling users to “fiddle the parameters” so that the strict test is > satisfied feels like a non-ideal answer: a warning when importing such data > could be legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this > is unusual, I hope you know what you are doing” rather than a flat out > error. > > > > Literally I got involved as I had a dials user ask me how to do this > parameter fiddling in a more niche case and I thought that was a suboptimal > solution to an artificial problem :-) > > > > On a personal note, I think it is important that the tools we develop > still allow people to explore problems rather than railroading them down > one true route which is the only allowed way to look at a problem: we learn > a lot by exploring odd corners as here. > > > > Best wishes Graeme > > > >> On 23 Feb 2024, at 09:49, Huw Jenkins wrote: > >> > >> [You don't often get email from h.t.jenk...@me.com. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > >> > >> Hi Graeme, > >> > >>> On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) < > 6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > >>> > >>> Processing a data set in lower than necessary symmetry e.g. tetragonal > as monoclinic you _cannot_ import the merged MTZ file into i2 because it is > impossible to have 90 degree angles for P21 > >> > >> I had a look at the code in CCP4i2 that generates the errors in the > screenshots you posted. The first one is only generated if two cell > parameters are *exactly* equal and the second is generated when beta is > between 89. and 90.0001 degrees. > >> > >> I think these tests should only fail if the data were processed > assuming higher symmetry so that unit cell parameters were restrained and > then the space group changed to a lower symmetry one. Isn't the correct > approach when the true symmetry is lower than originally assumed to repeat > the data processing without applying constraints imposed by the higher > symmetry - because, for example, cell parameters refined assuming cell > length/angle constraints may not predict the reflection positions as well > as if these restraints were not applied, reflections assumed to be symmetry > equivalent when they weren't may lead to suboptimal scaling etc etc? > >> > >> > >> Huw > > > > > > -- > > This e-mail and any attachments may contain confidential, copyright and > or privileged material, and are for the use of the intended addressee only. > If you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not > use, copy, retain, distribute or disclose the information in or attached to > the e-mail. > > Any opinions expressed within this e-mail are those
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Huw, This is tricky because in certain situations the cell parameter esds can get lost. For example if best_unit_cell= has been passed during scaling or merging with DIALS. Or, if cell parameter refinement was done using the LFBGS engine, in which case the esds are not calculated. Cheers David On Fri, 23 Feb 2024, 10:40 Huw Jenkins, < 288da93ae744-dmarc-requ...@jiscmail.ac.uk> wrote: > > On 23 Feb 2024, at 09:58, Winter, Graeme (DLSLtd,RAL,LSCI) < > 6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > > > so strictly it is possible and correct - if experimentally unlikely - > to have the situation we are discussing here occur. > > I believe this is only technically possible because the MTZ format does > not store esds on the unit cell parameters? In the thaumatin example > processing the dataset here - https://zenodo.org/records/4916649 - > assuming monoclinic symmetry results in unit cell: > > 58.176(2), 150.543(4), 58.2050(18), 90.0, 90.1058(9), 90.0 > > The situation you describe would result in for example: > > 58.1087(18), 150.543(4), 58.1087(15), 90.0, 90.(1), 90.0 > > and the test should really only fail for: > > 58.1087(18), 58.1087(18), 150.400(5), 90.0, 90.0, 90.0 > > i.e. where a=b have same value and esd (as they were constrained to be > identical and esd on beta is 0 as it was constrained to be 90. > > > > > Telling users to “fiddle the parameters” so that the strict test is > satisfied feels like a non-ideal answer: a warning when importing such data > could be legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this > is unusual, I hope you know what you are doing” rather than a flat out error > > I think you have misunderstood here. I was suggesting telling users to > integrate/scale the data without imposing higher symmetry was the correct > thing to do? I don't see how "fiddling of parameters" is required. > > But I agree i2 should allow an override of this test. > > > Huw > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 > > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are > available at https://www.jiscmail.ac.uk/policyandsecurity/ > To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
In the recent crystallography workshop in Thailand, we had at least 3 cases brought by participants where we had reason to suspect that the data had been over-merged because of undetected twinning. Often there is more than one possible twinning operator and (as potentially in one of the cases brought up recently on this BB) the easiest way to sort out the true symmetry is just to expand the data to P1 and solve the structure by looking for the appropriate expanded number of copies. If the data are of reasonable quality (case-dependent) and the model is good (true more often than not, in these post-AlphaFold days), the multicopy MR solution can be pretty straightforward. Once you have a better idea of the true symmetry, then would be a good time to try reprocessing the data without assuming too high symmetry. Why would we want to impose an arbitrary restriction on users for this relatively common scenario. Note that this kind of confusion between twinning and true symmetry will mostly arise when the twin fractions are close to equal. Then: a) the twin-related intensities should really be measurements of the same thing, and you get more precise data by making them equal; b) the superimposed diffraction patterns will obey the higher symmetry, although the spots might start to split at higher resolution. I would also argue that, if the twin fractions are experimentally indistinguishable from being equal, processing in higher symmetry and expanding the data to the correct lower symmetry is the correct approach to take for your final data set. Obviously you still want to try to process the data in the correct space group to make this decision, looking at things like whether the observations related by true symmetry are more highly correlated than observations related by the twin operator(s). Best wishes, Randy > On 23 Feb 2024, at 10:39, Huw Jenkins > <288da93ae744-dmarc-requ...@jiscmail.ac.uk> wrote: > >> On 23 Feb 2024, at 09:58, Winter, Graeme (DLSLtd,RAL,LSCI) >> <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: >> >> so strictly it is possible and correct - if experimentally unlikely - to >> have the situation we are discussing here occur. > > I believe this is only technically possible because the MTZ format does not > store esds on the unit cell parameters? In the thaumatin example processing > the dataset here - https://zenodo.org/records/4916649 - assuming monoclinic > symmetry results in unit cell: > > 58.176(2), 150.543(4), 58.2050(18), 90.0, 90.1058(9), 90.0 > > The situation you describe would result in for example: > > 58.1087(18), 150.543(4), 58.1087(15), 90.0, 90.(1), 90.0 > > and the test should really only fail for: > > 58.1087(18), 58.1087(18), 150.400(5), 90.0, 90.0, 90.0 > > i.e. where a=b have same value and esd (as they were constrained to be > identical and esd on beta is 0 as it was constrained to be 90. > > > >> Telling users to “fiddle the parameters” so that the strict test is >> satisfied feels like a non-ideal answer: a warning when importing such data >> could be legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this is >> unusual, I hope you know what you are doing” rather than a flat out error > > I think you have misunderstood here. I was suggesting telling users to > integrate/scale the data without imposing higher symmetry was the correct > thing to do? I don't see how "fiddling of parameters" is required. > > But I agree i2 should allow an override of this test. > > > Huw > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 > > This message was issued to members of http://www.jiscmail.ac.uk/CCP4BB, a > mailing list hosted by http://www.jiscmail.ac.uk/, terms & conditions are > available at https://www.jiscmail.ac.uk/policyandsecurity/ - Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: +44 1223 336500 The Keith Peters Building Hills Road E-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
> On 23 Feb 2024, at 09:58, Winter, Graeme (DLSLtd,RAL,LSCI) > <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > so strictly it is possible and correct - if experimentally unlikely - to > have the situation we are discussing here occur. I believe this is only technically possible because the MTZ format does not store esds on the unit cell parameters? In the thaumatin example processing the dataset here - https://zenodo.org/records/4916649 - assuming monoclinic symmetry results in unit cell: 58.176(2), 150.543(4), 58.2050(18), 90.0, 90.1058(9), 90.0 The situation you describe would result in for example: 58.1087(18), 150.543(4), 58.1087(15), 90.0, 90.(1), 90.0 and the test should really only fail for: 58.1087(18), 58.1087(18), 150.400(5), 90.0, 90.0, 90.0 i.e. where a=b have same value and esd (as they were constrained to be identical and esd on beta is 0 as it was constrained to be 90. > Telling users to “fiddle the parameters” so that the strict test is satisfied > feels like a non-ideal answer: a warning when importing such data could be > legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this is unusual, > I hope you know what you are doing” rather than a flat out error I think you have misunderstood here. I was suggesting telling users to integrate/scale the data without imposing higher symmetry was the correct thing to do? I don't see how "fiddling of parameters" is required. But I agree i2 should allow an override of this test. Huw To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Graeme (I may well have mentioned this when we shared an office) et al I’ll add something from my small-molecule crystallography days, when we used point detectors - so this would be pre-1996 which was the last time I used one of these machines. I don’t remember which structure it was (feel free to go through the CSD to check on my behalf, but many structures were not deposited in those days and languish in a PhD thesis!); I had a dataset with three 90º angles, but the processing statistics (and overall cell volume) indicated quite plainly that it was monoclinic (probably P21). I re-refined the unit cell as if it were triclinic and the “best” 90 degree angle with the smallest ESD was the one that corresponded to the monoclinic beta; the two 90º angles refined away from their true value more. A result of that experiment was that (since then) I never assumed that the values of the angles from the data processing showed unambiguously that I had a high symmetry solution. I believe that Pointless arose after a hexagonal/C-centred orthorhombic ambiguity arose (but my memory could be faulty here). Best wishes Harry > On 23 Feb 2024, at 09:58, Winter, Graeme (DLSLtd,RAL,LSCI) > <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > Hi Huw > > (first: thank to Phil for picking this up; it caused much confusion) > > While I get where you are coming from, it is still from a mathematical > standpoint correct to consider e.g. a tetragonal crystal as monoclinic - P21 > is a subgroup of P43212 (say) so strictly it is possible and correct - if > experimentally unlikely - to have the situation we are discussing here occur. > > Also, under merging data to investigate twinning is a current bb topic. > > Telling users to “fiddle the parameters” so that the strict test is satisfied > feels like a non-ideal answer: a warning when importing such data could be > legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this is unusual, > I hope you know what you are doing” rather than a flat out error. > > Literally I got involved as I had a dials user ask me how to do this > parameter fiddling in a more niche case and I thought that was a suboptimal > solution to an artificial problem :-) > > On a personal note, I think it is important that the tools we develop still > allow people to explore problems rather than railroading them down one true > route which is the only allowed way to look at a problem: we learn a lot by > exploring odd corners as here. > > Best wishes Graeme > >> On 23 Feb 2024, at 09:49, Huw Jenkins wrote: >> >> [You don't often get email from h.t.jenk...@me.com. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Hi Graeme, >> >>> On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) >>> <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: >>> >>> Processing a data set in lower than necessary symmetry e.g. tetragonal as >>> monoclinic you _cannot_ import the merged MTZ file into i2 because it is >>> impossible to have 90 degree angles for P21 >> >> I had a look at the code in CCP4i2 that generates the errors in the >> screenshots you posted. The first one is only generated if two cell >> parameters are *exactly* equal and the second is generated when beta is >> between 89. and 90.0001 degrees. >> >> I think these tests should only fail if the data were processed assuming >> higher symmetry so that unit cell parameters were restrained and then the >> space group changed to a lower symmetry one. Isn't the correct approach when >> the true symmetry is lower than originally assumed to repeat the data >> processing without applying constraints imposed by the higher symmetry - >> because, for example, cell parameters refined assuming cell length/angle >> constraints may not predict the reflection positions as well as if these >> restraints were not applied, reflections assumed to be symmetry equivalent >> when they weren't may lead to suboptimal scaling etc etc? >> >> >> Huw > > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any > attachments are free from viruses and we cannot accept liability for any > damage which you may sustain as a result of software viruses which may be > transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Huw (first: thank to Phil for picking this up; it caused much confusion) While I get where you are coming from, it is still from a mathematical standpoint correct to consider e.g. a tetragonal crystal as monoclinic - P21 is a subgroup of P43212 (say) so strictly it is possible and correct - if experimentally unlikely - to have the situation we are discussing here occur. Also, under merging data to investigate twinning is a current bb topic. Telling users to “fiddle the parameters” so that the strict test is satisfied feels like a non-ideal answer: a warning when importing such data could be legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this is unusual, I hope you know what you are doing” rather than a flat out error. Literally I got involved as I had a dials user ask me how to do this parameter fiddling in a more niche case and I thought that was a suboptimal solution to an artificial problem :-) On a personal note, I think it is important that the tools we develop still allow people to explore problems rather than railroading them down one true route which is the only allowed way to look at a problem: we learn a lot by exploring odd corners as here. Best wishes Graeme > On 23 Feb 2024, at 09:49, Huw Jenkins wrote: > > [You don't often get email from h.t.jenk...@me.com. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Graeme, > >> On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) >> <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: >> >> Processing a data set in lower than necessary symmetry e.g. tetragonal as >> monoclinic you _cannot_ import the merged MTZ file into i2 because it is >> impossible to have 90 degree angles for P21 > > I had a look at the code in CCP4i2 that generates the errors in the > screenshots you posted. The first one is only generated if two cell > parameters are *exactly* equal and the second is generated when beta is > between 89. and 90.0001 degrees. > > I think these tests should only fail if the data were processed assuming > higher symmetry so that unit cell parameters were restrained and then the > space group changed to a lower symmetry one. Isn't the correct approach when > the true symmetry is lower than originally assumed to repeat the data > processing without applying constraints imposed by the higher symmetry - > because, for example, cell parameters refined assuming cell length/angle > constraints may not predict the reflection positions as well as if these > restraints were not applied, reflections assumed to be symmetry equivalent > when they weren't may lead to suboptimal scaling etc etc? > > > Huw -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
Hi Graeme, > On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) > <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > Processing a data set in lower than necessary symmetry e.g. tetragonal as > monoclinic you _cannot_ import the merged MTZ file into i2 because it is > impossible to have 90 degree angles for P21 I had a look at the code in CCP4i2 that generates the errors in the screenshots you posted. The first one is only generated if two cell parameters are *exactly* equal and the second is generated when beta is between 89. and 90.0001 degrees. I think these tests should only fail if the data were processed assuming higher symmetry so that unit cell parameters were restrained and then the space group changed to a lower symmetry one. Isn't the correct approach when the true symmetry is lower than originally assumed to repeat the data processing without applying constraints imposed by the higher symmetry - because, for example, cell parameters refined assuming cell length/angle constraints may not predict the reflection positions as well as if these restraints were not applied, reflections assumed to be symmetry equivalent when they weren't may lead to suboptimal scaling etc etc? Huw To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [ccp4bb] i2 won't accept 90 degree angles in moniclinic
That looks like an unnecessarily severe test buried in the i2 library, which maybe should just be a warning. I can probably have a look at it Phil Sent from my iPad > On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) > <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote: > > > CAUTION: This email originated from outside of the LMB: > .-owner-ccp...@jiscmail.ac.uk-. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > If you think this is a phishing email, please forward it to > phish...@mrc-lmb.cam.ac.uk > Tried reporting to i2 dev list but it got bounced - feels like something > others may hit so don’t feel _too_ bad sending to the bb with a tiny > attachment > > > > > > > Hi Folks > > Helping someone out with some rather specialist data processing challenges > and she hit a problem: I can reproduce this with very boring thaumatin data > so I think this is a bug > > (it obliquely relates some to a current CCP4bb thread about MR, in passing) > > Processing a data set in lower than necessary symmetry e.g. tetragonal as > monoclinic you _cannot_ import the merged MTZ file into i2 because it is > impossible to have 90 degree angles for P21 > > Well, it is possible, and also, it is still correct to under merge the data > so this is a bug? Is this a reasonable viewpoint to hold? > > Many thanks Graeme > > > -- > > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any > attachments are free from viruses and we cannot accept liability for any > damage which you may sustain as a result of software viruses which may be > transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
[ccp4bb] i2 won't accept 90 degree angles in moniclinic
Tried reporting to i2 dev list but it got bounced - feels like something others may hit so don’t feel _too_ bad sending to the bb with a tiny attachment [cid:CA3CE9EB-841D-41A3-A41E-F79714492B21] Hi Folks Helping someone out with some rather specialist data processing challenges and she hit a problem: I can reproduce this with very boring thaumatin data so I think this is a bug (it obliquely relates some to a current CCP4bb thread about MR, in passing) Processing a data set in lower than necessary symmetry e.g. tetragonal as monoclinic you _cannot_ import the merged MTZ file into i2 because it is impossible to have 90 degree angles for P21 Well, it is possible, and also, it is still correct to under merge the data so this is a bug? Is this a reasonable viewpoint to hold? Many thanks Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
