nancycollins
commented
2 years ago i do think where possible as much of our code should use the routines in the netcdf_utilities_mod for the following reasons:
- if you use those file open/create routines the filename will be stored and provided in any error messages without the calling code having to pass it.
- the routine names are intended to be more helpful/self-explanatory to someone unfamiliar with the netcdf API.
- the routines hide native netcdf id numbers and use strings to identify vars, dims, etc for readability.
- the routines are mostly single-operation for simplicity of interface, implementation and to make the calling code more self-documenting.
- the calling code does not have to 'use netcdf' in the modules list.
however - they were also expected to cover ~90% of the cases but not 100%. the hope was they covered almost 100% of any model_mod.f90 needs, but inside the dart i/o code i expect there may be uncommon cases where something is needed that is best served by using native netcdf calls rather than try to add complex interfaces to netcdf_utilities_mod. it's a judgement call, obviously, and the more the netcdf calls can be isolated to a single module the easier it will be to swap in a different i/o library should that be required. but i suspect that module may not be able to cover every possible case.
hkershaw-brown
Hit this while working with TIEGCM:
There is a module netcdf_utilities_mod, but it looks like the state io makes almost no use of netcdf_utlities_mod (execpt nc_check). e.g. location_io_mod, direct_netcdf_mod, state_structure_mod.
linked issues: https://github.com/NCAR/DART/issues/287 https://github.com/NCAR/DART/issues/269 https://github.com/NCAR/DART/issues/106 https://github.com/NCAR/DART/issues/309 ( 3. top level is boundary condition).