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
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.
The text was updated successfully, but these errors were encountered:
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
printf
s over and over again just to figure that out.The text was updated successfully, but these errors were encountered: