Roadmap to 1.0.0

[kinnala]

Some future plans (ping @gdmcbain).

I hope that the release 0.2.0 will be quite close to what 1.0.0 looks like, and then after a while go directly to 1.0.0.

I've started listing some issues that I hope to resolve before/during 0.2.x into the corresponding milestone. But I think the most important ones are those that we know to require backwards incompatible changes. One of them could be the load/submeshes/boundaries/_parse_submeshes refactoring that we have discussed (depending on how it will be done).

I also wonder if there is something that we want to drop from the scope. My academic research was closely related to Nitsche-type mortar methods and I spent quite a bit of time thinking how they should be incorporated into a generic code like this, but I'm still very unhappy with the result and think that making this properly requires too much of my time. So I'm almost ready to drop InterfaceMesh1d etc.

Are there any other major changes that we'd like to see before 0.2.0?

[gdmcbain]

The loading of submeshes and boundaries, mentioned in #180, but probably deserving its own issue, should be straightforward, I think, and not backwards incompatible. They'd be optional keyword arguments to the constructors.

I've been dragged away from the work on coupling subdomains #163, which is very closely related to the Nitsche-type mortar methods. It was going well, I didn't foresee any real hurdles. I wasn't going to use InterfaceMesh1d as I didn't want to have to specify the interface in terms of coordinates; rather something like Mesh.boundaries. There's some more work to be done, but I didn't think it would require any changes to the library, unless eventually perhaps some additions to encapsulate a recommended way of doing things (analogous to the wrappers of spilu and cg in utils).

The one issue which does have me scratching my head is serialization #158, specifically of higher order spaces like P2 which can't be avoided for Navier-Stokes work. One hesitates to invent a new mesh format, but I don't know of an existing one that handles fields like ElementTriP2 but where the underlying mesh only has corner nodes.

Also maybe the elemental support #192. Does that require a reworking of the assembly? It might not break the interface though.

[kinnala]

I started refactoring from_meshio in https://github.com/kinnala/scikit-fem/commits/prepare-release

I'm planning to also invent a new serialization format at the same go. Simply a json dictionary which can be passed to the new constructors, e.g. MeshTri(**serialized_dict). Contains keys p, t, boundaries and subdomains (going to rename submeshes to subdomains). Not yet sure how the different finite element solutions will be incorporated into the format. What do you think about this? The serializations might become too large?

[gdmcbain]

+1. I'll pick up on the serialization back at #158; briefly though, json's a good idea: it's very flexible, fits well with the scikit-fem approach of remaining within the Python Standard Library, and can easily be read or written by external systems if required.

[kinnala]

Accidentally closed this in one of the commits. So everything mentioned here is now more or less implemented. I have still some other issues that I'll resolve before releasing 0.2.0.

[kinnala]

I'm still going to fix #85 before 0.2.0. The rest are pushed forwards to 1.0.0. If you have some comments or ideas @gdmcbain we can also implement them before 0.2.0.

[gdmcbain]

Oops, sorry, I haven't had a chance to look at the progress on serialization.

One other lingering idea I did have for 1.0.0 was reviving dof locations #84. That issue was closed with the development of skfem.utils.L2_projection, which works fine but it's not quite as nice as simply being able to specify values as functions of the nodal coordinates. This is something which does arise often enough in practice; e.g. the parabolic inlet profile in ex24. In particular, I continue to wonder about the suggestion in the last comment on #84 (2019-04-03) about adding a method to GlobalBasis (which has access to its .elem and .mesh attributes), maybe called .x, which I think should be easy enough to write for the important P2 and Q2 elements but could reasonably return NotImplementedError by default.

[kinnala]

I reopened #84 so we can discuss the goal and I can make PoC.

[kinnala]

287 introduces a backwards-incompatible change. But soon after that I'd like to commit to semver.

[gdmcbain]

Good idea. I was going to ask for a reference on semantic versioning but I see that there's one in fe4e115.

[kinnala]

Checklist for myself:

• [x] deprecate old style forms
• [x] update README
• [ ] add new functions and methods to API docs

[kinnala]

I'm wondering if we should rename ElementH1 to ElementAffine, ElementH2 to ElementGlobal, ElementHdiv to ElementPiolaCovariant, ElementHcurl to ElementPiolaContravariant. These are mostly internal things so it shouldn't be a huge issue.

[gdmcbain]

Might need some docs to go along with that; I have heard of Hdiv and Hcurl but not Piola co- or contravariance.

I recall sometime ago in #23 your writing that one-dimensional Hermite beam elements weren't H1 conforming, which confused me as I'd thought that H1 meant that the functions and their gradients were square-integrable, like Hdiv and Hcurl for functions and their divergence or curl.. 'Global' and 'Piola' were mentioned at the time. I didn't follow up then but might yet as I plan to report on the primitive Orr-Sommerfeld equation to the Australasian Fluid Mechanics Conference in December and beam elements would be good for solving the classical fourth-order equation for comparison.

[kinnala]

I'm sorry, obviously one-dimensional Hermite beam elements are also H1 conforming. But I probably meant that they are also H2 conforming which is a more stricter requirement. H2 conformity requires continuous derivatives over element boundaries.

[gdmcbain]

Right, yes, thanks.