Using PreallocationTools.jl #173
Conversation
…cache This fixes automatic differentiation, thus allowing implicit methods to be used. Also, this allows for setting the u-type for the caches, thus allowing for automatic differentiation of the solve itself for gradient-based optimization. Demonstrations of use cases will follow, but for now I have added a test showing that implicit methods work and the u-type stuff has been demonstrated locally.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #173 +/- ##
==========================================
+ Coverage 74.42% 74.44% +0.02%
==========================================
Files 9 9
Lines 1122 1127 +5
==========================================
+ Hits 835 839 +4
- Misses 287 288 +1
☔ View full report in Codecov by Sentry. |
|
Awesome, yeah there was just a few dangling things there 😅. Examples of calibration to come when I get in-flight wifi up. |
|
This looks good to me. |
| (_, :DualForm0, 1) => :E | ||
| (_, :DualForm1, 1) => :V | ||
| _ => return :AllocVecCall_Error | ||
| resolved_form = @match (c.form, c.dimension) begin |
There was a problem hiding this comment.
PR #151 also makes this refactoring and pulls it into a function to be called elsewhere, but I will leave this be and fix the merge conflict when it is time to merge 151.
There was a problem hiding this comment.
Changes look good to me. Just reran the CISM benchmark on this branch on HPG, and times are sitting at just over 11 [ms] using the Tsit5 solver. Loading up CairoMakie now to visually inspect results as final sanity check, though RMS and max difference appear normal. Will approve pending the render.
|
I should note that I was unable to get the parallel solver |
|
Looks like artifiacting builds up in strange ways using the FBDF solver. Tsit5 results are included for comparison. This is very likely not a "bug" in the solver implementation nor in Decapodes per se. But just thought that it should be noted. Let me know your thoughts @jpfairbanks and I will go ahead and merge. FBDF
Tsit5
|
|
That goes away at lower tolerances? |
|
Presumably yeah. That's been my experience using the explicit timestepping solvers with Decapdoes. I'll run some more tests with FBDF this afternoon and open an issue if changing up the parameters doesn't resolve this. The GIFs here are using just the default parameters. |
|
The artifacts shouldn't hold up the merge. We can diagnose the numerics in a separate issue. |
|
Yes this is somewhat expected. For explicit RK methods, the stability bound is stronger than the convergence bound, and therefore the default behavior that you'll get on this PDE has very low error because most of its step failures are due to stability criteria. Meanwhile for the implicit methods, it's only going to be bound by error, and therefore it's going to be hitting a much higher error by default because it's only aiming for the reltol=1e-3 default, which is effectively 1-2 digits of accuracy. That's just a default of "the plot should look good enough" but if you want to remove say the pseudowaves from there that's just a phenomena of numerical advection that can be dampened by using lower tolerances. |
That one probably won't be a good idea for this problem. |
@ChrisRackauckas, I added some fixes for #171