best final score less than starting score

Hi Matthias,

Thanks for your error report. This looks like a bug in Frealix. I'll try to explain what's going on first and then will suggest a workaround.

What happened

In this run, you are refining waypoints one at a time (sequentially) rather than simultaneously. This is useful because it usually saves time by running the minimiser on a few dimensions at a time rather than all refinement dimensions for all waypoints simutaneously.

In this case, the problem occurs with filament #28.

At line 14729 of the log file, Frealix begins work on the 2nd possible polarity of the filament. First, it revserses the order of the waypoints (wp 8 becomes wp 1, wp 7 becomes wp 2 etc.), then it prints out the new waypoints at line 14735. Then, it computes the score for this polarity, and at line 14839 you can see the starting score (i.e. before refinement of the waypoints) is 0.112. This is considerably lower than the score obtained with polarity 1 (0.255), which tells us that the polarity of this filament had probably already been determined correctly in a previous round.
Then, the sequential refinement begins. At line 14930, refinement of waypoint 5 begins (it will do wps 5 to 8 and then 4 to 1). The actual minimization for wp 5 occurs in lines 15172 - 15210. For this particular waypoint, the minimizer did not improve the parameters, and in lines 15216 - 15226, Frealix prints out that no parameters changed (all the numbers are 0.000).
At 15302, refinement of wp 6 begins, and again the minimiser does not improve things.
At 15671, refinement of wp 7 begins and in this case, the minimiser does improve the score, from 0.11169 to 0.11816 (lines 15918 & 16017) by moving wp 7 by -1.5503 pixels in X and 17.4789 degrees in phi (line 16031).
At 16109, refinement of wp 4 begins (wp 8 was skipped because you told Frealix to ignore the first and last waypoints).
Now, one of the things I glossed over so far is that as waypoints are moving around, the average helical parameters for the filament are constantly updated. If the average helical parameters for the filament differ signficantly from the helical parameters of the reference 3D volume, then Frealix will re-symmetrize the volume before continuing.
In this case, moving waypoint 7 in phi caused the average twist to change significantly so that at line 16267, Frealix says it will symmetrise the reference volume with the new updated helical parameters.
This new symmetrised reference volume then does not agree quite as well with the filament image, which makes sense because so far everything was optimised against the old helical parameters, and now the score is slightly lower than it was before this new symmetrisation was done. At line 16337 you can see the score is now 0.096 before curvature penalty, whereas it was 0.123 before re-symmetrisation.

So this is the source of the problem.

Without the sanity check killing the job, I would expect things eventually to converge on a set of average helical parameters and alignment parameters, after a few refinement rounds.

There are several solutions to this

• Do not re-symmetrise the reference volume until all waypoints have been refined. This is what happens when waypoints are being refined simultaneously
• Turn off the sanity check when sequential refinement is being done. I think for you this is the easiest workaround for now.

Suggested workaround

So my suggested workaround would be to recompile Frealix with lines 335 to 346 of fmcs.f90 commented out. I think in future releases I will deactive all these "sanity checks", which are only in there to help me find potential bugs. during development. As I explained above, this particular check doesn't make sense given the algorithm.

Sorry about all the trouble & thanks for your patience.

Alexis