-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
signed curvature #1085
signed curvature #1085
Conversation
| benchmark_name | dt(%) | dt(s) | t_new(s) | t_old(s) |
| -------------------------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------- |
test_build_transform_fft_lowres | +4.63 +/- 7.31 | +2.39e-02 +/- 3.78e-02 | 5.41e-01 +/- 3.6e-02 | 5.17e-01 +/- 1.3e-02 |
test_build_transform_fft_midres | -0.85 +/- 5.61 | -5.26e-03 +/- 3.49e-02 | 6.16e-01 +/- 1.7e-02 | 6.21e-01 +/- 3.0e-02 |
test_build_transform_fft_highres | -3.10 +/- 2.78 | -3.24e-02 +/- 2.90e-02 | 1.01e+00 +/- 2.1e-02 | 1.04e+00 +/- 2.0e-02 |
test_equilibrium_init_lowres | +6.80 +/- 4.68 | +2.59e-01 +/- 1.78e-01 | 4.07e+00 +/- 9.3e-02 | 3.81e+00 +/- 1.5e-01 |
test_equilibrium_init_medres | +0.96 +/- 3.47 | +4.06e-02 +/- 1.47e-01 | 4.28e+00 +/- 1.0e-01 | 4.24e+00 +/- 1.0e-01 |
test_equilibrium_init_highres | -0.00 +/- 1.71 | -7.19e-05 +/- 9.61e-02 | 5.63e+00 +/- 4.8e-02 | 5.63e+00 +/- 8.3e-02 |
test_objective_compile_dshape_current | +0.90 +/- 3.47 | +3.47e-02 +/- 1.34e-01 | 3.89e+00 +/- 2.7e-02 | 3.85e+00 +/- 1.3e-01 |
test_objective_compile_atf | -0.99 +/- 1.79 | -8.38e-02 +/- 1.51e-01 | 8.38e+00 +/- 1.2e-01 | 8.47e+00 +/- 9.1e-02 |
test_objective_compute_dshape_current | -1.55 +/- 3.75 | -1.97e-05 +/- 4.76e-05 | 1.25e-03 +/- 3.9e-05 | 1.27e-03 +/- 2.8e-05 |
test_objective_compute_atf | -11.73 +/- 6.37 | -5.72e-04 +/- 3.11e-04 | 4.31e-03 +/- 1.5e-04 | 4.88e-03 +/- 2.7e-04 |
test_objective_jac_dshape_current | +1.31 +/- 10.87 | +4.92e-04 +/- 4.10e-03 | 3.82e-02 +/- 3.7e-03 | 3.77e-02 +/- 1.8e-03 |
test_objective_jac_atf | +0.65 +/- 4.69 | +1.23e-02 +/- 8.91e-02 | 1.91e+00 +/- 4.5e-02 | 1.90e+00 +/- 7.7e-02 |
test_perturb_1 | +0.96 +/- 3.30 | +1.31e-01 +/- 4.51e-01 | 1.38e+01 +/- 4.0e-01 | 1.37e+01 +/- 2.1e-01 |
test_perturb_2 | +1.18 +/- 1.55 | +2.17e-01 +/- 2.84e-01 | 1.86e+01 +/- 2.0e-01 | 1.84e+01 +/- 2.0e-01 |
test_proximal_jac_atf | +1.37 +/- 1.15 | +1.01e-01 +/- 8.55e-02 | 7.51e+00 +/- 6.5e-02 | 7.40e+00 +/- 5.6e-02 |
test_proximal_freeb_compute | -1.30 +/- 0.85 | -2.33e-03 +/- 1.53e-03 | 1.77e-01 +/- 9.6e-04 | 1.79e-01 +/- 1.2e-03 |
test_proximal_freeb_jac | +0.63 +/- 1.55 | +4.70e-02 +/- 1.15e-01 | 7.44e+00 +/- 1.1e-01 | 7.40e+00 +/- 4.0e-02 |
test_solve_fixed_iter | -5.34 +/- 7.34 | -8.48e-01 +/- 1.17e+00 | 1.50e+01 +/- 6.4e-01 | 1.59e+01 +/- 9.8e-01 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few typos, main comment is about the sign convention and possible confusion with people used to unsigned curvature.
Also, suppose we flipped our parameterization s -> -s, then the frenet frame would flip, and wouldn't that make the curvature change sign? even though the curve is the same?
desc/objectives/_coils.py
Outdated
@@ -395,7 +396,7 @@ def __init__( | |||
name="coil curvature", | |||
): | |||
if target is None and bounds is None: | |||
bounds = (0, 1) | |||
bounds = (-1, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might want to throw a warning if the user passes in bounds like (0, max) since that wouldn't be possible i think (if a circle has curvature -1)? For people used to unsigned curvature this might be confusing. Or maybe we just flip our sign convention so that a circle has positive curvature? though that slighlty conflicts with our convention for surface curvature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could also have a flag for whether to use signed or unsigned curvature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish our sign convention was flipped (positive = convex), but I went with the sign convention we already use for the surface curvature. I would be fine with changing them both.
A closed curve has to be convex at some points, but in theory you could target a curve to be locally concave in certain regions. And I think there is a conceivable use case for targeting positive curvature everywhere, even though it is not possible, to try and force the coils to be straight (low curvature everywhere).
Instead of a flag for signed/unsigned, I think the better solution would be to add a loss_function="abs"
option. But that can be a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree the sign convention is annoying, I based it on several textbooks which define positive curvature of a surface as curving towards the outward normal vector to the surface.
I don't think we necessarily have to keep the same convention for curves, since signed curvature for non-planar curves isn't even necessarily well defined, and to me it makes more sense to define it such that a circle has positive curvature.
At the very least, I think we should include a note in the docstring for the curvature objective reminding users of the sign convention.
If we flip the parameterization, the tangent vector will flip but the normal vector will still point inwards towards the center of local curvature. The normal vector is what gets used to determine the sign of the curvature, so I think this should be fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
address changes and it will be good to go
J2 = jax.jacrev(self._fun)(params) | ||
for key in J1.keys(): | ||
assert np.all(J1[key] == J2[key]), "Function must be linear!" | ||
for j1, j2 in zip(tree_leaves(J1), tree_leaves(J2)): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was this change needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is technically unrelated to the signed curvature, but I threw it in this PR (sorry). This change is necessary to allow LinearObjectiveFromUser
to work with an OptimizableCollection
like a CoilSet
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this tested anywhere in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new functionality is not tested in this PR. But there are existing tests for LinearObjectiveFromUser
that still pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #1130 for a test of this new functionality
And fix the docs |
@@ -1665,7 +1670,7 @@ def __init__(self, *coils, name="", check_intersection=True): | |||
@property | |||
def num_coils(self): | |||
"""int: Number of coils.""" | |||
return sum([c.num_coils if hasattr(c, "num_coils") else 1 for c in self]) | |||
return sum([c.num_coils for c in self]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work for a nested coilset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should, because num_coils will just get called recursively until the self is a single coilset
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there was a change for linear objective from user to have it work with optimizable collections, I'd like to see it tested if possible. If not in this PR then make an issue to test it in the future
I just added a test for it in #1130, which will now fail until this PR is merged. |
Resolves #1039
Also fixes a bug in
FourierRZCurve.compute(["x_s", "x_ss", "x_sss"])
.Need to add tests for the following:
"center"
FourierPlanarCoil
with both"xyz"
and"rpz"
basisCoilCurvature
objective tests