bugfix for lsqml where we *always* use joint obj and probe step lengths even though the flag is set to false

[a4894z]

Just a quick bugfix in LSQML that causes the use of joint obj and probe step length calculation even if we set the flag to true telling it to use independent step length calculation

[mdw771]

Just a quick bugfix in LSQML that causes the use of joint obj and probe step length calculation even if we set the flag to true telling it to use independent step length calculation

The existing code isn't a bug, it's the intended behavior. As the name suggests, that option is only relevant when the object is multislice. If it is multislice and this option is True, it calculates the step sizes jointly. For single-slice object, it is supposed to always calculate object and probe sizes jointly. This is also consistent with the logic in PtychoShelves. Any particular reason you want to calculate object/probe steps independently for single-slice?

[a4894z]

Just a quick bugfix in LSQML that causes the use of joint obj and probe step length calculation even if we set the flag to true telling it to use independent step length calculation

The existing code isn't a bug, it's the intended behavior. As the name suggests, that option is only relevant when the object is multislice. If it is multislice and this option is True, it calculates the step sizes jointly. For single-slice object, it is supposed to always calculate object and probe sizes jointly. This is also consistent with the logic in PtychoShelves. Any particular reason you want to calculate object/probe steps independently for single-slice?

The math for joint step length calculation is incorrect; step lengths should always be real and positive here and the current code has a hack that zeros out any negative steps in the real part (red curve) and totally ignores the imag part (blue curve).

I have the corrected version implemented (black curve) but haven't tried to push it here yet, treating the faulty current version as the default (see attached image).

As a work around, I've just been doing non-joint probe and sample step calculations in a separate branch (the non-joint versions are mathematically correct), and it's working fine for me...the faulty current version for joint step calculation is occasionally unstable numerically for me but then again it could be that I'm using a object step scalar (from PtyChi options) of ~5.0 instead of the default 1.0.

Would it be better to change this pull request with the option to use non-joint steps for sample and probe on-demand, but leaving the faulty current version still the default?

[mdw771]

Ok, fair enough. I split the option into single_slice_solve_obj_prb_step_size_jointly and multislice_solve_obj_prb_step_size_jointly. The single slice one defaults to True, multislice one defaults to False so that the default behavior is unchanged.