-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More volume projection fixes #51
Conversation
I am tagging @sseraj and @marcomangano because they helped me review a similar PR previously. |
These ADflow tests failed with this change:
It looked like they were all small tolerance issues, I will look into these now. |
Codecov Report
@@ Coverage Diff @@
## main #51 +/- ##
=======================================
Coverage 52.53% 52.53%
=======================================
Files 5 5
Lines 1616 1616
=======================================
Hits 849 849
Misses 767 767 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Here's the test output on these tests:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes are good with me. Once the ADflow tests are retrained, we can merge this and the PR on ADflow at the same time.
This also looks good to me, but we need one of the maintainers to approve for this to be merged anyway |
Purpose
The volume projection routine changes the inverse evaluation into an optimization problem and utilizes the second derivative information to find the u,v,w parameters that correspond to given x,y,z coordinates. However, this second order Newton iteration does not always work; it looks like the final Jacobian ends up producing update vectors that make no sense. I think this might be caused by the second order derivative information.
So in this PR, I removed the contributions of the second order derivatives from the Newton solver, at least temporarily. With this change, the solver works much more robustly for me and @sseraj.
There can be 2 ways I think the second order derivatives are messing up the update:
Ideally, if the reason is the first one listed above, we either need to improve additional checks in the optimization algorithm, or convert the entire thing back to a regular Newton solver. Currently, it looks like it's solving an optimization problem but only using part of the derivative information. Effectively, this is the Newton's method with a weird nonlinear preconditioning step. It does work, but it is not as easy to understand as applying the Newton's method directly.
Expected time until merged
The fix is fairly quick. I created an issue to track this. I will keep looking into the problem, until then, merging this is fine for me.
I will dig a bit deeper into this and try to figure out the issue, and then we can test these terms again.
Type of change
Testing
Checklist
flake8
andblack
to make sure the Python code adheres to PEP-8 and is consistently formattedfprettify
or C/C++ code withclang-format
as applicable