Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in fluence when transformed sources used in source collection #1065

Open
4 tasks done
blakewalters opened this issue Oct 2, 2023 · 0 comments · May be fixed by #1076
Open
4 tasks done

Error in fluence when transformed sources used in source collection #1065

blakewalters opened this issue Oct 2, 2023 · 0 comments · May be fixed by #1076
Assignees
Labels
Milestone

Comments

@blakewalters
Copy link
Contributor

blakewalters commented Oct 2, 2023

Describe the bug
If a source collection includes multiple transformations of the same base source, then, when determining the fluence for the source collection, the fluence for each transformed source, regardless of source's weight in the collection, ends up being equal to the total fluence for all of the transformed sources. Thus, you end up with an erroneously high fluence for the source collection. This is due to the fact that getFluence in a transformed source calls getFluence of the base source, so every particle used from the base source ends up counting towards the fluence of every transformed source (using the same base source) in the collection.

To Reproduce
The following simple code (using 521icru.pegs4dat) reproduces the behaviour:

 :start geometry definition:

    :start geometry:
        library = egs_cones
        type = EGS_ConeStack
        name = cyl_phantom
        axis = 0 0 0.0 0 0 1
        :start layer:
           thickness = 14
           top radii = 20
           bottom radii = 20
           media = H2O521ICRU
        :stop layer:
    :stop geometry:

    simulation geometry = cyl_phantom
 :stop geometry definition:

 :start source definition:

    :start source:
        library = egs_parallel_beam
        name = e_beam
        :start shape:
           library = egs_rectangle
           rectangle = -0.5 -0.5 0.5 0.5
        :stop shape:
        direction = 0 0 1
        charge = -1
        :start spectrum:
            type = monoenergetic
            energy = 0.45
        :stop spectrum:
    :stop source:

    :start source:
        library = egs_transformed_source
        name = transformed_e_beam
        source name = e_beam
        :start transformation:
           translation = 0 1.0 0
        :stop transformation:
    :stop source:

    :start source:
        library = egs_source_collection
        name = multiple_e_beams
        source names = e_beam transformed_e_beam
        weights = 1 0
    :stop source:
 :stop source definition:

 :start ausgab object definition:
    :start ausgab object:
      library = egs_dose_scoring
      name = fluence_bug
      medium dose = yes
      region dose = no
    :stop ausgab object:
 :stop ausgab object definition:

 :start run control:
    ncase = 50000
 :stop run control:

The output from the dose scoring object indicates that fluence=100000, where one would expect 50000 (i.e. the no. of histories, since beam area = 1 cm^2). This is because in the source collection, the fluence from both e_beam and transformed_e_beam are set to 50000, even though transformed_e_beam isn't used (i.e. has weight 0). If you use a different base source for transformed_e_beam, this could just be a copy of e_beam with a different source name, then the fluence for the source collection will be 50000 as expected.

Expected behavior
I would expect the fluence of each transformed source in the collection to scale based on the source's weight.

Operating system

  • Linux
  • Windows
  • macOS
  • Other:

EGSnrc version
develop branch.

@blakewalters blakewalters self-assigned this Oct 2, 2023
@ftessier ftessier added this to the Release 2024 milestone Oct 3, 2023
@rtownson rtownson linked a pull request Dec 4, 2023 that will close this issue
@rtownson rtownson linked a pull request Jan 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants