clrp-code / egs_brachy Goto Github PK

A transformed XYZ geometry becomes type EGS_XYZGeometryT (note added 'T'), so it does not fall within the default supported geometry types for the phantom. No 3ddose files will be generated and the user is required to provide the individual voxel volumes.

However, I think transformed XYZ geometries should be supported the same as the non-transformed one. As far as I know, the getMass / getVolume methods are available in the transformed geometry, thus there should be no reason not to output 3ddose files.

I need to test this to confirm.

See report here. Unfortunately, I have no access to Windows 10 to investigate this.

Anecdotally, the EGSnrc repo had a couple of issues related to the mingw compiler and what I vaguely remember is that its trouble-prone. : /

In material.dat, the AIR_PHANT material is missing the gas pressure input value (1.0). There also is a trailing comma in the list of elements.

Both of those cause the simulation to abort during initialization.

A user recently reported issues with their density correction files that they tracked down to be egs_brachy specific. In order to add their own density correction files they had to place them in the HEN_HOUSE (usually they should go in egs_home) and follow a stricter file format.

Here are their conclusions:

In order to get it working, we needed to fix several things. First of all, the density correction files need to be in:

EGSnrc_with_egs_brachy/HEN_HOUSE/pegs4/density_corrections

Placing them in egs_home/pegs4/density did not resolve the issue.

Secondly, egs_brachy is sensitive to spaces/tabs in the second line of the density correction files.
While regular XYZ geometry simulations are flexible to space/tabs, it is not the case for egs_brachy.
There should be 7, 3,7,14-16 spaces between
numberOfEnergies meanIonizationEnergy density numberOfElements

NO TABS!

After this everything seems to work fine.

Commit 892f1b0 shifted the volume correction to be performed at the end of the simulation initialization (so that getMass() calls know material density), which may have had an impact on timing. Further investigation is required.

Clicking on the link for egs_brachy_technical_manual.pdf uploads a 2.7 kB blank file.

Some numbers (e.g., number steps taken in the simulation) are not output to egsdat during the simulation, so for a restarted simulation, the numbers reported are incorrect since they only take the fresh histories into account.

From @dworogers:

I am looking at 0.01% effects and so have hacked the code to print out
some more sig figs on the dose I am looking at. Specifically, at line 474
in phantom.cpp
/* "%7d %5d %11.3E(%8.3E) %13.3E +/- %5.2f%% %13.3E +/- %5.2f%%\n", */
"%7d %5d %11.3E(%8.3E) %12.4E +/- %6.3f%% %12.4E +/- %6.3f%%\n",
This lines up properly but gives excessive decimal places for most
runs. The ideal solution would be to use the original format for
uncertainties greater than some cutoff (say 0.1% ?) and the latter for
higher accuracy runs

A few issues with make docs:

• .DS_Store files get mistaken for directories on macOS
• Image extensions is hardcoded as ".png", but source geometry images use PNG
• Docs are generated within /egs_brachy/docs, so images are linked using the relative path "../lib/geometry/sources/etc.", but the /egs_brachy/docs folder gets moved to /docs, so all image links break.

Parallel job submission does not work when using gzip egsdat files. Best guess so far: there's some authentication that happens when they are generated that creates issues because the file names end with egsdat.gz instead of egsdat...

Needs further investigation, recommend using the normal egsdat text format for now.

This line fails on Windows because it assumes Unix-style path separators. It should use os.path.sep instead.

This line also fails because it is looking for a .so object, but it should be .dll on Windows. Also, on Windows, there is no "lib" prefix on the DLLs.

Working on a fix now.

The initialization of DEFAULT_RAND_POINT_DENSITY (in volcor.h an eb_volcor.h) causes some compilers to throw an error (complaining about in-class initialization of constant non-integer variable... or something like that). The error can be suppressed by passing the compiler the -fpermissive flag.

Any workaround we can implement?

on initial configuration, egs_internal_source is not compiling into c++ library. Shows error 2.
egs_internal_source error 2.txt

egs_brachy running in "normal" mode will run with seeds that overlap - shouldn't happen in this run mode because is unphysical. Add check in geometry initialization (perhaps during region discovery) for source geometries that overlap? Throw warning? Or stop?

The offending code for normalizing dose to phantom I found here:
https://github.com/clrp-code/egs_brachy/blob/main/egs_brachy/phantom.cpp#L349

Since sources return their own fluence for normalization (which most cases is just the number of histories), you should use that as the normalization factor instead. See here:
https://github.com/nrc-cnrc/EGSnrc/blob/master/HEN_HOUSE/egs%2B%2B/ausgab_objects/egs_dose_scoring/egs_dose_scoring.cpp#L313

I believe this will only cause problems for egs_collimated_source.

The Makefile may need some tweaking to work properly on Windows. Will update with more details later.

823fd5c was based on the 2021 release of EGSnrc, not on the most current changes in develop. There have been some changes and fixes since then, so the egs_brachy specific version of the URCO needs to be updated accordingly.

This issue may also be more relevant to our fork of EGSnrc...

On Unix-like systems, we've modified the finalize_egs_foruser script to go one level deeper into user_codes/egs_brachy/egs_brachy to copy all files to egs_home/egs_brachy.

On Windows, the configure GUI only copies user_codes/egs_brachy to egs_home, so that we end up with an extra level (i.e., egs_home/egs_brachy/egs_brachy) instead.

Not sure how best to resolve (other than copying the files manually, of course).

I'm not sure about this, but it looks like in a parallel run, the number of geometry errors reported in the egslog of the combined run is simply the number of geometry errors encountered in the last partial job that was combined. Is there any way to add the geometry errors of all parallel jobs together and report those in the combined egslog? The parallel run control of the code confuses me, so I can't even tell what it's doing right now.

nrc-cnrc/EGSnrc#633 added support for 95 materials in ctcreate, and this implementation differs from the expanded number of materials handled by egs_glib (a hard coded list of characters). This results in egs_brachy egs_view crashing when loading an egsphant with >9 materials (and unknown behaviour when running a simulation).

At line 209 in egs_glib.cpp you can replace the for loop with something like this, as a fix:

    for (int i=1; i <= nmed; i++) { // Note the index from 1 so that 0 is reserved for vacuum
        string med;
        data >> med;
        char med_key = char(((i + 16) % 95) + 32);
        phant2egs_idx[med_key] = EGS_BaseGeometry::addMedium(med);
        phant2egs[med_key] = med;
    }

Eventually I expect all egsphant handling should be done in egs_xyzgeometry, but for now this is a quick fix.

Here's the actual list I changes I suggest:

