**3)** If the voxel grid unit is not 1 mm (cfg.unitinmm), are the path lengths correct when computing the detected weights with mcx_replayprep() in the standalone mode in mcx/src/mcx_utils.c [Line3718](https://github.com/fangq/mcx/blob/89627a79428fc57695ec381362e58b15e1e88918/src/mcx_utils.c#L3718)? In the function mcx_replayinit() above for MATLAB/Python, 'plen' is scaled _after_ computing the weight on [Line3672](https://github.com/fangq/mcx/blob/89627a79428fc57695ec381362e58b15e1e88918/src/mcx_utils.c#L3672), since 'mua' is already scaled to account for cfg.unitinmm. This was fixed for the embedded mode in [orig_fix](https://github.com/fangq/mcx/commit/d9b2f2b44c29b2bac08bb5d502e67fc52a5437f0)

[fangq]

[fangq]

@HirviP, I confirm that in the standalone mode (not in matlab or python), the current handling of plen in mcx_replayprep() is correct, i.e. it should be scaled by cfg->unitinmm, before computing cfg->replay.weight. This is different from the mcx_replayinit() case in the embedded mode.

I know this is super confusing - because of the duplicated code in the two execution paths:

1. in the standalone mode: the call order is mcx_prepdomain -> mcx_loadseedjdat -> mcx_replayprep -> mcx_preprocess (where mua/mus are scaled)
2. in the embedded mode: the call order is mcx_validatecfg -> scale mua/mus -> mcx_replayinit

because the mua/mus scaling happened at different place relative to replay data computation, one before, one after, the standalone mode still requires temporarily scale mua by unitinmm before computing cfg->replay.weight. For this reason, I think the standalone mode handling is ok.