Triangle Mesh size affecting results

[Aaron Nowack]

Hi!

I've been using Chroma extensively and have found it very useful, however I am running into an issue where the size of the triangles in my mesh directly affect my results in dramatic ways.

I have a single volume of scintillator with several PMTs facing inwards on one side (see reardet.png attached), on the opposite side is a surface with a reflective coating (front_det.png). I iterate throughout the volume and plot the number of photons received by each detector (red surface). pmt_MRF.png shows the number of photons received in the center PMT across events near the front face. Many features, notably discontinuities along the triangle edges on the front face area clearly visible.

I have tried many iterations of attempting to track down the issue. There is no warning or debug messages, chroma-cam renders my detector accurately, and I have verified that the triangles are all indeed the correct material and surface properties.

Is chroma designed in a way in which the accuracy of the results depend on size of the mesh? Can any of the developers expand on how if that is the case?

I greatly appreciate any response. Chroma is a useful tool, these simulations run 100x faster than my old detect2000 runs.

Thanks,
- Aaron

[Stanley Seibert]

Hi Aaron,

Chroma currently uses single precision arithmetic for speed reasons, so the most likely problems stem from that. If you have triangles which are more than 4 or 5 orders of magnitude smaller than the total size of your detector, the intersection code is likely to experience some round-off error. I've been considering how to best introduce a small amount of double precision to improve that accuracy, but haven't come to a definite conclusion yet. Another option is to enforce a maximum step size for photons, like I've seen used in other programs to control round-off.

I'm not sure I understand the interpretation of the attached pictures, though. Looking at pmt_MRF.PNG, what are the discontinuities I'm looking for? The hexagon pattern?

> --
> You received this message because you are subscribed to the Google Groups "chroma-sim" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chroma-sim+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> <front_det.PNG><reardet.PNG><pmt_MRF.PNG>

[Aaron Nowack]

I experimented with different meshing sizes, here's another example which is more clear

This shows a front face broken into smaller triangles, the result plot shows the number of photons seen in the middle detector over a plane near the reflective surface (inside scintillator). The histogram uses hexagonal binning. You can see contours outlining the edges between triangles, so some triangles reflect more light back towards the detector than others.

The size of the triangles are larger than the triangles in the detector, not several magnitudes smaller. So I'm not sure if  this could be a round-off error.

[Anthony LaTorre]

Are you just seeing the fact that your geometry is represented by triangles when in fact the real detector has a smooth surface?

Certainly the size of the triangles in the mesh will affect the simulation. If the triangles are large relative to the curvature of the actual object you will see the artifacts of the triangle approximation.

Am I misunderstanding what the problem is?

Tony

[Aaron Nowack]

Okay, I wasn't aware the triangle size affects the simulation in this way. I initially had the largest triangles possible (see attached) and my results initially looked pretty good so I had wrongly assumed how triangle size affects the simulation.

Hmm, okay. I had written an interface between google sketchup and chroma to import models, but I'll need a way to set the meshing size then.

Thanks for the clarification.

- Aaron

[Aaron Nowack]

Forgot to attach my example ^

[Stanley Seibert]

Yes, a triangle mesh can only approximate a curved surface, so the mesh resolution is an important consideration when creating a geometry.

I am curious about this interface between Google Sketchup and Chroma. Are you exporting STL files?

[Aaron Nowack]

The front surface isn't curved though, it is completely flat. When I set the front surface to have diffuse optical properties (reflect_diffuse = 0.96, absorb = 0.04), I get the behavior described. It must be that the accuracy of reflection depends on the triangle size which I did not think was the case.

I was using COLLADA files as they allow me to also export surface properties. My current setup lets me paint the detector (white, black, red, blue, etc.) and then in my collada -> chroma script I have presets on what black, red, blue etc. correspond to. So white was a diffuse surface, and black an absorber.

It wasn't quite that simple though, as I need to association each triangle with which solid is on the inside and outside. To do this I specified that in the texture name, so really a surface gets painted material named something like "blue and scintillator inside and air outside". It would be nice if I could clean this part, but I haven't figured it out.

This is the library I was using to interpret collada files, https://github.com/pycollada/pycollada

As I have just learned though, sketchup may not be usable since I cannot afaik control how the meshing is done. I'm looking into Blender and other modelling software that may let me do this.

- Aaron Nowack

[Anthony LaTorre]

Yeah, so whatever triangle mesh is spit out from Sketchup is exactly what is simulated, i.e. if you create a sphere and triangulate it somehow the simulation doesn't have any idea that it is trying to represent a sphere, it just knows about the triangles.

One nice thing though is that the way the bounding volume hierarchy is built, increasing the number of triangles shouldn't have a huge impact on speed. If I remember correctly, the speed of the simulation is roughly proportional to the log_3(# triangles) or something like that.

One thing we've noticed that you might want to keep in mind is that it is generally better if all of the triangles in the model are roughly the same size. If you have a patch of very large triangles right next to another patch with very small triangles, the bounding volume hierarchy cannot segment the geometry like it normally would and it will generally run slower.

[Stanley Seibert]

Hmm. Can you send me off list (st...@mtrr.org) the output of "hg summary" and a python script that implements your geometry? I'm curious if there is some bug lurking here.

I am intrigued by this use of COLLADA files to specify surface properties. If you are happy with the behavior of your importer and want to contribute it to Chroma, feel free to file a pull request. :)

[Aaron Nowack]

Okay, I can send you those files soon. My importer is a bit specific on this setup, but I can work on generalizing it.

Since the front detector plane is *not* a curved surface, I am also concerned whether a bug is present. However first I will recheck it is not due to my implementation.