Move some of the spline functions to splinepy

[jzwar]

I think at this point it would make sense to move some of the functionality of splines to splinepy, to make splinepy a more flexible library on its own.

I would suggest moving the following functions to splinepy:

• spline-conversions,

  <Bezier-spline>.bspline
  

• extract
  • Bezier extraction is mostly done in splinepy
  • extract boundaries
  • would allow for the extraction of related splines, such as determinant mappings, FFD improvements - tangled (?) #52

We could also think about moving create to splinepy.

ImO, it is not very consistent, where functions are placed, and it just grew that way historically, but splinepy would be more autonomous if we were to move these functions.

@j042 I would love to hear your opinion on this

[j042]

I've been thinking about this too. splinepy outgrew the original scope and is introducing some complexities. I generally agree with the idea, but I'd be even willing to go a step further. For example, here are two options:

1. everything except visualization
2. flip dependency

Second option will probably be a bit easier, since we can just use all the helpers from gustaf. This also means that we'd move all the micro-structure related implementations to splinepy.

[jzwar]

To you second point: I still consider gustaf as a wrapper for splinepy, mostly because of its mesh capabilities. Being able to manipulate meshes, exporting meshes based on splines and visualizing all kinds of geometry representations is beyond the scope of splinepy. Therefore gustaf is not only visualization.

I would also keep the microstructures in gustaf for now. But we might start somewhere. This would be some great HiWi works, as it is mostly copy-pasting + test writing.

As a first step, we can move all "single-spline" operations to splinepy, i.e., creator, extractor into helpme, see how we like it and continue, rather than doing everything in one ginormous PR

[j042]

you can also think of it as splinepy wraps gustaf to provide mesh capabilities. without flipping dependency, extractor becomes a bit annoying. For example, for something like spline.extract.faces(), we need to copy connectivity creation in splinepy.
We could of course implement some hooks to manage proper init, if that's what you'd prefer during the migration

[jzwar]

(Temporarily), we could make a similar NAME_TO_TYPE construct for the extractor class like the one we did for the splines. That way we could keep the mesh extractions in gustaf but move the spline extractions into splinepy.

[j042]

Let's flip

[j042]

Done