Open YichengDWu opened 1 year ago
@xtalax can you describe where your parser rewrite is at? I think it would be fine to even do an earlier v6 with some features lost if it gets closer to these goals. One thing I think needs a total rewrite anyways is the integro differential equation support.
I have changed everything in the callstack up to parse equation to use symbolics and have started on parse_equation, I can pivot to this style though
Sophon can generate the symbolic loss functions I want, but it also falls short of what I'm talking about here. Its underlying implementation is just as hard to read as NeuralPDE, especially after the introduction of DeepONet. I removed support for integration and default parameters there, which should be kept in NeuralPDE.
What I would expect is to use advanced tools to transform expressions, such as MacroTools.postwalk
, which seems like something you're already using.
I'm happy with the design of Sophon's interface:
prob = Sophon.discretize(pde_system, pinn, sampler, strategy)
By the way, I don't actually use RuntimeGeneratedFunctions explicitly at all, and everything seems to work fine.
If anyone wants to rewrite NeuralPDE, I want to share some of my expectations here, some of which have been reflected in Sophon.jl.
The following code is mostly pseudocode, used only to illustrate the concept. I will gradually add what I can think of.
On PhysicsInformedNN
A PINN should be created and accessed in the form of named tuples, just like Lux.Chain.
Then wrap it in a PINN structure. It can be accessed through getindex, but getproperty is preferred.
Now we no longer need to record the order of dependent variables in the PDESystem. Parsing thus becomes simpler.
The code generating
begin ... end
should be wrapped in a reusable function, and so isu(t,x)->phi_u(coord_u, θ)
. Perhaps @rule can play a role here, I'm not sure. We need to break downtransform_expressions
into small functions or rewrite rulesSingle output & multioutput
I think we can just change
to
there is no need to make a difference in parsing other than that.
On coordinate
The current parsing is like this
Here unnecessary memory allocation caused by vcat has occurred. I hope there is a get_coord function that performs the least amount of vcat.
Similarly, we prefer to use named suffixes.
Periodic boundary conditions
Periodic boundary conditions are not currently handled correctly, see #469. Because the same dependent variable has different inputs. It needs to be treated specially.
A more general approach is to parse expressions like u(1.0,t) into
In this way, periodic conditions are naturally parsed correctly.
Even if something like this appears in the equation:
It can also be correctly parsed.
On derivative
I imagine having the following parsing function:
Sample
There should be an independent sample function, which can be used for resampling, and then passed into prob
Here
length(pde_datasets)==length(eqs)
,length(boundary_datasets)= length(bcs)
. Note that I believe the same data points should be used for all equations, which may help convergence. In any case, it saves memory.Scalaring
Before
scalarize
, each equation or boundary condition returns the residuals at each data point, not a scalar. We scalarize only at the very end.Note that weights are a tuple of functions, each assigning a weight to each data point in each equation, the most basic case is
Returns(1)
.Many adaptive algorithms need point-wise residuals, and we can hack weights to achieve changing weights without needing to make additional code changes.