This project has moved and is read-only. For the latest updates, please go here.

Possible bug in frequency-domain tallies?

Nov 3, 2011 at 7:00 PM
Edited Nov 3, 2011 at 7:03 PM

I was looking back at the frequency domain tally ROfRhoAndOmega, and noticed the following:

1) The number of frequency bins is one less than the number supplied. In the constructor (line 34 of ROfRhoAndOmega.cs):

            Mean = new Complex[Rho.Count - 1, Omega.Count - 1];

While this is appropriate for spatial and time bins, I wonder if this is wrong for frequencies. For example, someone who specified 0.0:0.1:1.0 GHz would actually get back data from 0.05:0.01:0.95 GHz.

If I understand correctly, we are not looking to tally for a "span" of frequencies between bin endpoints, but a sampling of the precise frequencies handed to the tally. I'd propose it should be alternatively:

            Mean = new Complex[Rho.Count - 1, Omega.Count];

2) Correspondingly, the tally (line 93) "misses" the first frequency of interest specified (Omega.Start):

            for (int iw = 0; iw < Omega.Count - 1; ++iw)   
            {               
                      double freq = (iw + 1) * Omega.Delta;
                      ...
            }

For example, what if that first frequency was 0 (steady-state reflectance); how would we tally this? I'd propose alternatively:

            for (int iw = 0; iw < Omega.Count; ++iw)   
            {                
                      double freq = (iw + 1) * Omega.Delta;
                      ...
            }

 Thoughts?

Nov 3, 2011 at 7:17 PM

I made all the detectors regard binning consistently.  I think though that you raised a good point.  The photon weights are not binned in frequency, they are just evaluated at the omega's specified. So I'd be fine with your edits and bug fixes.

Nov 3, 2011 at 7:45 PM

I should note that there is also a separate bug here - the variable "freq" assumes the frequencies specified are 0-based, not a range starting at an arbitrary frequency.

Nov 3, 2011 at 8:01 PM

Good catch.

Nov 3, 2011 at 8:03 PM

Thanks for the feedback. I'll implement the changes accordingly. This will also affect the reading/writing of the detectors, so I'll edit that code too.

Nov 3, 2011 at 9:48 PM

I would like to add that the spatial frequency domain tallies will have the same characteristics as temporal frequency. Likewise one could imagine running a single CAW simulation for an array of absorption coefficients.

Nov 3, 2011 at 10:11 PM
itsScience wrote:

I would like to add that the spatial frequency domain tallies will have the same characteristics as temporal frequency. Likewise one could imagine running a single CAW simulation for an array of absorption coefficients.

Thanks Adam...err...itsScience. This is actually how I ran into the problem, and an update is coming with changes to all F-D tallies.

Nov 3, 2011 at 10:51 PM

Ok, it's done - all tests are passing and I just pushed the changes. One note regarding unit tests:

All the layer tests had ROfRhoAndOmega[0,0] tested against the C/Linux code given the old convention. I updated the tests, including

- Updating the input ranges of the simulation to correspond to the same test frequencies (Start: 0.025, Stop: 1.0, Count: 20),  instead of (Start: 0.0, Stop: 1.0, Count: 21)

- Commenting the actual tests with the following:

// todo: warning - this validation data from Linux is actually for Omega = 0.025GHz
// (see here: http://virtualphotonics.codeplex.com/discussions/278250)

Finally, when we get around to posting a new set of binaries, we should add a comment regarding this change with a link to this thread, as well as update Souroush's thread similarly

Nov 4, 2011 at 1:38 AM

Thanks for making the updates to the unit tests David.