/products/ioapi/io_req.html
is self-contradictory ("portable" vs. "native")
Is unnecessarily "re-inventing the wheel".
We've just spent a lot of effort getting rid of the problems caused by stream-based data access assumptions !!! NO! NO!! NO!!!
Deterministic clock is essential to any coupled-model system.
NOT needed for any realistic application.
I don't really believe this. Neither did ORD when queried about it during the Models-3 Requirements phase!
We've been through this one in detail before: non-structural metadata is properly the subject of post-processing and not of the I/O interface. This represents a major failure to separate concerns (or a major violation of modularity) in the analysis.
...is definitely required We are already at the point where data volumes are on the order of 1 GB/variable/day, and where vis systems (such as Vis5d that assume "Everything--including seek pointers and address-offsets--is an int are grossly inappropriate.
should be under the modeler's control, and should probably be done via time-independent transform matrices, not by an API that wastes time redundantly computing the necessary transforms. That's why SMOKE is so much faster and more efficient than EPS!
Need geometry-related utilities (see /products/ioapi/gefile.html)
Definitely required: the dataset for the 2000 AMS presentation was 38 GB--because we extracted/cut down just the subset we needed. The original was 300 GB.
Projected in-memory requirement for large TOPLATS visualizations is on the order of 5 PB.
How large an app? This is not achievable in general, even with dedicated access to an ASCI-class machine.
<PLEADING>It's not "M3IO", damn it!</PLEADING>
And many more: see /products/ioapi/gefile.html for just a start.
This can also be handled on the application level (e.g., proposed WRF standard to pass all georegistration questions through "WRF standard-sphere-Lat/Lon" and "GRS80-Lat/Lon")
No! NO! NO! -- our current models and model couplings are based on getting away from the sequential dependencies that caused such problems in the 1980's!
What if we deal with MM5? Note that the full strength of F90 is as complex and as fraught with surprises as the worst of C++ ever has been. And at that, neither language has a powerful-enough polymorphism paradigm for what we need to do with I/O!
And rather more than that... which is why there are M3CPLE and MTXCPLE.