mtz2cif capable of handling map coefficients

From: Francis E Reyes
Date: 5 April 2012 16:25
It seems that deposition of map coefficients is a good idea. Does someone have an mtz2cif that can handle this?

Thanks!

F


----------
From: Pete Meyer
Have you tried mtz2various (with cif output)?

Pete

----------
From: Ethan Merritt

On Thursday, April 05, 2012 08:25:05 am Francis E Reyes wrote:
> It seems that deposition of map coefficients is a good idea.
> Does someone have an mtz2cif that can handle this?

Maybe I missed something.
What is accomplished by depositing map coefficients that isn't
done better by depositing Fo and Fc?

       Ethan

-

----------
From: Miller, Mitchell D.
I have not tried it, but the latest version of the rcsb
program sf-convert is supposed to support it
(see version 1.2 released March 23)
http://sw-tools.pdb.org/apps/SF-CONVERT/index.html
http://sw-tools.pdb.org/apps/SF-CONVERT/doc/V1-2-00/documentation.html
(Version 1.2 is not yet available as a binary download)
Regards,
Mitch

----------
From: Phil Jeffrey
Fc doesn't contain the weighting scheme used in the creation of the map coefficients, so Fc would require some sort of program to be run to recreate those for both 2Fo-Fc and Fo-Fc maps. By which time you might as well run a single cycle of the refinement program in question to generate new map coefficients - so I don't see the benefit of Fc.

The map coefficients, on the other hand, are a checkpoint of the maps being looked at by the author at the time of deposition and don't require programs beyond a typical visualization program (i.e. Coot) to view.

Phil Jeffrey
Princeton

----------
From: Ethan Merritt

On Thursday, April 05, 2012 09:30:25 am Phil Jeffrey wrote:
> Fc doesn't contain the weighting scheme used in the creation of the map
> coefficients, so Fc would require some sort of program to be run to
> recreate those for both 2Fo-Fc and Fo-Fc maps.

The viewers I am familiar with do this for themselves on the fly.
No need to involve additional programs. In fact, generating and storing
map coefficients is not part of my work flow, since none of the programs
I normally use need them to be pre-calculated.

> By which time you might
> as well run a single cycle of the refinement program in question to
> generate new map coefficients - so I don't see the benefit of Fc.

You must use a different tool set than I do.

> The map coefficients, on the other hand, are a checkpoint of the maps
> being looked at by the author at the time of deposition and don't
> require programs beyond a typical visualization program (i.e. Coot) to view.

But is that a good thing or a bad thing?

I would rather make my own call about weighting and choice of maps,
so I would rather have the Fo and Fc.  Anyhow, Coot reads in and displays
maps just fine from an mtz or cif file containing Fo and Fc but no
map coefficients.   It is true that usually you want to have a value for
the FOM or other weight avalailable also.

       cheers,

               Ethan

> Phil Jeffrey

----------
From: Oliver Smart

On Thu, 5 Apr 2012, Ethan Merritt wrote:

On Thursday, April 05, 2012 09:30:25 am Phil Jeffrey wrote:

Fc doesn't contain the weighting scheme used in the creation of the map
coefficients, so Fc would require some sort of program to be run to
recreate those for both 2Fo-Fc and Fo-Fc maps.

The viewers I am familiar with do this for themselves on the fly.
No need to involve additional programs. In fact, generating and storing
map coefficients is not part of my work flow, since none of the programs
I normally use need them to be pre-calculated.

Ethan,

If you load a mtz file from refmac or BUSTER then this file contains Map Coefficients. Different programs and protocols produce different maps. So I second Phil's comment that including map coefficients in deposition is a really good thing. It will enable people to see exactly the maps as seen by the depositor (and to do so in a few years time). Hence we have included map coefficients in 3 recent depositions 3syu, 3urp, 3v56 (using a prototype mtz2cif tool that is not quite ready for release yet).

We have also worked out how to patch ccp4 cif2mtz so that it can do the reverse process see

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ccp4bb;325e1870.1112


Regards,

Oliver

----------
From: Ethan Merritt

On Thursday, April 05, 2012 10:48:16 am Oliver Smart wrote:
>
> On Thu, 5 Apr 2012, Ethan Merritt wrote:
>
> > On Thursday, April 05, 2012 09:30:25 am Phil Jeffrey wrote:
> >> Fc doesn't contain the weighting scheme used in the creation of the map
> >> coefficients, so Fc would require some sort of program to be run to
> >> recreate those for both 2Fo-Fc and Fo-Fc maps.
> >
> > The viewers I am familiar with do this for themselves on the fly.
> > No need to involve additional programs. In fact, generating and storing
> > map coefficients is not part of my work flow, since none of the programs
> > I normally use need them to be pre-calculated.
> >
>
>
> Ethan,
>
> If you load a mtz file from refmac or BUSTER then this file contains Map
> Coefficients. Different programs and protocols produce different maps.

I am bowing out of this discussion with apologies for any confusion that
I caused.

I have realized that there may be a generational difference in
understanding the term "map coefficient" (or else my poor brain is just
not functioning as well as it ought to).  I thought that the proposal was
to require depositing the equivalent of a ccp4 *.map file, i.e. the
real-space side of the Fourier transform.  I see now that people are
using "map coefficient" to mean "weighted F", which was not what I originally
understood.

   please carry on!

           Ethan

> So
> I second Phil's comment that including map coefficients in deposition is a
> really good thing. It will enable people to see exactly the maps as seen
> by the depositor (and to do so in a few years time). Hence we have
> included map coefficients in 3 recent depositions 3syu, 3urp, 3v56 (using
> a prototype mtz2cif tool that is not quite ready for release yet).
>
> We have also worked out how to patch ccp4 cif2mtz so that it can do the
> reverse process see
>
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ccp4bb;325e1870.1112
>
>
> Regards,
>
> Oliver
>