-
Notifications
You must be signed in to change notification settings - Fork 21
Description
related to #41
Description:
When calling make_lstar1 with identical input parameters, the function returns a vector of different L* values.
For instance, calling this routine with the following inputs
ntime = 3
kext = 4
options = [1, 0, 0, 0, 0]
sysaxes = 1
X1 = [1. 1. 1.]
X2 = [1. 1. 1.]
X3 = [1. 1. 1.]
maginput = [[0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.
0.]
[0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.
0.]
[0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.
0.]]
Returns :
- Lstars = [2.30083614, 2.29254279, 2.28935006]
expected behavior :
+ Lstars = [2.30083614, 2.30083614, 2.30083614]
Lm = [2.31221887, 2.31221887, 2.31221887]
B = [8292.73332838, 8292.73332838, 8292.73332838]
Beq = [2353.17477373, 2353.17477373, 2353.17477373]
I = [1.87964672, 1.87964672, 1.87964672]
MLT = [3.45698638, 3.45698638, 3.45698638]It appears that the inconsistent L* values are caused by the COMMON variable Ilflag. This flag is correctly initialized to 0 when calling make_lstar1, but is set to 1 after the first successful L* computation. Once Ilflag = 1, the foot-point search no longer uses the initial linear guess based on the previous points of the current drift shell. Instead, it reuses the theta value computed from the previous call, which leads to inconsistent results for identical inputs.
I tracked this down to an initialization issue: Ilflag is used inside calcul_Lstar_opt to control whether a predicted foot point should be reused, but it is not reset between successive computations. As a result, computations after the first one use stale state from the previous iteration.
I will open a pull request to address this bug. In my view, it is better for the routine to fail consistently than to return inconsistent or state-dependent results.