Difference map script additions

[alisiafadini]

I was originally thinking of contributing my DED map script, but I think it would be redundant with diffmap.py. Maybe we could integrate the extra bits I have to the existing script? Mainly it would be (1) option to specify PDB ref model, rather than providing phases (so people don't have to go trough SFALL or similar) and (2) option to also TV denoise the difference map and write out a second file (or an extra column in the mtz). Thoughts?

[kmdalton]

This sounds great to me, but this is really @JBGreisman 's script.

I am curious how you plan to compute structure factors here. My suggestion would be to run phenix.fmodel in a temporary directory and grab the results from the output mtz.

[alisiafadini]

@kmdalton for computing structure factors from the PDB model you mean? I've been using gemmi sfcalc in a function for now. It's pretty good except that it writes out an mtz that I then read back in. I think this can be fixed, just haven't figured it out yet

[kmdalton]

oh nice! i have never used gemmi for this. this sounds like a good idea to me. it would be nice if we could do it all in memory at the API level. perhaps we can ask for this to be implemented as a function. otherwise, i think we have to sift through the cpp source and translate it to python.

[JBGreisman]

It is always possible to handle the plumbing using temporary files as @kmdalton said. This is the approach used by rs.scaleit.

I also agree that it would be very nice if there were a Python API that could be exposed for this purpose. That would simplify things for us quite a bit. I'll look into that a bit and see what seems viable.

Just to summarize:

1. In general, it seems like it would be useful to have a utility function for handling this sort of --ref option: If a PDB is given, it runs sfcalc and if an MTZ+Phi is given it just uses those for phases. This seems like a separate "enhancement" that we can plan to add in the near future to the existing functions -- we currently assume someone has phases from fmodel/sfcalc/refinement
2. @alisiafadini I think a --denoise (or other flag) could be a useful interface for adding your function. I always like implementing it as an additional column so that the user can easily view the before/after.

[alisiafadini]

yes, exactly. I think the --ref option would be useful. I've found it nice not to have to go run CCP4 to get FCalcs, so having the option in case someone doesn't have phases yet would be great. I kind of have something similar now for Rfree flags (use previous ones if there's a column with flags specified in input mtz, if not generate new set).
I like the --denoise option too. Seems like the best way

[alisiafadini]

for gemmi sfcalc, from the documentation I thought I should be able to make it return calculated structure factors without making it write out the file. But have not figured it out yet. Can only run it with its --to-mtz option successfully

[tjlane]

Here: time to revive this conversation.

meteor provides a diffmap interface, and therefore can do everything rs.diffmap can do and more. I'd suggest we deprecate the booster code, include a message that points people to meteor. Of course, I am biased.

Thoughts @kmdalton @JBGreisman @dennisbrookner @alisiafadini ?

[kmdalton]

i'm in favor of any diffmap code that has sensible defaults for column labels. also tests. rs.diffmap has no tests.