Modified calculate_K_trans to compute tau between a list of points within input_data.

[damianjilk2]

Current version consists of an updated tau calculation where it now considers a list of positions acquired from input_data.json. Future work includes:

• Add tests/validation to ensure tau is being calculated correctly (or at least as expected)
• Implement default position calculation for voxels set to center
• Handle scenarios where the user inputs multiple values for one voxel
  • Average the tau values to find streaming operator and then flux
  • Perhaps consider other averages as well (such as averaging the streaming operator or increasing matrices and averaging the flux)
• Implement input validation and edge handling

[damianjilk2]

Too much time has been spent on configuring an implementation for the user to input positions. The next version will simply have the user input a dictionary depicting the voxel index and the physical position they wish to calculate. Future versions should also allow for multiple points per voxel.

[damianjilk2]

An issue was brought up during the neutronics meeting noting a positive value for the streaming operator during intra-voxel calculations. Here is the referenced conversation:

Some thoughts: We (I?) keep conceiving of this 1-D problem as being finite in the other dimensions. This isn’t true for a real 1-D problem. In a real 1-D problem, those other dimensions are infinite and I think are the origins of the exponential integrals in the L&M “Slab Geometry” derivation It’s good for you to be able to explain why this is true. If you are going to do the 1-D case properly as a slab geometry, you’ll need to use Eqn 5-30 as the basis such that your streaming operator is ½ E1(tau), after all You can avoid the higher order exponential integrals that arise in Eqn 5-38 onwards by using a stochastic approximation to the integral.

[damianjilk2]

NOTE: eq 5-29 from Lewis and Miller is the same as scipy.special.expn. Thus, we can use scipy.special.exp1(tau) in order to solve E1(tau).

Update: issues remain with the with the streaming operator being greater than 1 for intra-voxel calculations despite the new equation.

[damianjilk2]

This PR allows the user to input a dictionary of positions that they would like to be calculated rather than defaulting to the left edge of the voxel.

This implementation averages the streaming operators if there are several values within one voxel, ensuring that all combinations are iterated through and calculated.

A bug currently exists with the equation used for the streaming operator and will be addressed further in a different PR (Issue #36).

The tester script has been modified as well to account for the new datatype used for positions as well as for the new equation used to solve for the streaming operator.

Please make note of issues with readability or noticeable bugs or problematic code within the scripts. Thank you for reviewing!

[damianjilk2]

Many code changes since last PR review.

• Created a Voxel object to implement OOP.
• Reduced computation time by only calculating the upper triangle of K_trans since transport is symmetric.
• Simplified calculate_K_trans significantly by calculating transport in just one direction (because of symmetry) and ensured edge cases still are computed as expected.
• Created a validate_input method to check the user input.
• Updated input_data.json to include a list of voxel information. Future work will result in removing the scattering cross-section since this will be calculated with ray-tracing.
• Future work will include allowing voxels to be different sizes.
• Adjusted number of logging comments. This will be further reduced after more features are included and many voxels are considered in the calculations.