virtualphotonics / vts Goto Github PK

The IForwardSolver interface is not correctly organized and as a result, it causes code issues. When this file is inherited these issues are duplicated in the new class.

Fix the organization in the main file and then in the classes that inherit IForwardSolver.

The pMC processing for two or more layers does not give correct results.

Is your feature request related to a problem? Please describe.
Currently only two dMC detectors (dMCdROfRhodMuaDetector and dMCdROfRhodMusDetector) are available. These detectors cannot be used in Time Resolved Reflectance simulations.

Describe the solution you'd like
We would like to have dMCdROfRhoAndTimedMuaDetector and dMCdROfRhoAndTimedMusDetector for Time Resolved Reflectance simulations.

In Vts/MonteCarlo/Tissues, the method GetDistanceToBoundary should determine the distance to the closest tissue region boundary using the photon current position and direction, independent of hitting it (not using photon.S, track length, but possibly using a projection of S).

The projected distance needs to be correct so that MonteCarloSimulation MoveToBoundaryCheck processes correctly.

Problem definitely occurs in MultiConcentricInclusionTissue but plan to check all other tissues.

MultiConcentricInfiniteCylinderTissue already exists, however does not currently allow for refractive index between layers and between outer cylinder and enclosing layer region. Comments in place in GetReflectedDirection and GetRefractedDirection to do this because trial code was coded before.

Describe the bug
Fix the bug in EllipsoidTissueRegion as per SonarCloud:
https://sonarcloud.io/project/issues?resolved=false&types=BUG&sinceLeakPeriod=true&id=VirtualPhotonics_VTS

Suggest we add a Gitter channel (https://gitter.im/). I've been following a few other Github OSS projects this way (such as this one https://github.com/cureos/csmpfit :)), and it's pretty effective.

When I tried using 'MieScattering' instead of 'PowerLaw' I am getting the following error. Could you please help me with the error?

Thanks,

Error using Vts.SpectralMapping.MieScatterer
No constructor 'Vts.SpectralMapping.MieScatterer' with matching signature found.

Error in VtsSpectroscopy.GetOP (line 43)
scattererNET = Vts.SpectralMapping.MieScatterer(...

Error in vts_solver_demo (line 111)
op = VtsSpectroscopy.GetOP(absorbers, scatterer, wv);

In the Desktop Vts project, the delete folder method appends the folder name twice and so the files cannot be deleted. This issue became apparent when we created the WPF application, before that, I'm not sure that this method was being used.

This issue will is a placeholder for the November release, once we have all the necessary features in master we will create a branch to update the version numbers and create the next VTS release.

We would like to complete the following prior to the release:
#121 - Vts Code and Scripting changes in preparation for Polyglot notebooks.
#115 - Bug fix in 2 of the detectors

The MC Post Processor (MCPP) infile specifies an InputFolder that designates where the database to be post-processed resides. The code was written so that the location of the InputFolder needs to reside within the MCCL download folder.

Add command line option "inpath" that would enable the user to overwrite the InputFolder and specify an absolute path. Note an "outpath" which specifies the location of the results of the MCPP already exists.

I am interested in running simulations in which an ellipsoid (or other tissue region) inclusion has a different refractive index than the surrounding tissue.

I have started a branch named ch-190214-tissue-inclusion-diff-n to begin making changes.

Discussed in #80

^{Originally posted by dcuccia August 3, 2023}
I was able to quickly validate that DocFx can create static website docs like this:

More info here, and here is how to build from GitHub Actions and host on GitHub Pages.

Is this something we could consider? Would be my personal preference for referencing docs, versus downloading a help file locally.

Repro of the steps I took to build and run locally are as follows:

1. Install DocFx as a global tool:

dotnet tool install -g docfx

3. Navigate to the VTS root code directory and initialize with "quiet" mode:

docfx init -q

4. Update the auto-generated docfx.json file with the following "src" subsection:

"src": [
        {
          "files": [
            "Vts/Vts.csproj",
            "Vts.MonteCarlo.CommandLineApplication/Vts.MonteCarlo.CommandLineApplication.csproj",
            "Vts.MonteCarlo.PostProcessor/Vts.MonteCarlo.PostProcessor.csproj"
          ],
          "src": "../src"
        }
      ],

5. Generate the metadata from the targeted Vts libraries:

docfx metadata docfx_project/docfx.json

6. Build the site and run the tool on localhost:8080:

docfx docfx_project\docfx.json --serve

I was recently contact from a student from Notre Dame interested in the frequency domain fluence solutions for the two-layer SDA solution on our Fluence/Interrogation Solver Panel. These options are currently greyed out because these solutions do not currently work or exist.

I would like to suggest that the student use a Monte Carlo solution instead, however we don't currently have Fluence(rho,z,ft) or Fluence(fx,z) implemented. I have reviewed my Monte Carlo lecture 5 at this years short course and the equations which describe taking the spatial- and temporal- Fourier transform of the RTE. What results is a transformed equation for radiance. Taking the integral of this equation over all angles would provide fluence. So I think I can use the modified short cut methods (Testorf, Gardner) to implement fluence solutions.

Any comments regarding this suggestion are welcome.

A Boston University user reports she has produced results in which the TallyCount of the ROfFx detector is larger than the number of photons launched, N.

When running a parameter sweep with values less than two decimal digits of accuracy, the output folder name is incorrectly named.
To reproduce run:
mc.exe infile=infile_one_layer_ROfRho_FluenceOfRhoAndZ.txt paramsweep=mus1,0.0001,0.0003,2
creates output folders named:
one_layer_ROfRho_FluenceOfRhoAndZ_mus1_0.00
for the two output folders rather than
one_layer_ROfRho_FluenceOfRhoAndZ_mus1_0.0001 and
one_layer_ROfRho_FluenceOfRhoAndZ_mus1_0.0003

In MC JSON simulation input files, a user has freedom to modify "mus", "musp" and "g" for each region. This leads to confusion because they value could not be consistent.

Is your feature request related to a problem? Please describe.
After the recent change to Moq to include SponsorLink, we should replace Moq with NSubstitute. We currently only use Moq in 12 files so it would be easy to replace now before we move forward with more unit testing.

Additional context
The issue on GitHub alerting to this feature:
moq/moq/issues/1372
Additional discussion on the topic:
moq/moq/issues/1374

Ran into this:

"R(fx) tallies assume a homogeneous or layered tissue geometry; Change tissue type to be homogeneous or layered"

Not true in the general case. Think this should be a warning, not an exception.

When running the MCPP with the "outpath" option, the results of the post-processor are not completely stored in the given outpath subfolder.

Describe the bug
The plot labels for CAW & DAW are reversed.

Application (MCCL, MATLAB or VTS code):
VTS (Vts.Scripting)

I added the VirtualPhotonics.VTS NuGet package, and wrote a .Net Core console test app to exercise the VTS.MonteCarloSimulation class:

using System;

namespace TestVts
{
    class Program
    {
        static void Main(string[] args)
        {
            RunASimpleMonteCarlo();
        }

        private static void RunASimpleMonteCarlo()
        {
            var input = new Vts.MonteCarlo.SimulationInput();

            var mc = new Vts.MonteCarlo.MonteCarloSimulation(input: input);

            var output = mc.Run();

            Console.Write($"Simulation results:" +
                $"\r\n\t{input.N} photons generated" +
                $"\r\n\t{output.R_r_TallyCount} photons detected");

            Console.ReadKey();
        }
    }
}

This works great. I then wanted to improve the VTS library, so I checked out the source code in a new repository, made some changes, built the project, and then referenced all .dll libraries in the following folder:

...\build\core\Desktop\Release

Repeating the execution, I get a runtime exception in LoggerFactory.cs:

Looks like the source code is using individual System.Reactive pieces (Core, Interfaces, Linq, PlatformServices), but the runtime expects the "full" System.Reactive. Removing the individual pieces, and instead adding System.Reactive 4.1.0 via NuGet, makes everything happy again.

I did a little digging, and discovered that we only copy 'Vts.Desktop' builds to the 'build' folder, but the netstandard 2.0 'Vts' libarary isn't copied. So, I was accidentally referencing "desktop" assets from a core project (which again, worked otherwise, just needed references updated).

I'd suggest two things:

1. Decide if the Vts.Desktop project is needed anymore. All desktop projects are on .Net 4.6.1 and thus netstandard 2.0 compliant. Is there a reason to keep? Desktop projects should be able to just reference the Vts library directly, and therefore work with Desktop, Core, Mono, Xamarin runtimes.

2. Figure out the story for packaging netstandard projects for re-use per my scenario above, where all I want to do is reference the compiled Vts.dll and start programming against it. I see that there's a Vts.deps.json file saved alongside the netstandard Vts.dll file. Presumably, referencing projects can reference this 'deps' file and have the tooling automatically pull in the necessary dependencies. Supporting this scenario will significantly improve other's ability to work with the API and make/suggest improvements, based on their specific use-cases.

Describe the bug
There are 5 bugs alerted by SonarCloud in the VTS:
https://sonarcloud.io/project/issues?resolved=false&types=BUG&id=VirtualPhotonics_VTS

Application (MCCL, MATLAB or VTS code):
VTS

Describe the bug
There are 120 issues on SonarCloud with high severity, most of these are cognitive complexity. This issue will address those particular code smells.

Application (MCCL, MATLAB or VTS code):
VTS

Additional context
https://sonarcloud.io/project/issues?impactSeverities=HIGH&resolved=false&types=CODE_SMELL&id=VirtualPhotonics_VTS

Using MCCL with paramsweepdelta=mus1,0.01,0.03,0.002
creates a DoubleRange Count value of 10 instead of 11 producing a Delta of 0.00222222...

Expected behavior is a Count value 11 which would produce a Delta of 0.002.

Hi all,

I'm working with water/intralipid and could really use some quick, accurate data for an n of ~1.33. I hear NURBS might be difficult to adapt for this, but perhaps scaled Monte Carlo is easy enough?

If I wanted to build this myself and simply swap out the current reference data, it looks like I could generate some new data in MCCL and change the "folder" variable in MonteCarloLoader.cs accordingly, or is there more to it than that?

Thanks,
Chris

Describe the bug
Fix the issues highlighted in SonarCloud:
https://sonarcloud.io/summary/overall?id=VirtualPhotonics_Vts.MonteCarlo

The Detectors section of MonteCarlo has a lot of duplicated code and every time we add another detector, the code is duplicated more. The Binary Serializers could be consolidated for the detectors so this would reduce the code duplication.

Article by Miguel de Icaza, pointing to new improvements in mono floating point speed. May require build flags to be added/changed: http://tirania.org/blog/archive/2018/Apr-11.html

This is a continuation ticket from #72, "Implement and test script-style use of the VTS", and originates from this Discussion: #70

Now that we have script-style C# files in Vts.Scripting which are compiled and tested alongside the rest of the VTS tools, we would now like to create initial .Net Polyglot Notebook and Jupyter Notebook implementations of these scripts. The goal is that the body of the Vts.Scripting scripts should be copy-pastable, but the helpers, library references, and "global" using statements can be handled in a header code block.

Notebooks will also allow us more flexibility to provide markdown-style formatted text in-between code blocks, so that we can be more expressive with a demonstration/walk-through, and to break up a computation into logical parts where useful. And example of this would be running creation of a photon database in one block, and then running desired post-processing in a separate block. Segregation helps in this case because the post-processing can be tweaked and augmented without having to re-run the initial simulation, and the variables and files generated with a photon database can be re-generated with a larger photon count, once the range of post-processing tasks is ironed out.

While the ultimate goal is to have the notebooks live in their own small, separate repositories, in order to flush-out the desired folder/file structure, and identify additional core Vts additions (or bug fixes) needed for making notebook use simple, we will start by adding a small set of prototype notebooks to the VTS project repository itself. These will reference a local Vts.dll library (required to be pre-built from within the Vts.dll project), as opposed to reference them from Nuget. This way, we can rapidly add any new functionality needed to make the look and feel of Vts use as "idiomatic" as possible from within the notebook tools and when used from non-C# languages such as Python (and it's constellation of tools like NumPy, SciPy, etc). For example, this may motivate new array indexing styles and multi-dimensional array helpers like Span2D, adoption of libraries such as NumPy.NET, NumSharp and NumSharp.Bitmap.

Finally, per here we'll re-organize the root 'Matlab' folder into a sub-folder called examples, so that we can have a range of demos of framework use, including scripting/Matlab, scripting/Python, scripting/CSharp (Polyglot Notebooks), maybe even scripting/JavaScript. :)

Following the scatterer.type='Intralipid' example in GetOP_help.m doesn't work. VtsSpectroscopy requires an additional field, "scatterer.VolumeFraction" in addition to "scatterer.vol_frac" to work correctly.

Application:
VTS Matlab v4.5.0 Beta

To Reproduce:
Use the code below. It produces a figure with three distinct scattering curves, as expected.
Comment out only the "scatterer.VolumeFraction" line and get an error.
Comment out only the "scatterer.vol_frac" line and get three identical scattering curves, indicating the default volume fraction is being used.

clear
absorbers.Names = {'HbO2', 'Hb', 'H2O'};
absorbers.Concentrations =  [70, 30, 0.8];
wv = 650:0.5:1000;

scatterer.Type = 'Intralipid';

for i = 1:3
    scatterer.VolumeFraction = 0.006+.002*i;
    scatterer.vol_frac = 0.006+.002*i;
    
    op(:,:,i) = VtsSpectroscopy.GetOP(absorbers, scatterer, wv);
end

figure
hold on
for i = 1:3
    plot(wv,op(:,2,i))
end
xlabel('Wavelength (nm)')
ylabel('\mu_S''')

Expected Behavior:
GetOP_help.m lists only the vol_frac field. VolumeFraction should not be required. or vice-versa

Hi friends!

On my fork, main branch, I've updated projects and references to be fully .Net Core 3.0/.Net Standard 2.0 compatible (it's up to date with the main project), and I've verified "dotnet run" for the mc.exe command line app now works out of the box on a vanilla Ubuntu distro (on WSL). This means (theoretically) we shouldn't need Mono, or any Linux-specific work-arounds. Also, between VS Code and VS for Mac, I don't think we should need to support MonoDevelop anymore.

I almost submitted a PR, but held back because there are multiple deployment assets that need to be updated or deleted. Very willing to do more work on this, but wanted to run by you guys. I've set the nuget package to 5.0.0-alpha01 (I don't have permissions to publish), and I've verified that a linux command line project referencing that alpha also works.

