When I try to run my input (see attached, montypy4_runB.inp (1.2 MB), I activate also the wall shown below, likely because the proton beam keeps going:
to keep the prompt radiation within only what we want to irradiate, i.e. the target) but the errors around the wall are now very strange and huge. I’m not sure how to fix this. The importance biasing is also correct I believe:
The figure below is showing the errors with black body. Where black on the colour scale is 100% and pink 20%. The input runs with 1e7 primaries.
The plot on the left is 5e6 particles (5 spawns of 1e6 particles each, 1 cycle, high biasing). On the right is 2.5e7 particles (5 spawns and 5 cycles, lower biasing). The colour bar is the error (20% pink, 100% black). You can clearly see how the statistics are really poor outside of the hall where the dose is supposed to be evaluated.
when the input is run in a cluster, several child runs remain stuck and eventually complete (i.e. in a run with 5 CPU cores that should take 30 minutes, 4 of them complete in 30 minutes and the last in >2 hours). You can verify this by running 10000 primaries with spawn=5. I have noticed that the core that gets stuck in general has more of these ELSCKN and Emsnsc calls.
Two simulations are done. RunA with Np_tot=5e6 histories, 1e6 primaries over 5 CPU cores and the other RunB with Np=166667 particles over 60 CPU cores (i.e. ~Np_tot=1e7). Attached three plots:
→ the uncertainty in the results of one of the child process of RunA (i.e. 1e6 primaries simulated)
–> the uncertainty of the total primaries of runA (i.e.5e6 primaries)
→ the uncertainty in the results of RunB (i.e. 1e7 primaries)
What is the reason for such similar uncertainties in the area circled red (it is a layered wall with progressive importance)? shouldn’t the uncertainty of RunB be much less?
The biasing is different for both runs but the gradient between layers in the wall is comparable,
I attach my inputs for both runs if needed and looking forward to your prompt reply!
Best wishes,
Marco
I note also that the error in the results got worst when the blackbody was introduced around the region Surr. Below is what it was before the introduction of the blackbody (with 5e6 primaries):
The problem with this scenario was that a second source of radiation in the wall was manifesting. The blackbody region around “Surr” was introduced to keep the radiation only in what we want to irradiate (i.e. the target)
It is a bit difficult to follow your post - in the future, try to clearly state the problem first and then add all the additional information. I am not sure what you are trying to solve.
When opening your input files, the geometry is not there. Could you upload the full file?
Please note that a black body region is not physical! Some of the prompt dose will be lost/absorbed there.
The fact that you have very little radiation (so almost no particles, whence your high errorbars) outside the shielding just proves the shielding effectiveness.
If you have a specific region/location that you want to achieve better statistics in, I would suggest to use Automatic Importance Biasing.
OK. The first simulation (sim 1) should be of the entire medical module with a medical target being irradiated in the middle of the target hall, with an ISOL target in front. Then, the ISOL target is removed (all its materials set to vacuum), and all components of the medical module will be let to decay, and its residual dose from the middle of the target hall will be scores in the entire target hall. This scoring needs to happen at times after the End of Beam (EoB + time) of: EoB+1day; EoB+1 week; EoB+3 weeks; EoB+6 weeks. The goal is to evaluate the residual radiation outside of the hall, outside of the walls that I show in my previous posts.
Attached my input files (when I try uploading my montypy4.inp it changes automatically to montypy4_new.inp. I have uploaded it as zip - input.zip) . The geometry is huge so maybe that’s why you couldn’t find the geometry in the above input, just look for “Surr” in the geometry search and appropriately zoom in and out and center. You should see the geometry as so:
2.2 The problems I mention are only manifested in the running, so it’s a very subtle problem. You may try running it with e.g. 5e6 primaries to see the issue. Another thing I’ve noticed is that e.g. with 5 spawns, 1 core always lags with respect to the other. With many spawns, more cores lag.
2.3 The blackhole region was tested in other scenarios with success.
I would prefer not to use automatic biasing since I have already biased my geometry in a way that makes the radiation escape the hall and through the walls…However I have not gotten the appropriate solution from this
I have tried two more things, I’ve removed many of the coincident planes and I’ve added the profile card to how much time each particle species is spending in each region. Both solutions produce the same outcome and the latter doesn’t produce anything insightful on the matter. The only maybe insightful thing is from the layering of the .profi file. It is saying that on the lower walls (“Blue”) the biasing is correct since the particles streamline from one layer to the next but in the upper figure “Red”) - that is the opposite – particles spend less time on the outer layers.
It would be very useful for clarity to distinguish the information you are providing from the question/problem you are trying to solve.
From my understanding, you have two issues:
A geometry tracking issue - for the case of long runs, please provide the associated *.err files. Given your very complex geometry, it is very probable that you have some errors that are not evident at visual inspection.
A statistics/error/biasing issue - what is the solution you are looking for? You mention you are trying to evaluate the residual radiation outside the the hall (please provide the name of these regions).
Please try to be as clear as possible in stating your issue. Except poor statistics in shielded areas (as expected), that you would like to improve via biasing and via running with more primaries, there does not seem to be any issue.
Thanks for your reply. The entire point is that there are no geometry errors and also now no GEOFAR errors — however, in a multicore run on a cluster, some cores lag with respect to others and the only noticeable pattern in the .err file are warnings of the sort:
1)*** PWNINE Problem in axestr, restart..
2)*** Umfnst”
3)Emsnsc: sighlp,sigmlr,eusplc
4)ITCURR,BRBETP,BRBETM,BRALP
5)COUSET, TXYZ
From my understanding these are innocuous but do have some effect on the runtime (e.g as written 1 core can become stuck and finish in double the amount of time as other cores).
As for the target region, this is specified in the input with the AUTOIMBS card that I attached - it is region VOID.
The issue is basically understanding whether the fact that radiation does not exit the wall is a consequence of the good shielding of the walls or due to a badly constructed geometry or something else altogether. As you pointed out, the geometry is complex. However, there are no signs of failure upon running and the biasing has been developed in a way that radiation can escape, so it should.
Hence the purpose of this post was to validate in a way the running of the input by the expert.
I had a look at your *.out and *.err files. The only thing that seems suspicious is that you have (78.9%) of your energy escaping the system, i.e. absorbed by regions assigned with BLCKHOLE material. Given your large geometry, it is very unlikely that you have radiation escaping your system in the encompassing BLKBODY region.
I see you have two other regions, HC2MEDBH and BBS. I would recomend not using BLCKHOLE for these and rerun. In your first message you mention that you do assign BLCKHOLE to some regions - though I caution against it.
You have some minor warnings (not to worry about) and some recoverable geometrical errors (rather expected given your large geometry, but not ideal).
Ideally, if you notice a core is stuck - you could investigate then the err/out files and try to see when/where it is stuck. I will run some simulations myself to see if I can identify the issue.
You say: “biasing has been developed in a way that radiation can escape, so it should” - not if you really have no physical process that would make radiation escape.
Maybe this is one of the issue - you are trying to use the AUTOIMBS for the VOID region, which encompasses (at least the upper half of) your geometry! It should be used for more local/smaller regions, i.e. a region of a few m^3 in your case, either above or on a side. The principle of geometric biasing is that you want to enhance radiation towards a particular direction, not in the entire geometry!
Try to define some regions of importance or that are representative of locations of where you want to quantify your radiation, and bias towards that direction.
Let me know if this is useful and do not hesitate to ask more should you still required guidance.
Interesting. Thank you for your reply!…Regarding the blackhole, when no BBS region is defined, two sources were manifested and this was not what was intended in the simulation (i.e. the only source should be from the proton beam), see plot just below:
The blackbody region around “Surr” was introduced to keep the radiation only in what we want to irradiate (i.e. the target). The blackhole should capture all the prompt radiation and during the residual phase it turns into vacuum (you can see this in the mat-decay card)
If you have other suggestion to get rid of this second source though while at the same time capturing the physics – I would be glad and interested to hear.
Regarding the geom errors— I think the code can recover from them as you say so we can rule this out.
I have also reconstructed the entire geometry using only RPP bodies (compared to the planes that were used before). The results are exactly identical which points to the general problem being in the BBS region. Does the thickness of this region also have an influence of the scored doses?
Thanks for running the simulations and waiting for your reply!!
PS. I have now achieved decent statistics in the areas of interest by running 5e8 particles
It would be nice to have better statistics in the area circled green so eventually I could use this in the autoimbs card. This is a YZ plot with X between -1620 and -1520.
Lastly I would like to point out to a similar input attached with black hole (TgMod.flair/inp) who has produced results with uncertainties of <10% in the same locations as the problem input file. See below…
