Comments (11)
The ability to define a detector NA for both reflectance and transmittance tallies has been done for a while. I also added a surface fiber detector with user-specified radius, NA, and final tissue region index (so can have adjacent to tissue or air gap). I also created a surface fiber tissue region so that if adjacent, I could handle the refractive mismatch between the fiber and the tissue. I used this code to try to recreate results that a user was interested in, however never obtained a complete match. I reached out to the authors of the results we wanted to match to check that they took such care with the MC simulation under the fiber and they thought the coder most likely did.
from vts.
from vts.
David, thank you very much for your feedback. Since you were part of the original design, I knew you'd catch consistencies and also know the best code design.
The paradigm shift that I'm wrestling with is that all of our detectors are currently "virtual". They are like surface or volume sieves tallying photon trajectory activity but not changing that trajectory. So, for instance, the RadianceOfRhoAtZDetector was defined to tally radiance as a function of rho at a certain depth Z within the tissue. This was actually designed for dosimetry estimates not for a submerged fiber. It is an internal surface detector that tallies as photons go by the surface. There is no physical detector defined. I don't think anyone has used this detector so no lessons learned so far.
To define detectors that mimick reality closer, then the detectors will need to be part of the tissue structure and take a more "real" role in that they will change the photon trajectory. This would be your "other alternative". So a submerged fiber in intralipid would have a vertical cylinder tissue region representing the fiber and photons would interact with this region.
This is somewhat consistent with my proposal for the fiber at the surface except here there is a virtual boundary at the tissue-air interface, so I thought that the fiber would lie between the tissue and that virtual boundary and be infinitesimally thin. I thought of having an air layer above the tissue that has a vertical cylinder representing the fiber and transport would continue into that layer. I didn't like this idea because the tally is occurring solely at the fiber tissue interface and no other.
You gave me good food for thought. I'll ponder some more.
from vts.
from vts.
I think we agree about current reflectance tallies. But just to recap. We run a photon trajectory and all reflections/refractions at the tissue surface are based on comparing the n=1.0 of air with n of tissue. This progresses until the photon refracts out of the tissue and is killed (so a direction change but no weight change - the refraction is a pseudo-collision). Then the photon trajectory that occurred is "replayed" for any detector definitions and for ROfRho say, the exiting location is checked to see if it is within Rho (and the refracted direction is checked against NA on the branch code). So the detector plays no part in the photon trajectory.
If we were to have a fiber adjacent to the surface, then the photon trajectory would check reflections/refractions based on n of the detector if the photon is at the detector location. So if I were to run the photon trajectory described above, the fiber n (which is most likely >1.0) could potentially change what happens to the photon when the photon is at the surface at the detector. For example, if the fiber were not there the photon could possibly reflect at that location, however, if the fiber is there and say had an n that matched the tissue, it would pass through to the detector and be killed.
Are we with the same understanding or am I missing a subtlety of your comment?
from vts.
I have discussed this over with others and have come to the following plan:
For fiber detectors, the user can define a CylinderTissueRegion as part of the tissue definition so that the photon transport will interact with this region. We already have a CylinderTissueRegion class with properties Center, Radius, Height and OPs. For a fiber that is at the surface, the Height specification should be set to 0.
I will code up RayIntersectBoundary in CylinderTissueRegion (it is currently not implemented) and handle the usual interaction with a cylinder. I will add in a case for when the height is 0 so that the photon interacts with a circle at the surface. I think we have an assumption that any layer inclusion lies entirely within the layer. I'll see if I run into this problem coding this up.
With this plan, the user can define whether the detector is there virtually or realistically. It will also accommodate defining a realistic source for example, for the one fiber source we have, LambertialSurfaceEmittingCylindricalFiberSourceInput.
I plan to proceed with this code on the branch. I will post my status as I go.
from vts.
I have progressed with the code development. I am now working on the VirtualBoundary related to the detector. I was going to use the RadianceVirtualBoundary for the submerged fiber detector, CylindricalFiberDetector, because they are both internal surface detectors. The one detector we have associated with this VB is RadianceOfRhoAtZ which was designed with dosimetry in mind. The VB has code particular to this detector within it (i.e. checking if Uz>0 downward flow) which makes it different from all the rest of the VBs. If I use this same VB for CylindricalFiberDetector, I would need to add code particular to this detector.
As I'm writing this, I think the best thing to do is add a VirtualBoundary for the submerged fiber and not try to merge it with RadianceVirtualBoundary. I plan to proceed with this plan. I think we should rename RadianceVB to DosimetryVB though or something like that because it doesn't handle all internal surface radiance detectors, it is only capturing downward radiance.
from vts.
I have kind of gone full circle with this effort. First, I tried to code up a literal CylindricalFiberDetector that could be at the surface or submerged. This required an equivalent tissue addition of a CylinderTissueRegion that represented the fiber. I ran into problems with this code. Technically, all inclusions are assumed to be contained within the layer. This assumption and trying to get the surface fiber to work caused me to ditch this code.
So I restarted and reread David's last post. In terms of how our software is architected, I think his idea has merit and so I coded it up. I added a reflection detector SurfaceFiberDetector that attached to the DiffuseReflectance Virtual Boundary. This coded up very easily because of the structure we have in place. However, all detectors that hang off the ReflectanceVB are tallying because they escaped the surface after passing Fresnel comparison of tissue n with air n. I added a check in the new detector class to compare it's n with that of the tissue and called Fresnel to see if I should tally, but all of the prior pseudo-collisions that bounced off the surface due to the tissue/air n comparison could have tallied to the detector if they were under it.
This is what I did to remedy this. I made SurfaceFiberDetector a IHistoryDetector which attaches to a GenericVolume VB. The key difference with a IHistoryDetector is that it goes back through all of the photon collisions and tallies accordingly. This allowed me to retrace and see if any prior pseudo-collisions occurred at the surface and check if under detector and if so, Fresnel compare the tissue n with the detector n. If transmitted to the detector, I stop processing that photon.
I have written unit tests and stepped through the code. It behaves correctly. I plan to build an executable to test.
from vts.
The method I posted in the prior post did not work. After returning to my old C code and coding up what I thought was needed, I got results that agreed with theory. So to code up something similar in the C# code, I created a MultiLayerWithSurfaceFiberTissue class. This class is similar to MultiLayerTissue except that a circular Tissue region, SurfaceFiberTissueRegion, can be defined that exists at the surface of the tissue. Then I modified GetRegionIndex and GetNeightRegionIndex to check if the photon is at the surface within the circular region. The key interaction with Photon class is in CrossRegionOrReflect asking the tissue:
int neighborIndex = _tissue.GetNeighborRegionIndex(this);
double nNext = _tissue.Regions[neighborIndex].RegionOP.N;
I needed to have the N of the fiber to be nNext when crossing the surface under the fiber. This gave me results that were more in line with theory. I'll see if Owen finds that it works for his test cases or not.
from vts.
How did this go, ultimately?
from vts.
I feel this issue was closed when branch branch ch-141202-detector-NA-changes was merged into master.
from vts.
Related Issues (20)
- CI/CD - Github Actions to build Vts.sln and run Vts.Library.sln Tests upon PR submission
- Fix the SonarCloud issues in IForwardSover HOT 4
- Add ability to angle SurfaceFiberDetector
- Fix the 5 SonarCloud Bugs
- Fix bugs, security issues and maintenance issues in MCCL and MCPP
- Fix the bug in EllipsoidTissueRegion
- Reconfigure the detectors to use global code for the Binary Serializers HOT 65
- Fix the cognitive complexity issues from the Sonar Cloud analysis HOT 5
- Bug in 2 of the Detectors TransmittedMTOfXAndYAndSubregionHistDetector and ReflectedMTOfXAndYAndSubregionHistDetector HOT 2
- Preparation for the November release
- Vts Code and Scripting changes in preparation for Polyglot notebooks
- Add ability to use layered concentric infinite cylinders with refractive index mismatch HOT 2
- Move the FemModeling and MGRTE into a separate repository HOT 2
- Non-flat layered tissues for MCCL HOT 31
- Replace Moq with NSubstitute
- Add resiliency to CustomBinaryStreamWriterOfT HOT 1
- SDA forward solvers need check on optical properties to make sure solution is valid HOT 4
- .NET Polyglot Notebook and Jupyter Notebook samples HOT 17
- RangeOfT enhancements for simplicity to consumers HOT 8
- Publish static web hosted documentation to Github Pages
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vts.