Let me know if you'd like to chat about it,
David

SDA solutions are only valid when mus'>>mua. This check is not currently performed in these solvers and lead to erroneous results.

The forward solvers that require this check are:
DistributedGaussianSourceSDAForwardSolver, DistributedPointSourceSDAForwardSolver, PointSourceSDAForwardSolver, TwoLayerSDAForwardSolver and possibly SFDDiffusionForwardSolver.

To reproduce this error define mua=1, mus'=1 as optical properties in TwoLayerSDAForwardSolver and view FluenceOfRhoAndZ method results.

Code should be added to throw an ArgumentException after checking optical properties for case of mua==musp. This is the extreme lower bound for mus'/mua. It is difficult to know a higher lower bound that would invalidate each SDA solution.

Not sure, but I think this is an issue related to test framework tooling. A large number of tests in Vts.Desktop.Test (perhaps those that rely on serialization?) are failing when I use the built-in test framework of Visual Studio 2017 (15.8.1) Pro on Windows 10 Pro x64. This is on a new checkout of the repo, nothing special. See attached image:

When I run the batch file (DesktopTests.bat) from the command-line, everything's hunky dory. Here's the XML data:

testcasecount="467" result="Skipped" label="Ignored" total="467" passed="444" failed="0" inconclusive="0" skipped="23" asserts="1537460" engine-version="3.8.0.0" clr-version="4.0.30319.42000"

Perhaps there's a difference in how VS Test Explorer deals with sandboxing and file artifacts? I was pretty sure this is still using NUnit under the hood, but I could be wrong. Not sure what to do next, so posting to see if anyone else has tried this and had problems.

Is your feature request related to a problem? Please describe.
For some studies or analyses, certain tissues cannot be assumed as flat layers. For example, skin cannot be assumed to be flat if large source-detector separations are considered. Instead of using a mesh-based Monte Carlo model, I want to see if MCCL can have concave or convex surfaces.

Describe the solution you'd like
I would like to see the possibility of using the existing "MultiConcentricInfiniteCylinder" tissue to get convex and concave tissues (See Figure). To do this, the virtual boundaries should be defined at the inner and outer cylindrical surfaces of a hollow cylinder. Such implementation will allow detectors to capture the photons exiting from the cylinder. We can consider that all detectors are normal to the surface.

Describe alternatives you've considered
Defining all layer boundaries by analytical equations.

Discussed in #87

Hi
I want to download a "IAD_simulated_data_GUI", but the link does not exist. Where can I find this software or its link to get it.
Looking forward to hearing from you
Thanks a lot

Due to a request from a student from Notre Dame, I'm trying to get the Fluence(rho,z,ft) working for the two-layer SDA solution. The bones are there and I would like to see current results. To view the map, additional code is needed:

