Dear all,
I am quite new to Julia so I maybe missed the proper documentation.
May anyone suggest advanced Julia tutorials for Physics-Informed NN (a GitHub repository or something else) ? For instance, problems with complex geometry (i.e. no-rectangular domain) etc ? I have already explored the examples in the NeuralPDE doc.
Thanks in advance 
Hi Leo,
take a look at the SciML book, especially in lecture 3, there’s a great explanation about PINNs there.
The tutorials in NeuralPDE.jl: Automatic Physics-Informed Neural Networks (PINNs) · NeuralPDE.jl cover what is currently supported. The library does not do complex geometries at this time, but it’s something that’s being worked towards.
Thanks @RosalRicardo, I’ll have a look!
@ChrisRackauckas super cool thanks! Keep on the good work, NeuralPDE is so nice!
@ChrisRackauckas if you’re in need of support for moving to comolex geometries I’m open to help contribute. Ive been working on non linear solid mechanics pinns the last year or so where our goal is always complex geoemtry.
Ive been wanting to move some stuff over to julia from python but i have the feeling the ecosystem is not quite mature enough for my needs unfortunately, but would love to help push it there.
Indeed we’d be very happy to have someone help out here. We’d need to pick a mesh representation to use in the ModelingToolkit format. It would probably be good for that to be compatible with Gridap.jl as well, so that in the future the same symbolic code works for NeuralPDE.jl and Gridap.jl. We’d need some way to describe the weak form as well.
Which Python PINN package does arbitrary geometries? I know DeepXDE is a bit limited as well on the geometry choices.
There is also IDRLnet (GitHub - idrl-lab/idrlnet: IDRLnet, a Python toolbox for modeling and solving problems through Physics-Informed Neural Network (PINN) systematically.), that is mainly based on NVIDIA’s Modulus (Modulus | NVIDIA Developer). Both made their codes available.
Good point is that Modulus enables to import .stl files for a complicated geometry!
@ChrisRackauckas great points about compatability with other packages in the ecosystem.
For arbitrary mesh geometries for my work, i made a home baked jax pinn solver using the weak form that was built on top of exodusII python interfaces for reading a mesh as well as postprocessing. I moved some of those tools over to Julia in Exodus.jl to directly call the C library. That format scales to obscene amounts of cores so there should never be any limitations there. It’s old, but held to very high standards and just works.
Oh interesting, that’s good to know. Yeah, getting something together usually isn’t too hard, it’s fitting it to the symbolics that may be difficult, but that’s the step that’s essential for getting it to non-mathematical folks!
Great points on the symbolics.
I think fundamentally that may have to be handled differently depending upon strong form vs. weak form. For the strong form I think it’s maybe a little bit easier as long as you have a sufficiently sampled set of collocation points for your irregular geometry (that’s probably the challenging part).
For the weak form I think at the end of the day we would need some interface from symbolics down to say an “element level residual (or energy etc.)” that will map a given operator or set of operators to how that element should be calculated and then a general assembly interface or AD tricks could be used. For general operators that’s easier said then done though. Perhaps a kernel system like that in INL’s MOOSE library might be something to consider so that we have building blocks of PDE operators.
It would be very nice to have support for complex geometries. In my project, regular FEM is used to perform some calculations for a 3d aircraft model. Getting the complex geometry of the aircraft into NeuralPDE.jl is probably the main obstacle for using NeuralPDE.jl for some required optimizations and other tasks as well, e.g., having a function for the impact of the pressure of the hydrogen filled tanks, impact of the aerodynamic forces and so on. For now, for each modification, a FEM calculation must be performed.
So I am looking forward to the feature of integrating complex geometries. By the way, the open-source community which performs FEM calculations, often makes heavy use of GMSH as their meshing tool. Ideally, one could use gmsh for meshing and insert it directly to NeuralPDE. Gridap and Fenics allow reading the gmsh mesh.
Hi, can idrlnet also be used for complex 3d geometries with defined subdomains? They state:
complex domain geometries without mesh generation. Provided geometries include interval, triangle, rectangle, polygon, circle, sphere… Other geometries can be constructed using three boolean operations: union, difference, and intersection" idrlnet
However, their documentation only shows a Polygon function in 2D. In order to generate complex geometries in 3D, I assume to require the same Polygon function in 3D. Spheres, boxes and similar shapes, might not suffice. Reading loading any 3d .stl file might be an alternative, but I would also require some tags for physical domains, like gmsh and gridap provide. So, the concrete question is: can idrlnet be used in order to generate complex 3d geometries with specified physical subdomains?
I’m not sure it can.
As at best a casual FEM user I have migrated to Salome-Meca for my FEA needs as it is all open source. It uses Salome as its solid modeling and meshing tool and Code Aster for its FEM engine. It is highly developed and should not be overlooked.
We are actively talking about implementing this both in the symbolic frontend, and in NeuralPDE; We have a GSoC interested in pursuing this in NeuralPDE. See the issue here, really welcoming any comments.