Presently, if one requests "qv" be read or written in a stream, you'll get an error that qv doesn't exist. Instead, you must read or write the entire scalar array, even if you don't need it all. That's quite a lot of unneeded bytes. This is a problem for the MPAS JEDI data assimilation, which doesn't use all the number concentrations. One step of the data assimilation workflow is entirely MPAS I/O dominated.
A workaround we're trying is to compile MPAS twice: once for the forecast, and once for the data assimilation. The data assimilation has a limited set of scalars via #ifdef in Registry.xml. MPAS ignores the unrecognized number concentrations when reading and writing the files since they're in separate NetCDF variables.
Ideally, we shouldn't have to compile MPAS twice to read or write a subset of the scalars.
Presently, if one requests "qv" be read or written in a stream, you'll get an error that qv doesn't exist. Instead, you must read or write the entire scalar array, even if you don't need it all. That's quite a lot of unneeded bytes. This is a problem for the MPAS JEDI data assimilation, which doesn't use all the number concentrations. One step of the data assimilation workflow is entirely MPAS I/O dominated.
A workaround we're trying is to compile MPAS twice: once for the forecast, and once for the data assimilation. The data assimilation has a limited set of scalars via
#ifdefin Registry.xml. MPAS ignores the unrecognized number concentrations when reading and writing the files since they're in separate NetCDF variables.Ideally, we shouldn't have to compile MPAS twice to read or write a subset of the scalars.