Bug 623 - Secondary source contributions are too large
Summary: Secondary source contributions are too large
Status: RESOLVED FIXED
Alias: None
Product: DIRSIG4
Classification: Unclassified
Component: Materials/Radiometry (show other bugs)
Version: 4.4.4-release
Hardware: All All
: P5 enhancement
Assignee: Scott D. Brown
URL:
Depends on:
Blocks:
 
Reported: 2008-08-15 13:38 EDT by Scott D. Brown
Modified: 2013-08-08 16:02 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott D. Brown 2008-08-15 13:38:45 EDT
The demo scene (SecondarySources1) reveals that the contribution from a point source is off by a factor of 10,000.  This was found to be a result of a radiometry calculation that forgot to convert an irradiance from W/m^2 to W/cm^2 (which is the internal units).

The fix for this will be in 4.2.1

For now, users can manually adjust there radiant intensity files by dividing the values by 10,000 to get the correct units in the DIRSIG calculations.  This would be a temporary fix and users will need to remember to undo this when 4.2.1 is released.
Comment 1 Scott D. Brown 2008-08-15 13:42:04 EDT
Committed the fix in SVN Revision 325.
Comment 2 Adam Goodenough 2012-09-26 13:50:13 EDT
The same mistake was made in the newer form of sources such that the units were per [m^2] rather than per [cm^2] (the lack of consistency between internal units is a larger issue to be addressed later). A fix will make it into the final 4.4.4 release.
Comment 3 Scott D. Brown 2012-11-12 15:34:28 EST
I am pretty sure we ran out of time to get this into the 4.4.4 release (we never recut new builds after the preview).  So I think this should be on our 4.5.0 list?  Is the fix in the trunk?
Comment 4 Scott D. Brown 2013-07-15 14:26:46 EDT
I'm 99% sure we fixed this for the 4.5.x builds.  Anyone can correct me if I am wrong.
Comment 5 Scott D. Brown 2013-07-17 12:18:20 EDT
Mike and some external users have verified that we never did resolve this problem.
Comment 6 Scott D. Brown 2013-07-17 12:20:32 EDT
After a discussion this AM, we are going to inject the 10,000 correction factor into the 4.5.1 release and 4.6.0 trunk.

At one point, we encouraged some users to add the 10,000 factor to their .INT files as a temporary fix. Once we add this fix to the code, they will need to go back to using the correct value in their files.
Comment 7 Scott D. Brown 2013-07-17 12:44:38 EDT
The correction factor was added to tags/4.5.1 and trunk for libFD/FDLegacyPointSource.cpp in SVN r12704.
Comment 8 Scott D. Brown 2013-08-08 16:02:21 EDT
In addition, we have now made the "normalize shape" option default to "true" rather than "false". This means that old scene setups that don't have that option set will act differently as of 4.5.1 in the following ways:
* The incident flux from the source will be 10,000 lower than in 4.5.0 or earlier because
   of the cm^2 vs m^2 issue discussed in this bug.
* Unless the normalize shape flag is explicitly set to false, the total (spherically and
  spectrally) integrated power will be constant.