Hi,
I’m looking into solving PDEs on a 2d domain using PINNs and would like to try the NeuralPDE package.
Is there a way to define a custom geometry besides linear intervals? I can’t find it in the documentation, the examples on the website all use a Unit Square geometry.
If now, what would be the approach to add user-defined geometries to the solver?
Right now it’s not supported. That’s near future.
1 Like
Don’t know what are the plans @ChrisRackauckas regarding the diffeq world, but it would certainly be great if there was some integration with Meshes.jl geometries, which are purely written in Julia and extensively tested with geostatistical applications in the industry.
That’s kind of the plan. Meshes though is not designed for performance in a numerical context, and no mesh format is universal in performance. So I think we need to have one mesh format which is a universal description for a PDE system, and then ways to convert that to forms specific to solvers. It’s not an easy task which is why it’s taking awhile, there’s just lots to do in SciML, but it’s the next big domain (pun intended).
Meshes.jl has a very solid design and algorithms in place, which is the hardest part to get right. Performance improvements will come along the way with more usage and demand from applications. We are continuously refactoring the internals. Feedback from PDE users is always welcome.
The project roadmap is very exciting.
I think you’re missing the point that PDE solving can have different demands on the mesh format than what’s required for visualization. We should at least have a way to convert between them, since I’d want to reuse any of the visualization pieces being built in Makie, but if the PDE solver needs struct of array instead of array of structs or whatever, the PDE solver will change the format to be what’s required and not take a 10x hit just to follow a standard not made for PDEs. So what the exact format will be for ModelingToolkit will almost certainly be something customized for the space, though interoping with Meshes.jl will still be important. This is exactly why it’s not a trivial problem.
I fully understand the requirements and wrote Meshes.jl with FEM applications in mind. It is not designed for visualization and that is stated in the first paragraph of the docs:
https://juliageometry.github.io/Meshes.jl/stable
I think it is important to distinguish end-user experience from internal optimizations. If PDEs require a struct of arrays instead of an array of structs, that is a simple pre-processing step that can be performed within a specific algorithm hidden from end-users. The main challenge here is to actually come up with a good design like we did, which avoids a lot of low-level interfaces that only advanced users (or core devs) can benefit.
Of course, there is a long way to meet the PDE requirements as you mentioned, but it is not something that is off our radar. The public API is stabilizing now, and we only have one additional major breaking change planned before we start optimizing for performance. I opened an issue to track this performance initiative, and it would be helpful if you could list some of the problems you see with the current internal representations adopted:
If you can pin point some core design decision that inhibits the use of Meshes.jl in PDEs, we are happy to assess changes to the internals to increase interoperability between the geostatistical work that we are doing and the PDE work that you are leading. I know that @moyner already did some integration of Meshes.jl with his Jutul.jl PDE project. We aim to create a full pipeline where people can model static geospatial properties with GeoStats.jl and then feed these properties into PDE simulation. This is very typical in reservoir engineering for example, where geologists create models of the rock (porosity, permeability) and engineers perform fluid flow simulation to forecast production.