...
We will focus on IODA and more precisely on ObsSpace.
Changing the internal structure of the ObsSpace. New design.
2 prototypes candidates: Column Priority priority or Raw Row priority.
Row priority occurs only once.
Decided to go with both.
Cons: Column priority: what is now. Raw will be better. Avoid arrays of boolean (for C++) and unsigned type (for Fortran).
Flexible new features: able to slice and dice the ObsSPace. Imagine the ObsSpace as a spreadsheet.
...
Steve: Will not change the IODA files. The interface (yaml) will stay the same. The switch will be transparent.
Yannick: That will be novnice.
??: Can you give details about the raw row approach.
Phil:
Steve: Coplumns corresponds Columns correspond to variables. Raws correspond to locations. Currently we are manipulating variables (rawrow). So raw row priority is advantageous
Zhiquan (Jake) Liu: do we expect new implementation will speed up something and/or less memory use?
...
Steve: Slice the pieces that we want to pick and pass only what is needed to UFO.
Phil: will drop stl maps, and keep only vectors. Searches are faster with vectors rather than maps.
...
Steve: Time window filtering will remain. Time binning will also stay. We are only touching the storage. Datetime is like a column. There will be move, remove removal and write of columns
Phil: There will be permissions, ie some columns will be read only.
Steve: original obs can be put read only (in a different column) to be used later as verification. Today, we don't have the read only check.
...
Steve: we currently have read an and write of IODA files and ODB. That will stay. Working on a BUFR read, should be available in the next months.
Yannick: Anymore questions. We welcome visitors from all partners. See you next week.
| View file | ||||
|---|---|---|---|---|
|