1. ForwardSolverBase and IForwardSolver need an overload of FluenceOfRhoAndZAndFt which takes in IOpticalPropertyRegion[] (instead of OpticalProperties).
2. TwoLayerSDAForwardSolver needs an overload for this method that actually implements generation of result. TwoLayerSDAForwardSolver does not inherit DiffusionForwardSolverBase (it inherits only ForwardSolverBase) which houses homogeneous versions of methods such as FluenceOfRhoAndZAndFt.
3. ComputationalFactory GetForwardFluenceFuncComplex needs code to handle special case when forward solver is TwoLayerSDAForwardSolver.

This appears to be giving reasonable results. It takes a little bit to run, however, it you make the rho and z grid less fine, it runs fairly fast (30x30 rather than 300x300). I plan to commit the Vts changes, but not push yet. I won't enable Fluence(rho,z,ft) for the two-layer SDA in the GUI yet.

Please let me know if you think my code implementation needs modification or if you have questions about what I did. Thanks.

Would like the ability to angle a surface fiber detector. The fiber end would be considered circular and adjacent to the tissue. Use with MultiLayerWithSurfaceFiberTissue would be implemented so that a circular patch with n matching that of the fiber would be underneath the fiber and allow transport of photons below patch to enter fiber.

Two years ago we moved the MGRTE code out of the VTS and into a separate library because it was not being used in any of our software, we put a note in the release notes in case it was being used externally to notify users that we could create a separate NuGet package. It seems that this code is not being used.

This issue is to move out the Vts.FemModeling code and the MGRTE console application from the main VTS repo and put it in a separate repository. @janakarana let us know if you foresee any issues with us making this change.

I'm trying to use VTS to generate some reflectance data in Matlab, but forward-modeled reflectance is way off when using the basic MC solver. Have I made an incorrect assumption?

To reproduce:
VTS_MATLAB_v4.3.0Beta
Matlab R2017b:

clear
startup

% Generate spectra
rho = 22;
wv = 600:1000;
absorbers.Names =           {'HbO2', 'Hb', 'H2O', 'Fat', 'Melanin'};
absorbers.Concentrations = [ 28.4, 22.4, 0.7, 0, 0.0051 ];
scatterer.Type = 'Intralipid';
scatterer.VolumeFraction = 0.01;
op = VtsSpectroscopy.GetOP(absorbers, scatterer, wv);

% Forward model reflectance with three models
VtsSolvers.SetSolverType('PointSourceSDA');
R_sda = VtsSolvers.ROfRho(op, rho);

VtsSolvers.SetSolverType('MonteCarlo');
R_basic = VtsSolvers.ROfRho(op, rho);

VtsSolvers.SetSolverType('Nurbs');
R_nurbs = VtsSolvers.ROfRho(op, rho);

% plot (log scale to keep all spectra visible)
figure
subplot(1,2,1)
plot(wv,op(:,1))
xlabel('Wavelength (nm)')
title('\mu_A (mm^{-1}')

subplot(1,2,2)
plot(wv,(op(:,2)))
xlabel('Wavelength (nm)')
title('\mu_S'' (mm^{-1}')

figure;semilogy(wv,R_sda,wv,R_basic,wv,R_nurbs)
xlabel('Wavelength')
title('Forward Reflectance')
legend('SDA','MC Basic','Nurbs','Location','Best')

Discussed in #70

Main Idea

In order to lay the groundwork for future Jupyter Notebook and .NET Polyglot Notebook sample code, as envisioned in #70, this ticket is to create sample C# "scripts" (top-level statements) that mimic the existing VTS Matlab scripts. In addition to unblocking the future work, at the end of this, anyone more comfortable working out of the VS or VS Code IDE should be able to use these scripts directly for their work if they desire.

Details

Design details:

1. Create these in a new project within the main Vts solution, with project name & namespace Vts.Scripting. This will ensure building the solution catches any build-level regressions to the scripts that might occur when the VTS library changes.
2. Use C# top-level statements combined with SmallSharp for simplifying running each script independently.
3. Make the code as "distraction free" as possible, removing as much unhelpful boilerplate code as possible, as these will be mirrored in other toolchains and languages.
4. Scripts will directly reference the Vts.csproj project within the Vts solution, to facilitate full use of the tools for design-time compilation error checking and debugging. This will differ from the future "external" Notebooks, which will resolve Vts.dll from Nuget.
5. Add a Vts.Scripting.Test project to cover the new script samples to catch/flag any runtime issues/bugs that will necessarily need updates to the libraries in the other repos

Acceptance Criteria

• Project should run "out of the box" with either VS or VS Code, requiring only a recently released version of .NET installed
• Should not require "classic" .NET Framework installed to run
• Should not concern the user with unnecessary details (e.g. throw logging errors, etc).
• Test project should successfully execute each script without errors

Describe the bug
In the file ParallelMonteCarloSimulation.cs 'listOfMeans.FirstOrDefault()' is null on at least one execution path. There are 24 instances of this bug identified by SonarCloud in this file.

Application (VTS code):

To Reproduce
The link to the issues is here:
https://sonarcloud.io/project/issues?resolved=false&types=BUG&id=VirtualPhotonics_VTS&open=AYmYDtRnMpwhnU9-85fg

Expected behavior
Avoid the code throwing a NullReferenceException unexpectedly.

Additional context
The resolution and why this is an issue is detailed on SonarCloud at the link above.

I would like to explore how we might modify the code so that individual batches of photons can be executed on different processors then added back together for a final tally. I've been reading this:
https://www.codeproject.com/Articles/767997/Parallelised-Monte-Carlo-Algorithms-sharp
under the section "C# Threadpool" as a possible model to follow.

Currently, if the "results" folder is not written ahead of time, PhotonDatabaseWriter will throw an exception when attempting to write to a file within the specified folder. When consuming the Vts library, it is not obvious that this folder must exist before a simulation is run, and leads to exceptions that a consumer of the library should not have to debug/fix.

In order to fix this, add the following guard to the top of CustomBinaryStreamWriter<T>.OpenStream():

try
{
    // guard against directory not existing ahead of time
    var directory = Path.GetDirectoryName(_filename);
    if (!Directory.Exists(directory))
    {
        Directory.CreateDirectory(directory);
    }
    ...
}

We would like to remove the support for .NET Standard 2.0 as it is no longer required for the MATLAB interoperability or the WPF application. The WPF application is now on a Windows version of .NET 6.0.

This will improve the running of unit tests, currently because we target .NET Standard and .NET 6.0 we have unit tests targeting .NET Framework 4.8 and .NET 6.0 so there are twice as many unit tests then we need.

This change will also allow us to move forward with the C# version we are using and we will be able to modernize our code to C# version 10.

This was discussed in #81 and is rearing it's head as I try to make the Notbooks simple and refactor commonly used code/extensions to the Vts core.

double[] endpoints = myRange.ToArray();
List<double> endpoints = myRange.ToList();
foreach(double endpoint in myRange) { //... }

Goal: to enable defining:
(a) detector NA capabilities in our current detectors, and
(b) a fiber detector with a index of refraction, n, and numerical aperture, NA, adjacent to the tissue. That is, change the tissue-air interface in the location of the detector to determine reflection and refraction based on the n of the detector. This is the first time a detector definition would modify the photon transport in the tissue.

Proposed solution: after reviewing the code classes and trying not to mangle classes, I came up with a plan. Tissue typically has no information about detectors, however, to modify transport, tissue needs to know that a detector is there instead of air. So if a fiber detector is defined, tissue would have a infinitesimally thin TissueRegion at the tissue-air interface under the detector that has different OPs.

I wrote out specs for the code. Please feel free to challenge any one of them.

Specs:

1. Add a ReflectanceFiberDetector and TransmittanceFiberDetector that has parameters:
   a) center
   b) radius
   c) refractive index
   d) NA
   These detectors would be the only detectors that modify the photon transport along the tissue-air surface. The rest of the resident detectors would assume a consistent tissue-air interface.

2. For the resident detectors enable a NA parameter but assume detection is always in the air. This would mean users would specify NA of detector relative to n=1.0. I came to this conclusion because it wouldn't make sense for say ROfRho (or all of the rest of the resident detectors) to be adjacent to the tissue since then the entire tissue surface would interface with the n of the detector and that didn't make sense to me.

3. Currently Photon class CrossRegionOrReflect method asks the tissue to provide the current n and the neighbor region index (index within the array of regions). This method then determines the n of the neighbor region. To do this, tissue checks the layers in MultiLayerTissue or the inclusion in SingleInclusionTissue to determine the neighbor index.

Proposal: If ReflectanceFiberDetector of TransmittanceFiberDetector are defined, also modify TissueInput to define a infinitesimally thin DetectorRegion that has center, radius, n and NA. Then when CrossRegionOrReflect asks tissue for the neighbor index, tissue will know the index of the DetectorRegion and Photon can then know the n of that region. No change to Photon class would be needed.

The DetectorRegion would be handled internal to the code when an infile specifies a ReflectanceFiberDetector. It would have dimensions based on the user input for this detector.

Describe the bug
While looking though the serialization code to research the reconfiguration, I discovered a bug in two of the detectors. This could result in the wrong information being serialized or it could cause an exception if the data does not align.

Application (MCCL, MATLAB or VTS code):
VTS Code

Bug Locations
VTS\src\Vts\MonteCarlo\Detectors
File: TransmittedMTOfXAndYAndSubregionHistDetector.cs at line 342, this value should be Y
File: ReflectedMTOfXAndYAndSubregionHistDetector.cs at line 345, this value should be Y

Additional context
This should be fixed as a hotfix before the next release because it could produce unexpected results.

We want to make the VTS code changes before the November release so the notebooks can pull the VTS library from NuGet. The notebooks need more work so we have separated into a separate issue so we can get the VTS code updated.