Requirements around depicting dose rainbow colours in egs_view

[nexustowers]

In the past I have had great success depicting colour dose maps for EGS_XYZGEOMETRY structures in egs_view using the 3ddose functionality. I have noticed though that the colour range doesn't seem to autonormalize to the range of doses in the input file, I have had to present doses in the region of e-13 or e-14 or so to see the full range of colours. 3ddose files with doses less than these tend to be represented as several shades of blue.
My latest simulation is generating region doses in a XYZ structure of between e-18 and e-20 and these are appearing in egs_view as blue. I have increased the doses to e-13 to e-15 or so by using the normalize facility in the dose scoring ausgab object, and despite the voxel doses now appearing as e-13 or so in egs_view they still appear as blue.
What are the requirements to visualise a full spectrum of colours in egs_view?

I am using egs_chamber in the 2025 release.

[rtownson]

Are there large uncertainties in the dose? Sometimes a single region with a large uncertainty can result a single hot spot voxel, that is then reported as the dose maximum and used for normalization. Scaling all the doses will then also scale that single hot spot proportionately, thus not solving the issue.

For your reference, here's the bit of code in egs++/view/viewcontrol.cpp that controls the normalization:

    EGS_Float dmin=1e10, dmax=0.;
    for (int j=0; j<g->regions(); ++j) {
        if (rp.score.count(j)) {
            if (rp.score[j] < dmin) {
                dmin = rp.score[j];
            }
            else if (rp.score[j] > dmax) {
                dmax = rp.score[j];
            }
        }
    }

    // Calculate the colors
    if (dmax > 0.) {
        for (int i=0; i<g->regions(); ++i) {
            if (rp.score.count(i)) {
                EGS_Float scoreNorm = (rp.score[i] - dmin) / (dmax - dmin);
                rp.scoreColor[i] = getHeatMapColor(scoreNorm);
            }
        }
    }

If you have qt5 installed and can compile egs_view, you could consider adding some debugging lines, or zeroing the first maximum you find and searching again for the second largest, etc.

Alternatively, try using VICTORIA:
http://web.uvic.ca/~bazalova/dose_viewer/

[nexustowers]

Thank you for replying and for your suggestions. I am glad to learn the colour palette autoranges.

I took onboard your suggestion about a hot pixel causing an unrepresentative normalisation, and so went hunting and did indeed find pixels with abnormal dose, with egs_view showing the dose as INF (infinity?).

I am modelling the dose to the walls of a radiotherapy bunker due the primary beam and scatter, and my geometry is really simple with a concrete frame and vacuum inside. The source is a linac manufacturer provided phase space. The pixels marked as INF always seem to be in the vacuum. The walls and interior of the bunker are constructed using a XYZ geometry and the floor and ceiling are made from box and prism objects. The completed bunker is a union of the components and none touch each other, as per the requirements.

I've spent the last week investigating and trying different things like removing electrons from the beam, but am still getting INF voxels in the vacuum. A peculiar thing I've found is that if I use a low number of particles, eg 1e5, then the colour palette looks fairly as expected (but still no red, which may not be unexpected given the highish uncertainty for this number of particles), but if I use a high number of particles, eg 1e9, then it's completely blue and I also see the INF voxels. I don't seem to get any INF voxels if I use a low number of particles.

I include some pictures
(1) 1e5 particles showing nice rainbow effect
(2) 1e9 particles, no rainbow, all blue
(3) 1e9 particles, close up of primary barrier. You can see an INF dose voxel in black in the vacuum adjacent to the concrete towards the lower edge of the beam.

Thanks for reading this far and, as always, much appreciate any input you may have.

[rtownson]

Thanks for the explanation. The INF dose values are of course because vacuum has zero mass, so there's a division by zero happening to convert the energy deposited to dose. For a quick fix, just do a search replace of "inf" in your 3ddose file and replace it with 0. I will consider adding a guard against infinite dose into egs_view, though we should also likely adjust the dose output to always output zero in vacuum regions.

[nexustowers]

Thanks for getting back to me once again. Yes, I suspected the INF doses were due to divide-by-zero errors but I got wrapped up in trying to figure out (a) why I was getting them, since there shouldn't be any dose deposited in a vacuum, and (b) why I was only getting them with high particle counts? I also know the 3ddose dose files are text files, and last week tried opening one in the linux text editor that I use (xed) but it kept crashing so I gave up on that route. Your suggestion to search and replace caused me to think of other options and I tried Windows Notepad which opened them up without any problem, so I replaced all the occurrences of INF as you suggested (there were quite a few) and hey presto the 3ddose file opens in egs_view with the full colour palette showing.
Thanks again for all your invaluable help and I have learned some more about the inner workings of EGSnrc which is always good. My final results are below. In case anyone's wondering you don't see a build-up region in the wall because the voxel size is too coarse at 5cm.

[rtownson]

By the way, I believe the non-zero dose in vacuum will be fixed when we merge in this PR: #1144