Add time-dependent isotropic goal-oriented demo #112
Conversation
There was a problem hiding this comment.
Thanks very much for the new demo, @acse-ej321 - this is great! A few fairly minor comments.
I see what you mean about the bug. I'll see if I can get Goalie to raise an exception when the user asks it to enrich shallow copies and (if successful) will raise a separate PR.
| # more densely distributed near to the right-hand boundary. This can be seen by | ||
| # comparing the second mesh against the first. | ||
| # | ||
| # .. rubric:: Exercise |
There was a problem hiding this comment.
Is there meant to be an exercise here?
|
|
||
| # At each timestep, recover metric of the solution | ||
| # vector. Then time integrate over the contributions | ||
| _metrics = [] |
There was a problem hiding this comment.
I wonder if metrics_i might be a clearer name for this list? (I know I've used a similar approach before.)
| # get local indicator | ||
| indi = indicators["u"][i][j] | ||
| # local instance of Riemanian metric | ||
| _metric = RiemannianMetric(P1_ten) |
| metric = _metrics[0] | ||
| # all the other metrics | ||
| metric.average(*_metrics[1:], weights=[dt] * len(_metrics)) |
There was a problem hiding this comment.
This is fine for now but I think we should implement a driver function for averaging on the Animate side to make this clearer. i.e., a function that effectively does this.
| fig.savefig(f"burgers-hessian_mesh{iteration + 1}.jpg") | ||
| plt.close() | ||
|
|
||
| # Since we have two subintervals, we should check if the target complexity has been |
There was a problem hiding this comment.
Maybe put 'multiple' rather than 'two', to keep things general.
| # | ||
| # Recall that the Burgers problem is quasi-1D, since the analytical solution varies in | ||
| # the :math:`x`-direction, but is constant in the :math:`y`-direction. As such, we can | ||
| # affort to have lower resolution in the :math:`y`-direction in adapted meshes. That |
| # | ||
| # Recall that the Burgers problem is quasi-1D, since the analytical solution varies in | ||
| # the :math:`x`-direction, but is constant in the :math:`y`-direction. As such, we can | ||
| # affort to have lower resolution in the :math:`y`-direction in adapted meshes. That |
There was a problem hiding this comment.
I find this a bit misleading. To me, having lower resolution in the y-direction would mean anisotropy. But these meshes are isotropic. Did I misunderstand something?
| @@ -0,0 +1,274 @@ | |||
| # Burgers equation with Hessian-based mesh adaptation | |||
jwallwork23
changed the title
@jwallwork23 - I found the cause of #107 : it was in how I was declaring my
meshespassed into theGoalOrientedMeshSeq. I was declaringmeshes = [UnitSquareMesh[n,n, diagonal="left"] * n_mesheswhich worked when theenrichment_methodwas set to 'p' but produced an error when accessing thetransfermethod between meshes when theenrichment_methodwas set to 'h'. Presumably the mesh is a shallow copy with the above expression.Even though this turned into a user error, I found this while compiling the MFC for burger's demo using goal-oriented isotropic adaptation which may partially address #28 instead?
Creating a pull request here to get feedback on the additional demo.