-
Notifications
You must be signed in to change notification settings - Fork 830
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
Discrete Adjoint Memory Usage #594
Comments
We have also encountered the significant memory requirements of the discrete adjoint. Actually, this requirement prevented the use of fine mesh (of 10-20M cells) in optimizations process. This is not the case while using continuous adjoint but the effectiveness of the discrete adjoint is higher by far. |
Hi Jayant, |
Another potential issue is unnecessary recording of computations. Jayant and I noticed that on his fix_wall_distance branch, the MG 2 case mentioned above was using 8GB more than on develop because during the tree search, the distance computations to all possible bounding boxes were being recorded, when the only necessary computation for recording is the final computation (once the minimum distance node is determined). So I wonder if there are other places in the code where we can turn off recording to reduce memory usage. I'm curious what @talbring's thoughts are. Best, |
In terms of improvements on a larger scale, this work by Tom Taylor et al. describes a hybrid approach that could take down that memory requirement quite a bit more: |
@ALL, I agree that it might be a problem for bigger cases and that we have to think of some ways to reduce the memory requirements for the discrete adjoint. One approach that I started already, is to template the linear solver in order to use double datatype also when running the differentiated version of the code. However, that was more involved than I thought, but still its on my agenda. The nice thing is that this also reduces the runtime a lot. The next thing is, like @pcarruscag correctly pointed out, the use of preaccumulation. However, this also requires a more detailed analysis, since it can also lead to an increased memory footprint if not applied carefully. Currently, a lot of memory is used for the geometrical derivatives, i.e. the derivatives with respect to the mesh coordinates (this requires approx 1.5 times the memory needed for derivatives with respect to the conservative variables). But since these derivatives are only needed when writing the solution we could think of doing some recomputation as runtime is not that important. So you see we have some ideas and I am sure we can reduce the memory by approx 50% if we apply all of them. However, time is unfortunately limited at the moment, but I will definitely continue improving the adjoint solver. Tim |
I'm pinning this issue, to my knowledge this is not being worked on directly but it should be something we keep in mind as we refactor code. |
#1022 helps with this. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions. |
Hey everyone,
We (@bmunguia and I) ran the discrete adjoint on the ONERAM6 wing mesh with ~500, 000 elements and noticed the following memory usage:
Is this increase in memory consumption expected?
I ran the computation on the develop branch. The mesh is in TestCases/cont_adj_rans/oneram6/
Cheers,
Jayant
The text was updated successfully, but these errors were encountered: