Open fmalatino opened 1 month ago
Those results are surprising, considering that they were generated with Acoustics
which touches upon most of the code. The next steps are:
FVDynamics
which is exactly all the dycoreUltimately, we should tie a coverage to a dataset so we now how to reach global coverage.
Thinking more about this, it actually makes sense.
The way the code works we never "execute" the stencil code declared under gt4py frontend. Instead we code generate then we jump over to the generate code in the .gt_cache_X
folders. This means the coverage will always see those code as "uncovered".
Partial fix is to include in the coverage the cache directory. Partial solution, because we still want the coverage to look at what code is being touched overall in-between stencils. Also __INLINED
and other code culling system within the stack will chop away code and will remove use from being able to have coverage
look at them. Maybe this can only be fixed by custom implementation of coverage tool from with gt4py and/or orchestration.
This issue will be worse under orchestration.
Is your feature request related to a problem? Please describe. Through the use of
coverage
current code coverage in test suite is 33%. Coverage of stencils should optimally be at ~75% Output fromcoverage
:Describe the solution you'd like Additional tests to increase coverage