[PULL REQUEST] Adjoint run skeleton#71
Conversation
|
Cool, thanks Colin! I'll add this to the 13.1 milestone. Sorry the GCHP restructuring was a burden on your end. Now that the restructuring is complete, things should be a lot more stable moving forward. I see there are a couple conflicts. Are those trivial things we can fix at merge time? (I've also seen GitHub identify conflicts that don't actually exist). |
|
The only conflicting "files" I see are the submodules ESMA_cmake, geos-chem, and HEMCO. I have learned while trying to get this pull request ready that there is no real way to merge submodules and so I don't know how to make sure that the repos stay in sync with the pull. In any case, I think you can ignore those and point the merged branch at the correct submodule commits once they've been merged into their respective repos. Let me know if that doesn't make sense and I'll try to clarify. |
|
Oh, I see. Yeah that's easy to do with the merge. Thanks! |
msulprizio
added
category: Feature Request
| if (.not. firstRun) THEN | ||
| call fv_computeMassFluxes(UCr8, VCr8, PLEr8, & | ||
| MFXr8, MFYr8, CXr8, CYr8, dt) | ||
| endif | ||
| firstRun = .false. |
There was a problem hiding this comment.
This change here is causing differences in the GCHP benchmark run. Could you explain why you put this here? Is it only for adjoint?
There was a problem hiding this comment.
This has to do with the reversal of the high-level operators; I have put it in an #ifdef ADJOINT block.
|
Also, don't worry about the conflicts. I am going to bring the file changes for this PR in manually to avoid the submodule updates. |
Okay, thank you! Is there a "correct" or at least better way to deal with submodule updates? |
|
Thanks for the quick turn-around! We are still figuring this out, but for now think the best way is to have super-project PRs include file changes but no changes to submodules. Then in the PR conversation list out the submodules that need to be updated with links to the individual PRs for them. Does that make sense? |
|
I have pushed the file updates manually to dev along with submodule updates for HEMCO, GEOS-Chem, and FVdycoreCubed_GridComp. I could not find a PR for ESMA_cmake. Did you have updates you need to make there? I am also holding off on the MAPL submodule update. We can move discussion of that to the MAPL PR. |
So sort of like what I did but backwards?
Wonderful! Thank you!
Sorry, I've created that PR now. geoschem/ESMA_cmake#4
Yes, thank you. I responded on there and will get back to you soon. |
|
Hi @TerribleNews, all of the updates except for MAPL are now merged in for 13.1. Would you like to keep this PR open to continue discussion of the MAPL updates that will eventually go in, or can we close and move that discussion to MAPL github? |
That's a good question. My plan was to send duplicate pull requests here and to GMAO, since there is likely to be a pretty long lag time for the GMAO changes to make it here. I am still trying to sort out what is in that pull request as I have had some difficulty getting things to build with the |
|
We can put updates in without going through GMAO for the short-term, to be superceded by what GMAO brings in. They will want to implement them their own way and in such a way that does not impact GEOS. The PR you do with them will give them a starting point - they may want to iterate with you or just see the update and do it themselves. So to answer your question, there should be two PRs but they may not be identical. GMAO is on MAPL 2.7.1 while we are still on 2.6.3. |
|
I will close this PR. The remaining work to be done is for MAPL which has open PR geoschem/MAPL#4. |
5 participants
I am submitting this pull request mostly to get the discussion started. The code should not change the standard GCHP at all, but allows for the flags -DADJOINT and -DREVERSE_OPERATORS to be defined at cmake time which enable runtime flags for reversing the timestep and computing adjoint variables (i.e., a single adjoint-enabled binary is compiled which can be run in forward and reverse mode for adjoint operations). The adjoint calculation code is still a work-in-progress, but a trying to keep up with the changing structure of the git repositories has become very difficult so I'd like to get the working reverse run code into the geoschem/GCHP repo ASAP. I will also submit pull requests for the submodules MAPL, HEMCO, geos-chem and FVdycoreCubed_GridComp to go along with this pull request since this code only compiles with the changes I made to those submodules.