sadly, the answer is, I don’t know either.

debugging is an art, fortunately art can be trained to certain level as well.

so here’s some general guidance.

Repeat the problem
Make sure the error you saw isn’t random, maybe it sounds funny. But I see random errors, nasty ones that jump around which is very hard to debug. It also gives hints to where the problem might be. Since computer is consistent, the “random” error might due to memory leak or random designed by your code.

So setup a scene, make sure you can repeat the error whenever you want, I know you want to jump directly to the problem and fix it and don’t want to see it again. But please be patient to setup the crime scene first.

See what happened
It’s not strict forward as it sounds, you saw a message on the screen. It doesn’t exactly tell you what happened, nor the location, not alone why it happened. To find out why, you need to be a detective. Print out everything that is close to the problem. If all the information making sense, then print more info around the problem, and start to trace back. If luckily you find out something isn’t making sense, congratulations, you’re close to the answer

In simulation, to see whatever you want adds some complexity due to the size of the problem and the amount of the data. Ex. make sure you can visualize your matrix or customized data-set when problem happens; and sometimes if you don’t save all the time, make sure you can repeat to the exact time before the problem.

In general, you want to have all the tools to see whatever you want around the crime scene, the more detailed key information you can access, the easier the job is, like in the movie.

Log events and important informations
When everything goes fine, nobody want to waste time on old records. But things normally don’t turn out to be what you want, if you have a log, it’ll make your life much easier, since you can trace back what you’ve done before.

Log and document your coding, make comments on what you did on this piece of code. If things get wrong tomorrow, you might go to the change you made right away if things were good before the change.

Log your events when code starts to run, let your code write some messages telling you what it’s doing, and some key parameters it generates when it runs, so you know it’s working. If code break at certain point, you can look at the file it generates and start at approximate key algorithm location.

Imagination and logic
Please do use your imagination when debugging, you might get to the point quicker if you’re lucky, some bugs can be very hard and nasty to dig out if you follow logic sense too strictly.

Btw, did I mention, debug is an art, well, your talents (imagination and luckiness) can be good here, and hard working (log and documentation) does make life a bit consistent

Notes : I personally don’t use debugger these days, because debugger version is too slow to run, and release version doesn’t contain debugger info. And normally debugger scales me, I don’t know what to do when I’m in them. I assume, only hacker use debugger, and I’m no hacker, I do want to be one of them though.

What if you want to compare your adaptive result with analytic solution to make sure you’re on the right track ?

It’s easy. Step 1, Load your data first as always,

[time,fd]=tmmpost(nframe);

Step 2, create a uniform grid that you want to convert to, here’s an 2D example.

gd={-1:0.01:1;-1:0.01:1};

Step 3, call fjuniform to convert,

fdu=fjuniform(fd,gd);

Type fd, and fdu to take a look

1
2
3
4
5
6

fd{1}
    [34x34 double]    {2x1 cell}    [0]
    [12x10 double]    {2x1 cell}    [1]
    [10x12 double]    {2x1 cell}    [1]
fdu{1}
    [11x11 double]    {2x1 cell}    [0]

so now fdu only contains uniform meshes, the density of the mesh and the location solely depends on the gd. The algorithm behind fjuniform is based on the interpolation of possible finest mesh onto new mesh.

The last question is how do I visualize the uniform field then ? simple, plug back into fjcolorgridm as usual