gemmi::transform_map_to_f_phi conjugates the forward FFT at the end (a structure factor is the sum over exp(+2 pi i h.x), a forward FFT the sum over exp(-2 pi i h.x)); MapToFPhi did not, so every model-path Fcalc and Fmask came out with its phase negated. Amplitudes, and so the R-factors and the scale, were unaffected; the phases of the maps and everything read off them (map coefficients, density at atom centres) were not. Caught by ModelValidation_MapToFPhiMatchesGemmi, which now passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nW6FNRP1bBJJ8pfHiByAT
19 lines
1.1 KiB
C
19 lines
1.1 KiB
C
// SPDX-FileCopyrightText: 2026 Filip Leonarski, Paul Scherrer Institute <filip.leonarski@psi.ch>
|
|
// SPDX-License-Identifier: GPL-3.0-only
|
|
|
|
#pragma once
|
|
|
|
#include "gemmi/grid.hpp"
|
|
#include "gemmi/recgrid.hpp"
|
|
|
|
// The structure factors of a real-space map on the model path (Fcalc from the model density, Fmask
|
|
// from the bulk-solvent mask): what gemmi::transform_map_to_f_phi(map, true) returns - the
|
|
// conjugated forward transform (F = sum rho exp(+2 pi i h.x)) scaled by V/N, kept for l >= 0 on an (nu, nv, nw/2+1) grid in the map's own XYZ order,
|
|
// ready for prepare_asu_data() - computed with FFTW rather than gemmi's single-threaded pocketfft.
|
|
// The same transform, not the same bits: the two libraries order their arithmetic differently.
|
|
//
|
|
// Plans are FFTW_ESTIMATE only - MEASURE would time candidate algorithms and could pick a different
|
|
// one from run to run - and made once per grid size and kept, so the rigid body's hundred-odd
|
|
// evaluations on one grid plan once. Safe to call from several threads at once.
|
|
gemmi::FPhiGrid<float> MapToFPhi(const gemmi::Grid<float> &map);
|