Multibody refinement initial offset search parameters are multiplied by an extra factor of pixel size

[fullerjamesr]

For multibody refinement, values given by the user for Initial offset search range and Initial offset search step in pixels get multiplied by one-too-many factors of the pixel size, at least in the context of what is reported in run.out

In angstroms, I expect that the values given in the GUI in pixels to be converted to angstroms (which is the unit in run.out) by multiplying by the pixel size (pixels * angpix). Indeed, this is the behavior for Refine3D, Class3D, etc.

However, for MultiBody jobs, the translational searches as noted in the run.out log file appear to be the result of (pixels * angpix * angpix), i.e., multiplied by an additional factor of angpix, for both the initial search range and step.

I'm not sure if this behavior effects only in what is printed to the log file, or if the actual underlying searches being performed are true to the log file values? Apologies in advance if this is intended behavior and I've misunderstood something.

Environment:

• OS: RHEL 8.4
• MPI runtime: OpenMPI 4.1.1
• RELION version: RELION-5.0-beta-1-commit-b75b38
• Memory: 256 GB
• GPU: A40

Dataset:

• Box size: 224 px
• Pixel size: 1.666 A/px
• Number of particles: 418482

Job options:

• Type of job: MultiBody
• Number of MPI processes: 5
• Number of threads: 8
• Full command:

`which relion_refine_mpi` --continue Refine3D/job085/run_it017_optimiser.star --o MultiBody/job094/run --solvent_correct_fsc --multibody_masks multibody_setups/3body_01.star --blush  --oversampling 1 --healpix_order 4 --auto_local_healpix_order 4 --offset_range 3.296308523409364 --offset_step 1.7625 --dont_combine_weights_via_disc --scratch_dir $TMPDIR --pool 30 --pad 1  --j 8 --gpu "" --pipeline_control MultiBody/job094/

Edit to add:

I wonder if this is an issue in ml_optimiser.cpp with the conditional statement at line 2024? From my brief read of the code, in the context of multibody refinement (which uses the --continue flag), the conversion to angstroms is already done in parseContinue but iter might still start out at 0?