Bug 1227 - Fast Cloud PHA_File Driven By View Angle Not Illumination Angle
Summary: Fast Cloud PHA_File Driven By View Angle Not Illumination Angle
Status: RESOLVED FIXED
Alias: None
Product: DIRSIG4
Classification: Unclassified
Component: Materials/Radiometry (show other bugs)
Version: 4.7.1-release
Hardware: Intel x86-64 Linux 64-bit
: P5 normal
Assignee: Adam Goodenough
URL:
Depends on:
Blocks:
 
Reported: 2016-08-11 18:32 EDT by Jeff Dank
Modified: 2016-09-30 16:04 EDT (History)
1 user (show)

See Also:


Attachments
Illustration of my confusion (134.37 KB, image/png)
2016-09-14 15:49 EDT, Jeff Dank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Dank 2016-08-11 18:32:44 EDT
This file appears to be driven be the View angle and not the solar illumination angle.

i.e. 180deg angle is always back towards the camera... not back towards the source, making it only possible to view clouds with the sun directly behind the camera.


I had a test case working for straight down looking with sun directly overhead... Then I moved the sun to be off 45 degrees thinking I may need to adjust the 135 deg angle to incorporate changes to the radiance, but adjust the 180 deg angle was the one that did it.
Comment 1 Adam Goodenough 2016-09-13 15:04:43 EDT
This particular property is actually queried by the cosine of the angle between the view and the source so I don't think the angle definition should matter. 

However, in checking this out I noticed that the view direction in the dot product was missing a negation (i.e. it was always the forward direction of the ray, not the vector back towards the viewer). I'm guessing this is the cause of the issue and that flipping the vector will fix it, but let me know if that ends up not being the case.
Comment 2 Adam Goodenough 2016-09-13 17:12:51 EDT
The issue is that the local entry and exit points were not getting copied from the hitlists correctly (assignment ops were resetting the values regardless of what the source copy said). I should have a fix soon.
Comment 3 Jeff Dank 2016-09-14 15:18:19 EDT
Just to be sure I'm reading your comments correctly, something is not working as expected correct?

What I'm confused about is why the scattering phase file has any dependence upon viewing geometry. I'm picturing this as a weighting file for forward and back scatter from an illumination source. 0 being forward scatter and 180 being back scatter.
Comment 4 Jeff Dank 2016-09-14 15:49:02 EDT
Created attachment 392 [details]
Illustration of my confusion
Comment 5 Adam Goodenough 2016-09-22 16:19:56 EDT
First, comment 2 is in the wrong bug (this had to do with your other bug on the transformation of the atmospherics section) -- sorry for putting that in the wrong place

Second, the angle is measured from the forward direction of the source to the direction back towards the viewer. 90 deg is a little ambiguous since it could be to the forward or backward source direction -- so i'm a little confused by the illustration? Also, just to be clear, the cosine only matters because its the dot product of the two vectors -- quicker than than taking the arccosine.
Comment 6 Jeff Dank 2016-09-27 00:53:25 EDT
files have been uploaded to dropbox to reproduce some of the trouble I'm having. There is a README included
Comment 7 Jeff Dank 2016-09-30 16:04:00 EDT
this appears to have been an artifact of a small number of phase angles in the .pha file. I created one with very high resolution and everything appears to be working as expected with both nadir and off nadir cases.