Is there any interest in creating a FEM Julia organization?

JuliaDiffEq has 60 repos currently. Unless something like github folders or similar gets implemented, I would think this is getting beyond a number easily handled. So, subgroups/organizations of JuliaDiffEq could be good. Possible Orgs: PDE, IVP, SDE spring to mind. Alternatively a repo which has a TOC might be the easier solution.

not up to date but WIP: http://juliadiffeq.org/packages.html . I wish we could pin the webpage to be more of a landing than the Github org page which is generally uninformative.

There is definitely a question of how to scale Github orgs. I’m not sure if continuing to split is a good idea. But it might be a good idea to make the split simply to reduce Travis times.

The issue is when things are one and the same. Solving SDEs and solving PDEs isn’t necessarily different. Neither is solving ODEs and PDEs.

1 Like

@ChrisRackauckas so if I understand correctly, you want to make a single package where a user can specify a PDE/SDE/ODE problem, give input data, and choose solver settings then the package will build the problem (and the solver), solve it and allow for post-processing, sort of like JuMP for differential equations? I assume making the solvers fully compatible will be much harder, if at all possible, than simply creating a modelling and user interaction layer on top. And while timestepping methods are used in dynamic PDE solvers for example, doesn’t this just mean that DifferentialEquations will be used as a dependency in these other specialized solvers? So there is not much that can be done on the DifferentialEquations side apart from documenting the internals perhaps to make it easier to integrate by other solver writers. Is this roughly the vision or did I miss something?

Spot on.

Yes. Which is why we’re doing this first. This is the whole problem types thing detailed in the manual. Then the modeling layer was https://github.com/JuliaDiffEq/ParameterizedFunctions.jl , but in order to be more flexible we will need a new one (https://github.com/JuliaDiffEq/DiffEqDSL.jl/issues/1).

No the specialized solvers just need to pull the timestepping methods directly.

No. In order to accommodate the full range of PDE methods, the ability to split and performantly utilize linear operators is a must. There’s been some big steps here already (http://docs.juliadiffeq.org/latest/solvers/split_ode_solve.html#OrdinaryDiffEq.jl-2), but there needs to be more control (https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/issues/90 and https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/issues/115).

I see, so there seems to be 2 distinct efforts here, one to add more ODE solvers required by the other more specialized solvers, or make them more performant, and the other is to make a DSL that can talk to existing solvers of different classes of differential equations and provide a unified user experience.

This discussion took off nicely.

My motivation was another thread (Pruning and quality control for the package ecosystem). I believe, as do others on that thread, that organizations might be a natural and effective way of ensuring quality of packages. An organization might develop a sort of multi-mind intelligence and memory.

I don’t think there’s any real reason for the packages in an organization to comply with a single API or a design principle.
For instance, for time- (or parameter-) independent BVPs (boundary value problems) there’s no reason why they should have an API usable from within IVP (ODE) solvers. Similarly time-space methods will have no need of the method of lines, and so on.

I do agree that if I have a particular BVP and I want to apply two different packages to its solution, it would be nice if the problem could be defined just once and the backend (the solution package) could be chosen on the fly. But that sort of thing is probably best left to the individual developers within an organization…

Yes, and there is a 3rd project that needs to happen which is the development of the toolboxes for spatial discretization. I did the easy finite difference one (which still needs work for more boundary conditions though), but am conceding that doing the others, like FEM and spectral toolboxes, can be an entire organization of their own and I’ll just use their results there.

1 Like

Sorry for going a little off topic!

I don’t think anybody is advocating for that. Though actually that’s an easy way to build some parallel-in-time ODE solvers…

The idea is moreso that, for common PDEs, say the Heat Equation, u_t = u_xx + f(t,u), and different packages can offer different ways to solve the same problem and spit out a solution. For smaller and stiffer discretizations you use a space-time implicit discretization, while when it gets bigger you might need to go to MOL. As long as we can offer a HeatEquationProblem which has a known interpretation and a set way to handle the solution, what package or algorithm solves it is just an intermediate choice. Somehow in that problem the user needs to specify the spatial discretization, which is where we would just pull from whatever FEM org builds the right tools.

True. That would be nice.

And what about the name? It seems that JuliaPDE is a natural, but what about JuliaPartialDiffEq?

Or, JuliaPDESolvers?

And any ideas for the logo?

Maybe too FEM-centric?
image

1 Like

I realized when discussing this that it’ll have to have so much documentation that it’s no way it can be contained in the same docs. It’ll definitely need its own sister site, and so a sister org is probably the right way to go. I created JuliaPDE and invited @PetrKryslUCSD and will make him another admin. Over the next week or so I will migrate the finite difference tools (DiffEqOperators.jl), the DiffEq FEM toolboxes (which will probably deprecate over time), and FEniCS.jl. Long before trying to get something integrated, I think we should try to get good toolboxes and “one-off” solvers to do the pieces, and then try to tie it together later.

2 Likes

Yes it is. I guess we have failed to get more contributors to join and bring their packages to JuliaFEM organisation. I guess we should have get some of the core developers to join our organisation in order to build up the trust that this is definitely part of the julia community. Anyway I guess things naturally evolve in open source community and this is a good thread to talk about our issue to get more, or minimum one, core developers to join our JuliaFEM organisation.

The organization that I (and others on this thread) envision is an umbrella for multiple projects, for multiple methods for PDEs, for multiple physics domains (perhaps solid and fluid mechanics, heat transfer, EMF, …), and also perhaps for multiple abstraction levels (general second-order PDEs vs one particular PDE, …).

At least for me the motivation would be to provide a place where Julians can go when they are looking for a package to help them with some code.

I may be wrong, but INVITING developers of relevant packages to join the organization and then to encourage them to transfer the packages to the organization (or at least link them from a wiki or in some other way) may be the key to the fitness of the org. Chris may have more to say about it. He has much more experience with an org (a successful org I might say). @ChrisRackauckas

I see it similarly. PDEs is a very heterogeneous field and while I am attempting to work towards something that combines solvers together, it will take quite a long time and in the end the specialized codes would probably do really well and should be integrated anyways. So an org is a nice way to organize various projects together. It also can pull together a set of bylaws and maintenance: I usually spend part of my morning going through tagging, re-running tests, and checking open PRs to see what needs to be done to move forward (maybe pinging the right people or leaving a message as to why it’s stalled). This kind of maintenance work from a core group is really what brings an org together and can make it “trustworthy”, and with that there’s also a sense of community that grows so people tend to work more together which then makes things sooner or later look more uniform.

The issue with FEM is that it’s such a time investment. I plan to just use whatever comes out, but FEM packages are a full team and org itself. Plus, I don’t tend to ever need it for my own work. I think a lot of people are the same. But there’s so many other things to do though that I don’t plan on stepping into FEM grounds anymore since there are so many specialists looking to do just that. Meanwhile I’ll do the easy stuff like FDM :wink:.

1 Like

I’m also very interested in this. In my spare time, I’m developing some prototypes of semidiscretisations for hyperbolic PDEs at https://github.com/ranocha/HyperbolicDiffEq.jl, including finite volume and discontinuous Galerkin methods. It is in its early stage but may become part of the JuliaPDE toolbox. I’m also interested in classical summation-by-parts operators from finite differences and want to implement them in a package.

4 Likes

May you add the link to the org?

https://github.com/JuliaPDE

I think JuAFEM hasn’t been mentioned yet?