Remove pio initialization routines from shr_pio_mod #34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Needs to be coordinated with cmeps and cpl7 branches where I am introducing new init_pio_mod modules.
billsacks
commented
Jul 5, 2022
src/shr_pio_mod.F90
Outdated
Comment on lines
45
to
47
| ! The following variables are public just for the sake of the driver's init_pio_mod. | ||
| ! No other subroutines should access these directly! Any other access should go | ||
| ! through the above accessor routines. |
There was a problem hiding this comment.
Making these variables private to shr_pio_mod would have required adding a number of additional getter and setter routines. This seems doable but tedious and would add complexity.
jedwards4b
reviewed
Jul 5, 2022
This was referenced Jul 5, 2022
jedwards4b
approved these changes
Jul 5, 2022
|
I have run CESM prealpha testing on these changes. All tests pass other than those that failed in the baseline as well. @jedwards4b let me know if you'd like me to do any other testing – and if you'd like me to do the srt testing by hand, please help me with exactly how to do that. |
billsacks
added a commit
to ESCOMP/CMEPS
that referenced
this pull request
Jul 8, 2022
Extract non-initialization parts of shr_pio_mod to a module in share ### Description of changes Extract the non-initialization parts of shr_pio_mod to a module in the share repository, just keeping the initialization parts here. This is part of a set of changes where I am splitting shr_pio_mod into two pieces: (1) Reading configuration files and initializing PIO appropriately (2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from `cmeps/cesm/nuopc_cap_share/shr_pio_mod.F90`), one in the cpl7 repo (created by extracting the initialization pieces from `share/src/shr_pio_mod.F90`), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)). See ESCOMP/CTSM#1759 (comment) for more context. Needs to be coordinated with ESCOMP/CESM_share#34 ### Specific notes Contributors other than yourself, if any: Discussions with @jedwards4b @mvertens CMEPS Issues Fixed (include github issue #): none Are changes expected to change answers? no Any User Interface Changes (namelist or namelist defaults changes)? no ### Testing performed **Only limited testing performed so far; I plan to run CESM prealpha testing. Please let me know if you'd like more than that (I'm uncertain about whether scripts_regression_tests and testlist_drv give additional value if I'm already running prealpha testing).** Testing performed if application target is CESM: - [ ] (recommended) CIME_DRIVER=nuopc scripts_regression_tests.py - machines: - details (e.g. failed tests): - [ ] (recommended) CESM testlist_drv.xml - machines and compilers: - details (e.g. failed tests): - [x] (optional) CESM prealpha test - machines and compilers: cheyenne intel & gnu - details (e.g. failed tests): tests pass and are bit-for-bit - [x] (other) please described in detail: the following tests pass ``` ERP_D_Ld10_P36x2_Vmct.f10_f10_mg37.IHistClm51BgcCrop.cheyenne_intel.clm-ciso_decStart ERP_D_P36x2_Ld3.f10_f10_mg37.I1850Clm50BgcCrop.cheyenne_intel.clm-default LILACSMOKE_D_Ld2.f10_f10_mg37.I2000Ctsm50NwpSpAsRs.cheyenne_intel.clm-lilac ``` Testing performed if application target is UFS-coupled: - [ ] (recommended) UFS-coupled testing - description: - details (e.g. failed tests): Testing performed if application target is UFS-HAFS: - [ ] (recommended) UFS-HAFS testing - description: - details (e.g. failed tests): ### Hashes used for testing: - [x] CESM prealpha tests: - repository to check out: https://github.com/ESCOMP/CESM.git - branch/hash: cesm2_3_alpha09c, but with: cmeps at 1f8ce13, cpl7 at 15c5d5ce45a9db320b1448e5c29d9892fc57e046 and share at d7c43983b8d84abfc357fa112870bc50b3b60d60 (all from billsacks forks) - [x] For the other tests described above: - repository to check out: https://github.com/billsacks/CTSM.git - branch/hash: branch fix_lilac_pio2, hash 2ead6826d - [ ] UFS-coupled, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash: - [ ] UFS-HAFS, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash:
billsacks
added a commit
to ESCOMP/CESM_CPL7andDataComps
that referenced
this pull request
Jul 8, 2022
Introduce init_pio_mod with the initialization pieces from shr_pio_mod This PR introduces an init_pio_mod that contains just the initialization pieces from shr_pio_mod (from the share repository). This is part of a set of changes where I am splitting shr_pio_mod into two pieces: (1) Reading configuration files and initializing PIO appropriately (2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from `cmeps/cesm/nuopc_cap_share/shr_pio_mod.F90`), one in the cpl7 repo (created by extracting the initialization pieces from `share/src/shr_pio_mod.F90`), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)). See ESCOMP/CTSM#1759 (comment) for more context. Needs to be coordinated with ESCOMP/CESM_share#34 . See also the related PR for CMEPS: ESCOMP/CMEPS#306
billsacks
added a commit
to ESCOMP/CTSM
that referenced
this pull request
Jul 11, 2022
Fix LILAC interface to PIO Fixes the LILAC interface to PIO. This involved splitting shr_pio_mod into two pieces: (1) Reading configuration files and initializing PIO appropriately (2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from cmeps/cesm/nuopc_cap_share/shr_pio_mod.F90), one in the cpl7 repo (created by extracting the initialization pieces from share/src/shr_pio_mod.F90), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)). See #1759 (comment) for more context. Much of the work here was in externals: ESCOMP/CESM_share#34, ESCOMP/CMEPS#306 and ESCOMP/CESM_CPL7andDataComps#16. So this PR updates those externals to versions with those changes. In addition, changes were needed within LILAC - to implement the LILAC version of piece (1) described above. Resolves #1759 (LILAC test failing in ctsm5.1.dev095 with cime/share/pio update)
jedwards4b
pushed a commit
to jedwards4b/CESM_share
that referenced
this pull request
Apr 1, 2024
Extract non-initialization parts of shr_pio_mod to a module in share ### Description of changes Extract the non-initialization parts of shr_pio_mod to a module in the share repository, just keeping the initialization parts here. This is part of a set of changes where I am splitting shr_pio_mod into two pieces: (1) Reading configuration files and initializing PIO appropriately (2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from `cmeps/src/shr_pio_mod.F90`), one in the cpl7 repo (created by extracting the initialization pieces from `share/src/shr_pio_mod.F90`), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)). See ESCOMP/CTSM#1759 (comment) for more context. Needs to be coordinated with ESCOMP#34 ### Specific notes Contributors other than yourself, if any: Discussions with @jedwards4b @mvertens CMEPS Issues Fixed (include github issue #): none Are changes expected to change answers? no Any User Interface Changes (namelist or namelist defaults changes)? no ### Testing performed **Only limited testing performed so far; I plan to run CESM prealpha testing. Please let me know if you'd like more than that (I'm uncertain about whether scripts_regression_tests and testlist_drv give additional value if I'm already running prealpha testing).** Testing performed if application target is CESM: - [ ] (recommended) CIME_DRIVER=nuopc scripts_regression_tests.py - machines: - details (e.g. failed tests): - [ ] (recommended) CESM testlist_drv.xml - machines and compilers: - details (e.g. failed tests): - [x] (optional) CESM prealpha test - machines and compilers: cheyenne intel & gnu - details (e.g. failed tests): tests pass and are bit-for-bit - [x] (other) please described in detail: the following tests pass ``` ERP_D_Ld10_P36x2_Vmct.f10_f10_mg37.IHistClm51BgcCrop.cheyenne_intel.clm-ciso_decStart ERP_D_P36x2_Ld3.f10_f10_mg37.I1850Clm50BgcCrop.cheyenne_intel.clm-default LILACSMOKE_D_Ld2.f10_f10_mg37.I2000Ctsm50NwpSpAsRs.cheyenne_intel.clm-lilac ``` Testing performed if application target is UFS-coupled: - [ ] (recommended) UFS-coupled testing - description: - details (e.g. failed tests): Testing performed if application target is UFS-HAFS: - [ ] (recommended) UFS-HAFS testing - description: - details (e.g. failed tests): ### Hashes used for testing: - [x] CESM prealpha tests: - repository to check out: https://github.com/ESCOMP/CESM.git - branch/hash: cesm2_3_alpha09c, but with: cmeps at 1f8ce1304a7c0939cbc4584e1b5afa5165821fb6, cpl7 at 15c5d5ce45a9db320b1448e5c29d9892fc57e046 and share at d7c4398 (all from billsacks forks) - [x] For the other tests described above: - repository to check out: https://github.com/billsacks/CTSM.git - branch/hash: branch fix_lilac_pio2, hash 2ead6826d - [ ] UFS-coupled, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash: - [ ] UFS-HAFS, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash:
jedwards4b
pushed a commit
to jedwards4b/CDEPS
that referenced
this pull request
Apr 1, 2024
Extract non-initialization parts of shr_pio_mod to a module in share ### Description of changes Extract the non-initialization parts of shr_pio_mod to a module in the share repository, just keeping the initialization parts here. This is part of a set of changes where I am splitting shr_pio_mod into two pieces: (1) Reading configuration files and initializing PIO appropriately (2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from `cmeps/share/shr_pio_mod.F90`), one in the cpl7 repo (created by extracting the initialization pieces from `share/share/shr_pio_mod.F90`), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)). See ESCOMP/CTSM#1759 (comment) for more context. Needs to be coordinated with ESCOMP/CESM_share#34 ### Specific notes Contributors other than yourself, if any: Discussions with @jedwards4b @mvertens CMEPS Issues Fixed (include github issue #): none Are changes expected to change answers? no Any User Interface Changes (namelist or namelist defaults changes)? no ### Testing performed **Only limited testing performed so far; I plan to run CESM prealpha testing. Please let me know if you'd like more than that (I'm uncertain about whether scripts_regression_tests and testlist_drv give additional value if I'm already running prealpha testing).** Testing performed if application target is CESM: - [ ] (recommended) CIME_DRIVER=nuopc scripts_regression_tests.py - machines: - details (e.g. failed tests): - [ ] (recommended) CESM testlist_drv.xml - machines and compilers: - details (e.g. failed tests): - [x] (optional) CESM prealpha test - machines and compilers: cheyenne intel & gnu - details (e.g. failed tests): tests pass and are bit-for-bit - [x] (other) please described in detail: the following tests pass ``` ERP_D_Ld10_P36x2_Vmct.f10_f10_mg37.IHistClm51BgcCrop.cheyenne_intel.clm-ciso_decStart ERP_D_P36x2_Ld3.f10_f10_mg37.I1850Clm50BgcCrop.cheyenne_intel.clm-default LILACSMOKE_D_Ld2.f10_f10_mg37.I2000Ctsm50NwpSpAsRs.cheyenne_intel.clm-lilac ``` Testing performed if application target is UFS-coupled: - [ ] (recommended) UFS-coupled testing - description: - details (e.g. failed tests): Testing performed if application target is UFS-HAFS: - [ ] (recommended) UFS-HAFS testing - description: - details (e.g. failed tests): ### Hashes used for testing: - [x] CESM prealpha tests: - repository to check out: https://github.com/ESCOMP/CESM.git - branch/hash: cesm2_3_alpha09c, but with: cmeps at 1f8ce13, cpl7 at 15c5d5ce45a9db320b1448e5c29d9892fc57e046 and share at d7c43983b8d84abfc357fa112870bc50b3b60d60 (all from billsacks forks) - [x] For the other tests described above: - repository to check out: https://github.com/billsacks/CTSM.git - branch/hash: branch fix_lilac_pio2, hash 2ead6826d - [ ] UFS-coupled, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash: - [ ] UFS-HAFS, then umbrella repostiory to check out and associated hash: - repository to check out: - branch/hash:
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is part of a set of changes where I am splitting shr_pio_mod into two pieces:
(1) Reading configuration files and initializing PIO appropriately
(2) Storing information about PIO (io system descriptors, io types, io formats) and providing an interface to query this information
Piece (2) lives in the share code and is used regardless of the driver. Piece (1) is driver-specific, so for now we have three versions of that piece: one in CMEPS (created by extracting the initialization pieces from
cmeps/cesm/nuopc_cap_share/shr_pio_mod.F90), one in the cpl7 repo (created by extracting the initialization pieces fromshare/src/shr_pio_mod.F90), and one in CTSM's LILAC directory (which is essentially identical to the one in the cpl7 repo). Piece (2) – the actual share code piece – is used by components (their use statements stay exactly as they are now) as well as by piece (1) (which is responsible for setting the module-level variables in piece (2)).See ESCOMP/CTSM#1759 (comment) for more context.
Needs to be coordinated with cmeps and cpl7 branches where I am introducing new init_pio_mod modules.