Refactor surface and curve compute methods

[f0uriest]

• Replaces the individual methods compute_coordinates, compute_normal etc of Curve and Surface objects with a generic compute method similar to the one used in the Equilibrium class.
• This allows us to share a lot of the desc.compute infrastructure with new classes and reduces duplicated code.
• Removes grid and transform attributes from Curve and Surface classes, these are now built on the fly in the compute method.
• FourierXYZCurve now has seperate basis for X, Y, Z for consistency with other classes.

Resolves #559

[ddudt]

Now there are two difference compute functions both with the name "V". I'm confused about when one is called over the other. Does this new one only get called for FourierRZToroidalSurface, and the original one gets called for all other classes? But this new one is actually more general, where as the original one will only work for an Equilibrium.

[ddudt]

If the new compute function is valid in all use cases, can we replace the old one instead of having two different functions that compute the same quantity?

If we need to keep both implementations, we should add a test to check them against each other.

[f0uriest]

The new one is more general and could replace the old one, I'll make that change.

[f0uriest]

actually its a bit tricky. The new compute function is only correct if the grid has nodes along the LCFS, while the original one assumes quadrature nodes in the volume, which genreally are a bit short of the LCFS. in eq.compute we use a quadrature grid to compute everything with dim==0, but that will give an incorrect result with the new compute method (Surface.compute uses a linear grid so its correct using the new method)

[ddudt]

OK. It still seems messy to have redundant compute methods. Should we add a parameterization to the old method to specify it works for Equilibrium? We need something to document when to use one over the other.

[f0uriest]

the default parameterization is Equilibrium unless otherwise specified. I don't think its much of an issue since users will never really interact with these functions directly.

[dpanici]

I noticed a couple things

• we don't have the same sort of logic setup in the curve and surface compute functions for ensuring that when we calculate things and a grid is passed in, that things stay broadcastable. Is that fine? I know for stuff like length it is a scalar and does not matter, and it was really more important for calculating 1D profiles that we wanted to then be able to multiple with 3D quantities, but is there nothing analagous for the Surface class let's say?
• There isn't any logic to check that a passed-in grid has nonzero N resolution for the Curve compute function, or nonzero M,N resolution for the Surface compute function. That could be good to add

[f0uriest]

I noticed a couple things

* we don't have the same sort of logic setup in the curve and surface  compute functions for ensuring that when we calculate things and a grid is passed in, that things stay broadcastable. Is that fine? I know for stuff like length it is a scalar and does not matter, and it was really more important for calculating 1D profiles that we wanted to then be able to multiple with 3D quantities, but is there nothing analagous for the Surface class let's say?

* There isn't any logic to check that a passed-in grid has nonzero N resolution for the Curve compute function, or nonzero M,N resolution for the Surface compute function. That could be good to add

I dont think there are any broadcasting issues, since everything for curves and surfaces is either a scalar or a function over the whole curve/surface, so everything should work fine.
For the grids, I think its fine if it has N=0, ie, if you just want to compute something at a single point.

[dpanici]

I noticed a couple things

* we don't have the same sort of logic setup in the curve and surface  compute functions for ensuring that when we calculate things and a grid is passed in, that things stay broadcastable. Is that fine? I know for stuff like length it is a scalar and does not matter, and it was really more important for calculating 1D profiles that we wanted to then be able to multiple with 3D quantities, but is there nothing analagous for the Surface class let's say?

* There isn't any logic to check that a passed-in grid has nonzero N resolution for the Curve compute function, or nonzero M,N resolution for the Surface compute function. That could be good to add

I dont think there are any broadcasting issues, since everything for curves and surfaces is either a scalar or a function over the whole curve/surface, so everything should work fine. For the grids, I think its fine if it has N=0, ie, if you just want to compute something at a single point.

Right, but if length is computed with a N=0 grid, it will be completely incorrect right?

[f0uriest]

Ah OK i see what you mean. Like how we always compute volume on a quadrature grid and profiles on a linear grid, then seed the data dictionary with those values. I can do something similar for curves/surfaces