jtramm
string names of surface properties
Awesome package, many thanks for making it public. I'm playing with the examples, and everything works. One minor comment: "transmission" and "vacuum" are nouns, while "reflective" is an adjective. It would be more intuitive if they were all adjectives.
What's the difference between vacuum and transmission? Are you planning to add partial transmission?
Glad you like the package, and hope you find it useful!
I originally chose the BC string names for consistency with a Fortran monte carlo program that does ray tracing in it (OpenMC): https://mit-crpg.github.io/openmc/usersguide/input.html#surface-element
I definitely agree though that the labeling does not make a lot of sense - so I will plan on adding in the ability to define the BC as "reflection" to be more consistent with the others and will change the docs/examples (though will still leave option the option to define it as "reflective" so as to not break existing code). I'll put this in whenever I put out the next minor patch. Thanks for bringing this up!
There is no difference between vacuum and transmission from the package's standpoint, though the application developer may find it useful to have the package keep track of this. As the package exposes which boundary type is encountered at each intersection:
new_ray, id, boundary_type = find_intersection(ray, geometry)
the app developer can use that info to impose some physics that depends on transmission/reflection/vacuum. For instance, one common use case might be to use the vacuum condition to define the outer most surfaces of the geometry so that ray tracing is terminated when a vacuum condition is hit.
Nice, didn't know about OpenMC, thanks for the link. I know it can be a pain to maintain the symmetry with an existing package.
I was wondering about find_intersection, though. Conceptually, I would have thought I'd get the boundary_type directly from plane[id], not from the intersection method. It seems a bit wasteful to always return the strings, but I've not timed it, so maybe the compiler already optimizes this properly, so this may be a moot point. Certainly, I'm not aware of slowdowns because of it, so feel free to ignore.
Anyway, love the package. Using it for some toy studies for a particle physics detector.