Yes, Kelvin. To clarify, in #5 the temporary output data calculated in Trunc() is “undone” and gets recalculated when the simulation calls the evaluation function with the new timepoint/shorter timestep…
To take this a step further, there are two ways to use Trunc(). The way that I’m doing it forces the simulation to produce a timestep at a particular time. I could do that because I wanted to trigger at a specific time (per the user’s requirements).
The way that Mike’s ACME Semi (or whatever) example does it (and, I think, you also) is conceptually different. In the example, well, the circuit is complicated and the component doesn’t know exactly when it would need to change state. So…
The example checks to see if the proposed t (in Trunc()) would produce a change in component state. If so, it “sneaks up” on the state change by setting the *timestep to a small “tolerance value.” This may cause multiple extra unnecessary simulation steps (where the state doesn’t change). But that’s required because of the uncertainty about when the state would actually need to change. In this case, the *timestep is truly a “tolerance.”
Anyway, that’s how I understand things. I have a half-finished “C-Block Basics #4” that focuses on Trunc(). I guess I need to complete and upload it to my repo.
–robert