> [thank you]

You're welcome! Thank you for your questions! This has been a ton of fun on my part too.

> existing solutions employ FEM

FEM is pretty great for a lot of problems. Some fields are devoted to particularly tricky PDEs and go a long ways beyond that to generate asymptotically better solutions that don't generalize to other PDEs. Some easier problems have insights that improve on FEM.

> NN abstracts away the meshing rules and learns the correct resolution in the areas of interest

Something like that. That's certainly how I described it. The internals of a NN are a bit more wishy-washy, and for a variety of pathological problems (largely non-physical problems, e.g., ones devolving into rapidly tightening, infinite-curl spirals) none of the outputs will make intuitive sense when plotted against progressively finer-meshed classical solvers. For nice enough problems though (E&M with a smattering of QM, CFD, ...) that's approximately the net effect. Large portions of the weight space are devoted to interesting stuff, smaller portions to how it all fits together, and as you feed in information you'll naturally have more computation done with respect to the parts of the solution that need it.

> why not use a NN to generate meshes directly

If I'm understanding correctly, you're saying that this would contrasted with the current technique of generating outputs at various inputs. There's nothing wrong with that idea per se, but it's about as computationally intensive as generating approximate outputs at each of those mesh descriptors, so you might as well use that information. Combine that with the fact that a lot of these problems are extremely messy (how long does it take to transform gaussian noise or your favorite other initialization into a benzene molecule? (answer: weeks to months depending on your desired degree of accuracy, much worse for relativistic atoms)), and a classical solver will still struggle if all you do is give it a mesh and tell it to go wild.

> would give provable bounds on the solution

That point is a little interesting since it requires assumptions about the bounds of various partial derivatives in each region. In real-world problems, even when you can come up with such bounds, often you can't easily get those bounds to depend meaningfully on the mesh size (and certainly not on local properties in regions of widely spaced meshes). The net effect is that you can't prove much about the solution quality for an arbitrary PDE just based on mesh specifics (other than asymptotic information, which we can prove very easily).

> incorporated into mainstream engineering software

No clue, but I suspect not yet. Everything I've read about, used, written, or seen has been a one-off PINN.

> there are existing works on NN mesh generation, but ... proves error bounds

That's one of those things where I'd be strongly inclined to let the traditional software do its job. Much like using ChatGPT for recipe generation -- you might list some ingredients you do or don't want used, give the model a persona capable of cooking the thing you want to eat (to bias it away from the dregs of the internet), and ask for ideas and then maybe a followup or three. Once you have that result, you won't just blindly broil your shrimp at 550F for 180min; you'll independently verify the results (and still, hopefully, save time overall since you now at least know the right search terms and whatnot).

These NN results are similar. They're just approximations, and their best use IMO is feeding them straight into a tool that improves their accuracy and gives you known error bounds. The chief advantage is the speed with which you can obtain results, and the fact that the speed transfers when used as an initialization elsewhere is a very happy surprise.

> generate meshes directly

The status quo isn't bad for that for most classes of problems. For small, simple problems you'd never use a PINN. For large, complicated problems, classical techniques are so slow that the overhead of just sampling NN output to uncover the mesh isn't a huge problem. It's the in-between cases where you might want something smarter. I've seen a few papers and a few problems, but it doesn't look like there's a lot of interest. I'm not sure why, but collecting a few of those problems, trying to come up with real-world use cases where you'd need to solve tens of thousands or more of them (to make the PINN training worth it), and then using that as the backdrop for your project is probably the first direction I'd take if I had to work on that middle ground.

> any hints?

Let the NN do NN stuff. Expensively transform bulk data into a model that can much more cheaply approximate that data. PINNs use gradient information to replace most of that data (relying, then, on low sample counts of experimental or synthesized data). However you do it, the goal is to distill something expensive and messy into a model and then use the model to do something. Nobody has good error tracking via NNs, so don't use the NNs for that; use the NNs to feed data into a tool with good error tracking. Similarly with any other hard criterion.