DO NOT MERGE YET - Update CMAQ submodule to CMAQv5.3.3.2_7May2022#40
DO NOT MERGE YET - Update CMAQ submodule to CMAQv5.3.3.2_7May2022#40climbfuji wants to merge 5 commits intoNOAA-EMC:developfrom
Conversation
|
Some things to think about as this PR progresses: @rmontuoro @bbakernoaa This would be a very good transition point once we branch off for the operational implementation. After this PR, I would strongly encourage a process working with USEPA on bringing our code improvements into their repository and ditching all our local changes if they apply to anything with the newer tag and attempting to keep on track with the EPA's repo. @climbfuji, we have local changes to CMAQ files in src/model/src . You would need to spend some time comparing those files to the ones that do or do not exist in the new tag and adjusting accordingly. |
Argh, I don't think I should be doing this. All I need are specific commits from CMAQ so that the code works on pseudo case-sensitive filesystems like on macOS so that the UFS works with JEDI in our environments (we run locally on macOS for testing/development). But I don't understand, the git submodule info points to which is in the authoritative repo. Where are your local changes to the CMAQ files coming in? |
OK. I thought you wanted to bring in all the changes from 5.3.3.2. We have been moving local changes to src/model/src because of the loads of work to move to the newest CMAQ and not having that time right yet. |
|
@BrianCurtis-NOAA I am coming back to this one, finally. All we need in your CMAQ version (unless you haven't updated to tag 5.3.3.2) are the changes from this PR: USEPA/CMAQ#171 |
|
honestly I don't see a point to upgrading unless its to CMAQv5.4+ |
|
So how are we going to get the changes from this PR USEPA/CMAQ#171 into the ufs-weather-model? I have no preference, as long as these changes are available to us. |
|
As part of the DSRA an upgrade to CMAQ 5.4 is planned |
Ok, do you have an estimate for when this is going to happen? |
|
@bbakernoaa The cherry pick isn't too complicated to put into develop for the time being but I don't know if the updates will break anything. we only build (cmake) with the junit.F, so we would need to know how important the CSQY_DATA.F file is as it's removed with that. So if you get a spare few minutes, can you take a look at that cherry pick and see if you think it would break anything? |
|
@BrianCurtis-NOAA @bbakernoaa Any progress on this? Thank you! |
|
@climbfuji I tried your branch this morning and it doesn't compile. |
Fix bug resulting from merge
|
I remember that I had to resolve a conflict w.r.t. to this filename when I pulled in the ufs-weather-model updates last week. I removed the offending file from |
|
I am closing this. We have PR JCSDA/ufs-bundle#43 which points the JEDI ufs-bundle to ufs-weather-model develop, and it has instructions for creating a case-sensitive volume on macOS for working around the issues that this PR would have addressed. I also believe that others have brought up the issue for the ufs-weather-model, because it's not only AQM but also another submodule that is causing the same problems on the default case-preserving but case-insensitive macOS filesystems. |
Description
Update CMAQ submodule to tag CMAQv5.3.3.2_7May2022 - needed for building the UFS with aerosols on macOS systems with case-preserving (but otherwise case-insensitive) file systems.