Convergence of parameters of heat equation #199
-
I'm currently trying to solve the problem u_t- a* u_xx -b * u_x -c * u =0 when x \in [0,1] and t \in [0,1]. The boundary condition is u(t, 0)=u(t,1 )=0 and the initial condition is u(x,0)=sin(pi x). In my code, I'm trying to recover a, b and c (variables) when the a, b and c that I originally wanted is non 0. I have tried to solve this problem using the PINN model from the necromancer package. To code up this problem, I used the code in https://colab.research.google.com/github/pnnl/neuromancer/blob/master/examples/PDEs/Part_3_PINN_BurgersEquation_inverse.ipynb as a reference, and changed the generation of data. The rest of the code should be similar. My question is: why am i unable to recover the parameters a, b and c? Here is my code:
|
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
Hi @AliaNajwaMY! Thank you for using Neuromancer! I've reviewed your issue, and I was able to reproduce what you mentioned regarding the parameters a, b and c not matching the expected values. I wanted to point out a few things so that we can help you solve this problem:
Please let me know if any of these points need clarification. I'd be happy to follow up on these. Best wishes, |
Beta Was this translation helpful? Give feedback.
-
Hello Bruno,
Thanks for replying! I just realised that the right PDE is actually the one in my code file: meaning that I wanted to solve u_t - a* u_xx -b * u_x -c * u =0, sorry for that! In that case, I was thinking that your last suggestion would apply the most since the the function that I would use for data generation would actually satisfy the PDE. What scaling do you suggest I use instead? I tried a variation of scaling, but when I increased the scaling of ell_2 instead of ell_1, it just made finding the solution of PDE be inaccurate but not actually helping in recovering the parameters.
On Tuesday, 22 October 2024 at 07:57:37 pm GMT-4, Bruno Jacob ***@***.***> wrote:
Hi @AliaNajwaMY! Thank you for using Neuromancer!
I've reviewed your issue, and I was able to reproduce what you mentioned regarding the parameters a, b and c not matching the expected values. I wanted to point out a few things so that we can help you solve this problem:
-
You mention in your question that you are trying to solve this advection-diffusion-reaction equation: u_tt - a* u_xx -b * u_x -c * u =0. However, when constructing the loss function for the PDE, I noticed you used dy_dt - a_var * d2y_d2x - b_var * dy_dx -c_var * y_hat. There is a mismatch in the u_tt and dy_dt that can be causing the issue.
-
I noticed you are using an analytical solution to generate u, as u(t,x) = sin(pi*x) * exp((-a*(pi^2) + c)*t). I do believe, however, that this is not a solution of the PDE that you are trying to solve, even with b = 0; it seems that a source term is missing out of your PDE, that should probably take the form d2y_dt2 - a_var * d2y_d2x - b_var * dy_dx -c_var - f, where f is the source term that you get from plugging your manufactured solution into the PDE. I did test this on wolfram alpha and by hand, just to make sure, and I do believe this is the case. Please double check to make sure that's the case.
-
Notice that the issues mentioned in 1) and 2) are not necessarily affecting the solution found by the PINN, as you are using a scaling of 400x in the data loss ell_2 when compared with the PDE loss ell_1. Note that this is not necessarily wrong (we did that in the tutorial you mentioned, and that's a good practice when using data loss as means of imposing initial/boundary conditions), but since the network is learning u(t,x) mostly in a supervised manner, (the data loss doesn't have a clear signal from a, b and c, as it doesn't know the PDE), it might be hard for the model to actually learn a, b and c when u is not a solution of the PDE.
Please let me know if any of these points need clarification. I'd be happy to follow up on these.
Best wishes,
Bruno
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi @AliaNajwaMY! I think the function that you are using (unless you changed it) does not satisfy the PDE. Here's what I got from wolfram alpha: In other words, the function you are using to generate the training data does not satisfy the PDE, unless you add that difference (the
where So you can either i) add the source term f to the PDE, by changing your Regarding the recovering of parameters, you'll need to first fix the PDE / u / f incompatibility that I described above in order to actually recover a, b and c accurately. In this case, it's likely that you'd be able to recover a, b and c with the scaling as is. I hope that helps! Please don't hesitate to ask for clarification :) Best, |
Beta Was this translation helpful? Give feedback.
-
Hello Bruno,
Thank you so much for getting back to me!
That's odd that they didn't equate to 0 because if I rewrite the results of the wolfram alpha you included, I can cancel the terms out to be 0. Am I missing something here?
On Thursday, 24 October 2024 at 03:02:05 pm GMT-4, Bruno Jacob ***@***.***> wrote:
Hi @AliaNajwaMY!
I think the function that you are using (unless you changed it) does not satisfy the PDE. Here's what I got from wolfram alpha:
Screenshot.2024-10-24.at.11.44.28.AM.png (view on web)
In other words, the function you are using to generate the training data does not satisfy the PDE, unless you add that difference (the -b*exp(c-a*pi^2)... term shown in the last equality of the wolfram alpha result, i.e., unless you modify your PDE to the following:
du/dt - a* d2u/dx2 - b * du/dx -c * u - f
where f is the -b*exp(c-a*pi^2)... term. That way, minimizing the loss ell_f actually makes sense, as ell_f = fpinn = du/dt - a* d2u/dx2 - b * du/dx -c * u - f -> 0. What you are currently doing, on the other hand, is: ell_f = fpinn = du/dt - a* d2u/dx2 - b * du/dx -c * u, which won't work, as du/dt - a* d2u/dx2 - b * du/dx -c * u will, at best, approach f here.
So you can either i) add the source term f to the PDE, by changing your fpinn to have that f term; or ii) change the way you are generating your exact solution u. I don't think this PDE has an analytical solution such that f = 0, so I think you can either go with option i) or you can propose a new u(x,t) and recover a new f from plugging u back into the pde.
Regarding the recovering of parameters, you'll need to first fix the PDE / u / f incompatibility that I described above in order to actually recover a, b and c accurately. In this case, it's likely that you'd be able to recover a, b and c with the scaling as is.
I hope that helps! Please don't hesitate to ask for clarification :)
Best,
Bruno
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi @AliaNajwaMY, I'm sorry you are a absolutely right, it does reduce to zero, so the u you proposed is indeed the solution of the PDE! In this case, chances are that the optimization is getting stuck in a local minima; so the a, b and c somewhat get close to what the solution would be, but not the global one. This is an ongoing research problem in PINNs (e.g., see https://arxiv.org/pdf/2203.13648, https://www.sciencedirect.com/science/article/pii/S2590123024001841), and things like adaptive weights for the different loss terms, as well as adaptive collocation point creation, may help. You'll notice as well that the characteristic length of the domain L, the number of layers, the number of collocation points, the scaling of each loss term, the dimensionless Peclet number (here would be bL/a), and Damköhler Number (cL^2/a) should all affect the presence of these local minima; that's because all these parameters affect the loss landscape, directly or indirectly. Sometimes the minima is somewhat sticky (e.g., in case the PDE has a fixed point that attracts and traps the optimization process); that's the case for equations like Allen-Cahn (see Fig. 3 of https://arxiv.org/pdf/2203.13648), and sometimes this can be resolved by running your optimization for a long number of epochs. For example, if possible, try using a = 0.1. Because the diffusion will take place in a much slower pace, the signal to c will be a bit better (you'll likely get a c closer to 4.). I'll keep exploring to see if we currently have anything in Neuromancer that can help in your specific problem, but unfortunately that's a difficult one! Please let me know if that helps! Best wishes, |
Beta Was this translation helpful? Give feedback.
-
Hello Bruno, Oh thank you for letting me know about this! I wonder if you or anyone in the necromancer team has a specific example of this problem occurring? The fix doesn't have to be using the necromancer package but I would love to see a concrete example of the fix if you have it! Best, |
Beta Was this translation helpful? Give feedback.
Hi @AliaNajwaMY! Thank you for using Neuromancer!
I've reviewed your issue, and I was able to reproduce what you mentioned regarding the parameters a, b and c not matching the expected values. I wanted to point out a few things so that we can help you solve this problem:
You mention in your question that you are trying to solve this advection-diffusion-reaction equation:
u_tt - a* u_xx -b * u_x -c * u =0
. However, when constructing the loss function for the PDE, I noticed you useddy_dt - a_var * d2y_d2x - b_var * dy_dx -c_var * y_hat
. There is a mismatch in the u_tt and dy_dt that can be causing the issue.I noticed you are using an analytical solution to generate u, as
u(t,x) = sin(…