It appears there are organizations for a number of areas, but not for numerical methods in PDEs. FEM is probably too restrictive, for instance there are some excellent BEM codes on Github. I also know of a FVM code, and so on. Throw in finite difference methods, spectral methods, mesh-free and particle methods, and the list can go on.
Anyway, it seems that at this point there may be enough for an organization here…
Well I definitely wouldn’t say there are no organizations in this area. JuliaFEM is specifically for building an FEM toolbox in Julia:
And one of the big focuses of JuliaDiffEq going forward is PDEs, building a finite difference toolbox in DiffEqOperators.jl and piecing together different PDE solvers into coherent interfaces (and supplying the timestepping routines of course). It doesn’t have a focus on FEM because I don’t have the bandwidth, but there are projects related to FEM, specifically the wrapping of FEniCS in FEniCS.jl. (There is also an abandoned FEM toolbox in here, which someone could pick up if they wanted). And separately, ApproxFun.jl is all about (adaptive) spectral methods, and we have some projects integrating with ApproxFun.jl (pun intended).
I think there is a case to have a JuliaPDE org besides the Edit JuliaDiffEq DifferentialEquations (DE) and let the latter focus on more ODE-like things. DE is pretty big as it is already, so another division could be good, if only to serve as repo organisation. The split to PDEs would probably be the most natural.
And one of the big focuses of JuliaDiffEq going forward is PDEs, building a finite difference toolbox in DiffEqOperators.jl and piecing together different PDE solvers into coherent interfaces
By “coherent” do you mean that the long term goal is to have FDM, FVM, FEM and spectral methods all having the same interface? Or does coherent just mean that each method has it’s own interface? Also, how high level do you think that the interface can be? Could it be as easy as solving PDEs in Mathematica?
Those are two different things: one of those is an org and the other is a package. We’re building our PDE components in separate packages from DifferentialEquations, and splitting out the docs because it’s a separate package. Do you think it needs a separate org as well? We’ve found there to be enough crosstalk that keeping it together in one org made sense for privilege management (since solving any PDE with timestepping is invariably writing a timestepping algorithm and mixing it with some spatial discretization). We can split this out to a different org, but there would probably be a lot of mirrored teams in the long run, unless if JuliaPDE was specifically built around spatial discretization toolboxes.
But there are shared types that need to be directly known to all of the solvers because the main form to thing to handle here is just linearity and specializations of expmv!, which is where DiffEqOperator comes from. But then that handles more than just PDE operators because, well, it’s just generic linear operator handling since there’s nothing special about PDEs at that point other than the fact that only some linear operators are stable, which is then on the user to just choose the right one.
Could it be as easy? Of course, that’s just about putting the right API on it. We already can do most of what it can do. The automatic method of lines via finite difference approximations stuff is already in the DiffEqOperators.jl. We don’t have a DSL to automatically apply the operators and generate an ODEProblem, but it’s not difficult to do that last part yourself though. What we’re missing is more robust finite element discretization tools. What we gain is that our version of “method of lines” is much more encompassing, and you can pretty much define any PDE method with timestepping as an extended idea of “method of lines”.
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.
@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 GitHub - SciML/ParameterizedFunctions.jl: A simple domain-specific language (DSL) for defining differential equations for use in scientific machine learning (SciML) and other applications , but in order to be more flexible we will need a new one (Roadmap · Issue #1 · SciML/DiffEqDSL.jl · GitHub).
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 (Magnus and other linear operator solvers · Issue #90 · SciML/OrdinaryDiffEq.jl · GitHub and Dual linear solvers interface · Issue #115 · SciML/OrdinaryDiffEq.jl · GitHub).
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 - #13 by Tamas_Papp). 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.
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?
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.
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.