You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The netcdf loading "actions" code was written this way, basically, to maximise similarities with what went before, but it leaves considerable opportunities to simplify + improve.
(1) We (I!) wrote a lot of code designed to replicate the firing of the equivalent original logic rules (here for example), allowing us to debug the operation of the code and compare it to the original implementation, in case problems arose with loading some files (compared to older Iris versions).
In practice no such problems really happened, so this complex debugging/logging is pretty redundant (as it was in the original rules code, really).
(2) Likewise, the way the "facts" of the current loading case (per cube) are stored in a database is pretty cumbersome + obscure (notably here), and could be usefully streamlined.
So in both those areas, there's a big opportunity to simplify the code and improve maintainability, and probably efficiency too.
The text was updated successfully, but these errors were encountered:
In the course of working on loading tolerance work for #5165 (comment) within the 3.12 sprint work, we have been reminded that the original work to replace Pyke rules with our own "custom rules engine" approach has effectively left a lot of inefficient and complex (non-functional) scaffolding in place
The netcdf loading "actions" code was written this way, basically, to maximise similarities with what went before, but it leaves considerable opportunities to simplify + improve.
(1) We (I!) wrote a lot of code designed to replicate the firing of the equivalent original logic rules (here for example), allowing us to debug the operation of the code and compare it to the original implementation, in case problems arose with loading some files (compared to older Iris versions).
In practice no such problems really happened, so this complex debugging/logging is pretty redundant (as it was in the original rules code, really).
(2) Likewise, the way the "facts" of the current loading case (per cube) are stored in a database is pretty cumbersome + obscure (notably here), and could be usefully streamlined.
So in both those areas, there's a big opportunity to simplify the code and improve maintainability, and probably efficiency too.
The text was updated successfully, but these errors were encountered: