Light Propogation

Jon is interested in adding a better light calculation to his PV code. At the moment the Beer-Lambert law/equation is being used for light. Firstly we need to understand what is wrong with the current technique. We've been discussing the use of the level set method / fast marching method as an alternative to using FiPy's basic first order upwind scheme, which is quite inefficient and is not working for some problems. Some more thoughts:

  • We don't have a second order accurate implicit scheme in FiPy.
  • Would using a second order explicit scheme be very inefficient. It is a one time cost since it is static, but it could get prohibitively bad for the sort of meshes Jon may need for accurate solutions.
  • FFM will be way more efficient and we have second order schemes available, but not on unstructured meshes.
  • Can we even solve the Beer-Lambert equation using the Eikonal equation?
  • We need to understand what is going wrong with the current solution that Jon showed me in 1D and why it seems to deviate form the analytical. I believe that it is grid spacing.

Given the Beer-Lambert equation,

$ \nabla \cdot \left( \vec{c} \Gamma \right) + \alpha \Gamma = 0 $

let's try and solve a 1D problem with a shock using implicit upwind. See trunk/misc/light.py. With a fixed grid things seem quite good even though this is a 1D scheme. Not sure if this carries over to 1D. Basically the velocity goes from 10 to 1 half way across the domain and we see a shock as expected ($\alpha$ is constant). The results are not so bad.

source:trunk/misc/light.png

The upwind implicit scheme can deal with shocks (at least in 1D). Let's observe how it deals with a large change in the mesh density (see trunk/misc/lightVariableMesh.py). Let's try a 100 fold change. A small jump occurs.

source:trunk/misc/lightVariableMesh.png

A ten fold increase. Seems fine.

source:trunk/misc/lightVariableMesh10.png

A thousand fold increase. Big jump.

source:trunk/misc/lightVariableMesh1000.png

The jumps are not surprising and consistent with a first order scheme. The tail has the right shape even though it has a large displacement. The PV 1D result did not have a tail that modeled the local solution correctly. Maybe that is to do with a gradient of changes rather than 1 jump in the mesh density.

Adding a gradual change example trunk/misc/lightVariableMeshGradual.py shows this

source:trunk/misc/lightVariableMeshGradual.png

This could be the issue with the PV code.

  • Posted: 2012-01-27 12:35 (Updated: 2012-01-27 18:01)
  • Author: wd15
  • Categories: (none)

Comments

No comments.

Add New Comment