diff --git a/HEN_HOUSE/egs++/geometry/egs_glib/egs_glib.cpp b/HEN_HOUSE/egs++/geometry/egs_glib/egs_glib.cpp
index 31240c0..13c50ee 100644
--- a/HEN_HOUSE/egs++/geometry/egs_glib/egs_glib.cpp
+++ b/HEN_HOUSE/egs++/geometry/egs_glib/egs_glib.cpp
@@ -206,11 +206,10 @@ EGS_BaseGeometry *readEGSPhant(istream &data, map<string, EGS_Float> med_rhos) {
     // read in media names and create map from phant medium code character to egs++ name
     map<char, string> phant2egs;
     map<char, int> phant2egs_idx;
-    string phant_meds_str = "123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
-    for (int i=0; i < nmed; i++) {
+    for (int i=1; i <= nmed; i++) { // Note the index from 1 so that 0 is reserved for vacuum
         string med;
         data >> med;
-        char med_key = phant_meds_str.at(i);
+        char med_key = char(((i + 16) % 95) + 32);
         phant2egs_idx[med_key] = EGS_BaseGeometry::addMedium(med);
         phant2egs[med_key] = med;
     }

I am new to EGS and seeking assistance with installing EGS_brachy on my Windows 10 system to conduct simulations in brachytherapy. While following the EGS_brachy manual, I encountered an error during the configuration of EGSnrc using the configuration shell script (./HEN_House/scripts/configure). Despite following the provided instructions and attempting to adjust the GCC version, the compilation of egs_c_utils.c and egs_c_utils.h failed. And it gave me this recommandations:
Creating egs_c_utils.h and egs_c_utils.c ... OK
Compiling egs_c_utils.c ... Failed

Failed to compile egs_c_utils.c. This may be due to a variety of reasons
(e.g., non-standard include files, unsupported file lock operations, etc.
Will disable now the availability of a C compiler.
If you want to try to make the new parallel processing implementation in
cavrznrc and dosrznrc work,

1. Go to /c/EGSnrc_CLRP/HEN_HOUSE/lib/mingw64_nt-10.0-19045
2. Edit egs_c_utils.h and egs_c_utils.c to make them compile with your
   C compiler
3. Put
   REPLACE {$HAVE_C_COMPILER(#);} WITH {{EMIT;{P1}define HAVE_C_COMPILER};}
   in machine.macros
4. Put
   $HAVE_C_COMPILER(#);
   near the beginning of your user-code.
5. If your compiler requires some unusual options, include directives, etc.,
   change the variable C_FLAGS in the spec file mingw64_nt-10.0-19045.conf in the
   /c/EGSnrc_CLRP/HEN_HOUSE/specs/ directory.
   I would greatly appreciate any guidance or suggestions to resolve this persistent issue.
   the.error.msg.txt
   configure.txt

When importing values from low_energy_default, there is an error on bremsstrahlung correction that reads:

INPUT-->NRC <--NOT ALLOWED
OPTIONS ARE:
KM
NRC
NONE

Need to fix the one about energy fluence in region.

The total radiant energy used to normalize the 3ddose files when scoring primary and scatter-separated doses is not reported anywhere. It should be reported in egslog.

I want to score Dmm and Dwm for a prostate permanent implant. The geometry mainly consists of a egsphant file generated using ctcreate from DICOM images of a prostate implant. It has body tissues (supplied in ramp file) as media and 57 number of 125I sources are embedded in it. I tried to run the simulation and score Dmm and Dwm using tracklength estimator. The run finished with no errors. However, Got score for Dmm but zero values for Dwm in all the voxels. I have noticed that if the material (water in this case) is not a part of the geometry, the scoring is not done.

As per my understanding, for scoring Dwm the radiation transport is being carried out in CT anatomy but dose to water is scored. I believe my scores using tracklenth estimator should not be limited to the media present in the geometry since the muen/rho data supplied should be able to take care of this. Else how to estimate different scoring options as suggested by TG186.

I scored using energy deposition estimator as well. There i believe dose is deposited in actual voxel media we have no option of scoring Dwm. I got identical Dmm and Dwm values. ### Please help me to understand the difference of these two estimators which have same units i.e Gy/history.

Issue comes from this line. When an egsphant has more than 10 media, the media keys go to letters ('A', 'B', 'C', etc.) and not to numbers ('10', '11', etc.).

Hello
After completing a simulation for smaller no. of histories, would like to restart the run for larger no. of histories as used to do in other user codes (ex: dosrznrc)

As defined in technical manual of egs_brachy i have added
calculation = restart in run control

It seem it does find the .egsdat file. However it is available in dir egs_brachy.
i am getting the following error:
EGS_Application::readData: failed to open /home/mcarlo/egs/EGSnrc/egs_home/egs_brachy/egsrun_26882_Ir192_Varisource_2000_TG43_mcarlo/Ir192_Varisource_2000_TG43.egsdat for writing
EGS_Application::runSimulation(): failed to start the simulation

egs_brachy output failed in initial compiling on configure, along with mird. When attempting to make specifically on egs_brachy, i encounter the attached error.

egs_brachy make error.txt

I need to investigate if the following behavior is a bug:

• Switched auto-envelope with transformed sources
• Region discovery set to "region discovery"
• Source volume correction set to "none"

This supposedly results in EGS_AEnvelope reporting failing "to find any region with inscribed geometries" and is resolved by setting source volume correction "correct".

Off the top of my head, I'm not sure if this is expected or unexpected behavior.

Should be replaced by this.

Disable scoring scatter dose if any of those conditions are met:

• More than one source is being simulated
• Phase space source is used
• Recycling is used

The following commit 823fd5c causes compilation to fail on Windows.

I'll update this issue with the exact error message, but it involves the EB_UniformRunControl class and dllimport.

See: nrc-cnrc/EGSnrc#720

I think this just means we will need to update the getUncorrectedVolume function here: https://github.com/clrp-code/egs_brachy/blob/egs_brachy_2020/egs_brachy/phantom.cpp#L302