Minor changes for ANK solver behavior #277
Conversation
… chord for the moment computations
…rgence. also fixed the mgpc setup for ank turb ksp
Codecov Report
@@ Coverage Diff @@
## main #277 +/- ##
==========================================
+ Coverage 40.77% 40.87% +0.10%
==========================================
Files 13 13
Lines 3882 3892 +10
==========================================
+ Hits 1583 1591 +8
- Misses 2299 2301 +2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| This option only really makes a difference very close to the final L2 convergence target. | ||
| For example, setting a value of 0.01 will force the linear solver to converge the linear system more tightly, in the cases where the absolute linear convergence is achieved before the relative target. | ||
| Reducing the value here to 1e-4 or 1e-6 may result in "extra" nonlinear convergence in the final iteration, at the cost of more linear solver effort. | ||
| Increasing the value here to 1e-1 will reduce this buffer and the solver is more likely to end closer to the final L2 convergence target, but a too large of a value might cause issues with the final iterations where several smaller additional Newton steps are required. |
There was a problem hiding this comment.
Maybe worth mentioning the "performance improvement" motivation here as well?
There was a problem hiding this comment.
No I don't want to mention it here. People should not use this unless they know what they are doing.
There was a problem hiding this comment.
Follow up comment: The reason I dont want to mention is that setting this variable too high has the potential of tripping the linear solver near the end so you never reach the L2 convergence. If the user does not understand what this option does exactly (which is fairly nuanced), then its likely they wont be able to fix this issue if it arises.
Effectively, this is only really useful for solver performance tests for papers etc.
There was a problem hiding this comment.
that makes sense, I was not thinking to encourage users to play with this, but rather explain this. Maybe a heads up explicitly saying "People should not use this unless they know what they are doing" could be useful? No strong opinions on my hand here, your call
|
"Cool, just a couple of clarifications. I use coupled ANK so I guess I will need to change the default PC update tolerance option after this?" This stuff was added relatively recently in #231, so I doubt this was affecting you. If you want you can change this option, but only do it if you understand what is going on and if your case is doing too many PC updates. This level of performance optimization is usually irrelevant for academic work, so I would not bother most likely. Getting a more robust solver is always better, so I recommend not changing the default. |
Perfect, thanks! |
Purpose
This PR contains the ANK-related changes from #246. The CL solver in that PR will need more work, but I want to clean up some of my work branches sooner than that.
The changes are:
ANK CFL Reset: I added a python option
"ANKCFLReset"that defaults toTrue. This was the original behavior of the solver, where at each subsequent ADflow call, the ANK CFL would be reset to"ANKCFL0"and then the moving lower bound was applied in the solver itself based on the L2 convergence. Now, the users can set"ANKCFLReset"toFalse, so that the last ANK CFL is preserved exactly as the solver goes into the next iteration. This improves performance near the final stages of optimizations, or with CL-solvers where the problem does not change all that much. However, restarting the new case at high CFL numbers can make the solver unstable, so I am keeping the original behavior as default. The ANK CFL for each case is saved in the aeroProblem's ADflow data.ANK Linear Solver Buffer: This was a hard-coded value in fortran, which is now exposed to Python. This determines how much we over-solve the linear system when we are near the L2 convergence target. Not really relevant for most people, only really comes in handy when you are trying to do performance tests and you would prefer the linear solver to quit as soon as you think you are near the L2 target. This is a linear approximation, so achieving the L2 target is not guaranteed. That's why we multiply the L2 target by the linear solver buffer
"ANKLinearSolveBuffer", which defaults to 1e-2. Increasing this value to something like 0.5 would be a bit more accurate at the risk of running a few extra iterations due to the linear approximation not being an exact calculation of the nonlinear residual.Added a new PC update tolerance: The
"ANKPCUpdateTolAfterCutoff"option can be used to control the PC update based on L2 convergence after the"ANKPCUpdateCutoff"is reached. Again, mostly a performance related option that most people don't need to worry about.Added method to get number of cells: The
getNCellsmethod in pyADflow returns the total number of cells in the grid as computed in the fortran layer.Expected time until merged
Would be great if this is done within a week.
Type of change
Testing
Checklist
flake8andblackto make sure the Python code adheres to PEP-8 and is consistently formattedfprettifyor C/C++ code withclang-formatas applicable