In ancient times, KHARMA had a compile option to "trace" a zone: print values for the primitive and conserved variables at that zone at many points during a step (before/after each task, iirc).
Recent bugs indicate to me we should bring that functionality back, to make it easier to double-check the actual numbers the code is processing. The original version was verbose and unwieldy, though, so we should allow users to narrow the firehose. I'm thinking something like:
<trace>
i = 10
j = 11
k = 12
level = 2
variables = prims.rho, cons.rho
The idea is to allow users to print values in a zone (or even a small 2D region of adjacent zones?) at different points during a step, looking for where and how the values change. This lets us check a bunch of different assumptions which might otherwise let small bugs lie around for ages ("surely this function will modify the current fluxes!" (#132) "when I call the boundaries they affect only the boundary regions!" (#128)).
When first developing KHARMA, I had assumed zone printing would be superseded by writing out new variables to the output dumps, and then plotting the results. But the two are complementary debugging strategies: sometimes you just need to know if the value in the cell did the change, and we should stop leaving everyone to write a million printfs over and over again just to figure that out.
In ancient times, KHARMA had a compile option to "trace" a zone: print values for the primitive and conserved variables at that zone at many points during a step (before/after each task, iirc).
Recent bugs indicate to me we should bring that functionality back, to make it easier to double-check the actual numbers the code is processing. The original version was verbose and unwieldy, though, so we should allow users to narrow the firehose. I'm thinking something like:
The idea is to allow users to print values in a zone (or even a small 2D region of adjacent zones?) at different points during a step, looking for where and how the values change. This lets us check a bunch of different assumptions which might otherwise let small bugs lie around for ages ("surely this function will modify the current fluxes!" (#132) "when I call the boundaries they affect only the boundary regions!" (#128)).
When first developing KHARMA, I had assumed zone printing would be superseded by writing out new variables to the output dumps, and then plotting the results. But the two are complementary debugging strategies: sometimes you just need to know if the value in the cell did the change, and we should stop leaving everyone to write a million
printfs over and over again just to figure that out.