-
Notifications
You must be signed in to change notification settings - Fork 75
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
Roadmap to 1.0.0 #194
Comments
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 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 Also maybe the elemental support #192. Does that require a reworking of the assembly? It might not break the interface though. |
I started refactoring 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. |
+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. |
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. |
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 |
I reopened #84 so we can discuss the goal and I can make PoC. |
#287 introduces a backwards-incompatible change. But soon after that I'd like to commit to semver. |
Good idea. I was going to ask for a reference on semantic versioning but I see that there's one in fe4e115. |
Checklist for myself:
|
I'm wondering if we should rename |
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. |
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. |
Right, yes, thanks. |
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?
The text was updated successfully, but these errors were encountered: