Implement abstract type for NetCDF I/O #697
Description
Description
Multiple physics schemes need to read non-decomposed data from NetCDF files, which is allowed under the current CCPP-framework rules. However, host models, like CAM-SIMA, may use specialized libraries (e.g. PIO) to do NetCDF file I/O, which may not be available to all host models and thus cannot be exposed in the physics schemes themselves.
To get around this problem, we recommend creating an abstract type that is defined in the CCPP-framework itself, and that physics schemes can use to do NetCDF file I/O. The actual implementation of the type will then be implemented in each host model as they see fit, although this won't be needed until they use a physics scheme which uses the new data type. This would allow for host models like CAM-SIMA to use specialized I/O libraries like PIO while still ensuring that the physics schemes themselves are portable across modeling systems.
Additional explanation/description of the problem can be found here:
ESCOMP/atmospheric_physics#241
And of course I'd be happy to discuss any aspect of this in more detail!
Solution
Define an abstract class, type, or set of interfaces that would live in the CCPP-framework, and that host models are responsible for implementing if they decide to use it. We already have a possible candidate for this abstract type here:
https://github.com/ESCOMP/atmospheric_physics/blob/main/phys_utils/ccpp_io_reader.F90
So the simplest solution would be to just move this code from ESCOMP/atmospheric_physics to NCAR/ccpp-framework. An example of how this code is actually used in a physics scheme can be found here:
The host model would then be responsible for the actual implementation. For CAM-SIMA we implemented it using PIO via the following two source files:
https://github.com/ESCOMP/CAM-SIMA/blob/development/src/physics/utils/pio_reader_sub.F90
https://github.com/ESCOMP/CAM-SIMA/blob/development/src/physics/utils/pio_reader.F90
Also please note that while CAM-SIMA is using a Fortran submodule approach, this is in no way required for implementation in other host models.
Alternatives (optional)
There are multiple other possible alternatives, although none of them were without flaws (at least when @mwaxmonsky and I did the original scoping effort). Ultimately as long as physics-side interfaces are agreed upon across the CCPP, and that host models can implement those interfaces in a way they see fit, then this issue would be resolved on our end. Thanks!
Related to (optional)
See links in text above.