Debugging diagnostics

[edoddridge]

In preparation for #123 and #124 I've added a number of debugging output dumps. These are controlled by debug_level, as discussed in #109. To facilitate the output, two new subroutines were created that export 2D and 3D fields. These are now called by maybe_dump_output, and at other appropriate places in the code. When debug_level=4 the fields exported every time step are:

• h, u, v
• dhdt, dudt, dvdt
• ub, vb
• eta, etastar, etanew
• Bernoulli potential (BP)
• zeta (relative vorticity = curl of velocity field)

debug_level=1 causes the tendencies to be dumped at the frequency given by dumpFreq.

There are also two tests to check that these levels are working as expected.

This PR includes changes to interpret_raw_files so that every array has three axes, regardless of its dimensionality. This is the same dimensionality pun discussed in #116. It allows the test suite to automatically plot the upper layer of whichever field has caused the failure of the test suite.

The work on this branch caused the short lived ticket #130 to be opened, and then closed when I realised the error was in the output subroutine, not the underlying array.

[codecov[bot]]

Codecov Report

Merging #131 into master will increase coverage by 0.26%. The diff coverage is 97.53%.

@@            Coverage Diff             @@
##           master     #131      +/-   ##
==========================================
+ Coverage    89.9%   90.16%   +0.26%     
==========================================
  Files           5        5              
  Lines        1070     1119      +49     
  Branches       47       56       +9     
==========================================
+ Hits          962     1009      +47     
- Misses         89       90       +1     
- Partials       19       20       +1

Impacted Files	Coverage Δ
aronnax/driver.py	93.51% <ø> (ø)	:arrow_up:
aronnax/core.py	76.24% <100%> (+2.78%)	:arrow_up:
aronnax.f90	92.66% <96.22%> (+0.02%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 6cd272c...8a4b42e. Read the comment docs.

[axch]

Actually, I correct myself. write_output was ensconced inside maybe_dump_output, so actually it was reasonable to eliminate it. It write_output were being called directly from simulation code, it would have been more important to keep it intact.

Also, I'm not sure I understand Github's new commit commenting features -- can you tell which commit each of the above two comments was referencing?

[edoddridge]

I can't see which commits they refer to - but I can guess. If I click on the "view changes" button associated with your comments it shows me all of the changes in this PR, not the changes associated with any particular commit.

I think the first was referencing the first commit: https://github.com/edoddridge/aronnax/pull/131/commits/98ab2f4c8105625ab594e171e38d2c331f9c3ad3

And the second this one: https://github.com/edoddridge/aronnax/pull/131/commits/5c7db7972a8a203991a93e67c5be9c928e17feef

I broke apart the write_output subroutine partially so that the new ones could be called from other places in the code, when the rest of #109 gets implemented.