luc-j-bourhis / smtbx-paper Goto Github PK

[Richard's point 4] Should we include the current addresses for Luc and me (especially Luc as corresponding author, and I don't know if you want OlexSys address also for Oleg/Horst/Judith), in addition to the Durham address?

We need to mention we handle it and a few words about which method is used

[Richard's point 24] Equation 39 (just after "The former must be evaluated for every function, whereas the latter is constant for a given unit cell.") just appears to be stuck in between two paragraphs, with no associated text. It is only reference in the text much later on.

[Richard's point 5] I am not particularly keen on the sentence including "viz a viz" in
the introduction - could we reword that and possibly make it a bit less
personal towards GMS/shelxl?

[Richard's point 22] Perhaps the section on twinning, especially the description of
different kind of twins could be reduced, and we just refer readers to the
various Herbst-Irmer & Sheldrick papers. We could just explain the
distinction in treatment of twins where the reciprocal lattices are
(almost) exactly superimposed and non-merohedral twins (although I prefer
the terminology "multiple lattices" here now). Speaking of the latter,
hasn't Oleg implemented support for hklf5 refinement in smtbx/olex2.refine?
Perhaps Oleg should add a few words here regarding his implementation.

We should:

• either specify somewhere that all computations are done in double precision – that incurs a 2x slowdown, and CRYSTALS and SHELXL being proofs that robust refinement can be done in single precision, it will be hard to justify that decision;
• or change the source code so that the normal matrix accumulation is done in single precision (that's the only hotspot of relevance).

[Richard's point 3] The main part of the paper ends a bit abruptly - I think we could do
with some kind of discussion, conclusions, maybe mention of source code
availability/licensing. Do we need some example refinements (I am not sure
about this one)?

The section about restraints, the one about constraints and the appendix about L.S. with a scale repeat the same stuff.

This is not directly relevant to anything we present but we could mention it in the introduction of section 6.2.1 (to be nice to David to start with!)

Richard's point 26

[Richard's point 27] Appendix C on "Minimisation of Least-Squares with an overall scale factor": "well known that the overall scale factor tends to be
highly correlated with the thermal displacements" - can we add a reference
here?

[Richard's point 32] then we can also cite the iotbx.cif paper.

We have Flack and t'Hooft but there is no mention of it in the paper

I have used \partial F / \partial x whereas Richard uses \nabla

[Richard's point 29] Just a comment on footnote 9 about sine/cosine computation - have we compared/quantified the
difference in speed for trigonometric functions vs tabulated sines and
cosines, and the effect of the precision on the overall results? (this is
just out of interest, and possibly to support our decision to use the
trigonometric functions).

[Richard's point 11] section 3.2: Isn't REFMAC still fundamentally CGLS? I was under the impression that it was using pre-conditioned CGLS, and that sparse normal
matrix algorithms were just part of the pre-conditioning of the CGLS, but I
could be wrong. Do you have a REFMAC reference that says such a thing?

[Richard's point 17] Section 4: I think this needs some kind of brief introduction, as
the first sentence suddenly seems to come out of nowhere! This is probably
up to me to do something about this though.

[Richard's point 18] Top of second column of page 4: "never performing products that involve" - maybe "computations" or "multiplications" could be better here? (I am not so sure)

[Richard's point 9] Page 3: "by bailing out with an error if it detects a cycle in the
graph" - I think we need a less informal description than "bailing out with
an error", and also an explanation of what exactly you mean by "a cycle in
the graph".