# PDEs Update

Tags since the last blog post:

This new setup shows how one can add PDE libraries to the setup. The PDE problems are defined in DiffEqPDEBase.jl. There’s current a problem type for specifying a Poisson equation, and one for a Heat equation. More types of PDEs should be added, so please feel free to open a PR with new equation types (even before we have solvers for them). Additionally, notice that the mesh is held in the problem definition. This means that the Problem type is a full computational specification of the problem to be solved, which allows for it to properly dispatch to the correct libraries and solvers. The mesh is parameteric, meaning that different meshes can be specified and dispatched on. For example, a FDMMesh could be made to hold finite difference meshes, and then one could specify a finite difference heat problem by a change of mesh. Solvers can then dispatch based on the type of the mesh. Conversions between meshes can be done automatically to expand the reach of solvers (within reason).
FiniteElementDiffEq.jl then got a bit of an internal revamp. It got rid of a lot of dynamic dispatching, allowed for the familiar solve(prob,alg;kwargs...) form, and was just generally modernized / made to work well on v0.5 and v0.6. However, the solvers are still “special-purpose”. In the future, I will be getting rid of the special purpose solvers, and instead write them as calls to the ODE solver libraries, which will increase the performance given how well optimized those libraries are.
Next on the docket is the integrator interface. You’ll see docs for this come live very shortly. Essentially, you can control ODEs step by step, and callbacks/ event handling got a major boost in applicability. This may be the new strongest part of the JuliaDiffEq. A separate post will handle this.