Hi all,
When using the (at-time T step-functions ...) functionality, I run into
problems when specifying a time T that is very close to an actual time
at which an iteration of Meep takes place. It can happen, that the step
function gets called one iteration later although the later time is not
close to T anymore.
Looking into the source code, I found that at-time calls after-time,
which does a simple >= check. I guess that this check suffers from
floating point precision issues in the sense that my specified time T is
ever so slightly larger than the Meep time T0 of the iteration during
which I want the step-function to execute. Thus, the step-function gets
called one iteration (and one time step) later.
As a workaround, I currently subtract 1e-5 from my specified time T;
this ensured (so far) that the step-function gets called during the
right iteration.
My questions are:
1.) Is this intended behavior?
2.) If not, would it make sense to alter the definition of at-time in a
way that the step-functions of an (at-time T ...) are called during the
iteration with a Meep time that is actually the closest time to T? In
this case, I can submit a patch to the repository.
Cheers,
Thomas
_______________________________________________
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
