Conversation
…xperimental code.
pp-mo
force-pushed
the
structured_load_api
branch
from
c641653 to
fed341f
Compare
| Header elements of potential concern include LBTIM, LBCODE, LBVC, | ||
| LBRSVD4 (ensemble number) and LBUSER5 (pseudo-level). | ||
|
|
||
| Known current shortcomings: |
There was a problem hiding this comment.
This section currently appears within the "warning" box, which may not be such a good idea.
It is not really about the same things.
On review, I'll investigate re-casting this as a separate "regular paragraph", like "Use of callbacks" and "Applicability"
| The results from this are normally equivalent to those generated by | ||
| :func:`iris.load`, but the operation is substantially faster for input | ||
| which is structured. | ||
|
|
There was a problem hiding this comment.
Probably don't need to separate these notes into their own paragraphs?
| For calls other than :meth:`~iris.load_raw`, the resulting cubes are | ||
| concatenated over all the input files, so there is normally just one | ||
| output cube per phenomenon. | ||
|
|
There was a problem hiding this comment.
Again
Probably don't need to separate these notes into their own paragraphs?
| inputs. Otherwise, odd behaviour and even incorrect loading can result, as | ||
| input files are not checked as fully as in a normal load. | ||
|
|
||
| Even where applicable, structured loading is not an *identical* replacement |
There was a problem hiding this comment.
"where applicable" --> "where it is applicable"
reads better
| A context manager is used to enable fast um loading in all the regular iris | ||
| load functions, such as :meth:`iris.load` and :meth:`iris.load_cube`, | ||
| when loading data from UM file types. | ||
|
|
There was a problem hiding this comment.
Add a trivial example of usage.
| dimensions and the choice of dimension coordinates. | ||
|
|
||
| * although both constraints and user callbacks are supported, callback | ||
| routines will generally need to be re-written. |
There was a problem hiding this comment.
Add brief words to explain the 'why+how' of the change to the callback context.
| In particular, the callback's "field" argument is a | ||
| :class:`~iris.fileformats.um.FieldCollation`, from which "field.fields" | ||
| gives a *list* of PPFields from which that cube was built. | ||
| The code required is therefore different from a 'normal' callback. |
There was a problem hiding this comment.
Add a link to the test code, providing example of "translating" a callback.
| For full details, see : :meth:`iris.fileformats.um.structured_um_loading`. | ||
|
|
||
| Not all input files will be suitable for structured loading: Each file | ||
| must have a regular repeating order of time and vertical levels, as described |
There was a problem hiding this comment.
Add the "complete set" concept into this statement somehow.
"Each input file must have a complete set of all combinations of time and vertical levels, arranged in a ordered pattern, as in UM model outputs."
|
|
||
| For full details, see : :meth:`iris.fileformats.um.structured_um_loading`. | ||
|
|
||
| Not all input files will be suitable for structured loading: Each file |
There was a problem hiding this comment.
Add a hint that you can "try" structured load + compare, and in many cases results will be identical,.
| ]] | ||
| Fast UM file loading: | ||
| --------------------- | ||
| Support has been added for accelerated loading of UM files (PP and |
There was a problem hiding this comment.
Add specific test-data example with speedup factor.
pp-mo
force-pushed
the
structured_load_api
branch
from
9042b42 to
4d69994
Compare
|
I think I've now addressed all the outstanding stuff we noted down. |
3 participants
This now replaces the discussion PR on the "feature branch" in my repo : pp-mo#27
NOTE NOT READY YET : documentation changes still need to be reviewed/finalised/agreed.
from notes there: