Page 2 of 4
Posted: Thu Jul 19, 2018 4:15 pm
Thank you! It worked!
I tried the solid 2 routine but for one of the STL files the program returned an error stating "Degenerate facet, unable to proceed" and for other files
it looks like some parts are not plotted. I am loading models of the whole tokamak vessel and just sections of it, respectively. Could the problem in both cases be the complexity of the geometry?
Posted: Thu Aug 30, 2018 9:28 am
The STL files are composed of triangular facets defined by three points. The error message means that for some facet two of these three points coincide. So the problem is in the STL file. Unfortunately some CAD models have these errors, and fixing them has to be done on the CAD side.
Posted: Tue Sep 18, 2018 5:16 pm
Thank you very much for your reply, Jaakko!
I have a few more questions:
1. There is something going on with the STL files when I plot them (find attached an example) and I would like to know if this is just a plotting issue or it will influence the results of the simulation as well.
2. In order to calculate the total neutron rate using a He3 detector, I am running the following case:
set acelib "$SERPENT_DATA/xs/sss_jeff311u.xsdata"
therm MyThermLib lwj3.00t
mat He3 -1.65
mat water -1.0 moder MyThermLib 1001
mat graphite -1.88
surf 1 cube 0 0 0 1000
surf 2 inf
cell 1 0 fill detector -1
cell 2 0 outside 1
cell 3 background void -2
solid 2 detector background
10 4 5 4 3 2
body cylinder_1 cell_detector water
file cylinder_1 ".../detector_holder.stl" 1 100 0 0 %moderator
body cylinder_11 cell_detector He3
file cylinder_11 ".../detector_he3.stl" 1 100 0 0 %cylinder inside the moderator
body cylinder_2 cell_detector graphite
file cylinder_2 ".../cylinder.stl" 1.5 400 0 0 %material the neutrons pass through
det helium dr -1 He3 dm He3
mesh 8 2 helium 2 900 900
mesh 8 2 helium 3 900 900
src 5 se 20 sp 700 0 0
set nps 10000
set srcrate 1E15
plot 1 900 900
plot 2 900 900
plot 3 900 900
I want to make sure that the definition of the detector is properly used for the purpose because the output is 0.
3. When running the case with a radioactive decay source, the volume is zero, regardless of the fact that I specify it in the material card. What could be the reason for this?
Posted: Wed Sep 19, 2018 8:57 am
The extra pixels can be an indication that there are holes in the STL surfaces. Do you have any way of checking the water-tightness of the model?
You can also try running the calculation with command line option "-checkstl N M". The code samples N random points in the geometry and starts M rays in random directions to check the consistency of the model.
Which version are you using?
How large is the STL model? Would it be possible to send it to me by email?
The detector definition looks right, but the zero result may result from some geometry error in the model.
Posted: Thu Sep 20, 2018 3:31 pm
I will try to find a way to check the water tightness within the CAD program. I used the -checkstl option and the files with roughly 96% consistency and below have this problem.
The version is 2.1.29.
The files are not large but I would like to try solving this myself before bothering you with sending anything.
Regarding the detector, there should in principal not be a problem because I am running a very simple case just with STL cylinders in order to get familiar with the detectors before jumping to the more complicated scenario.
The consistency test passed in all random points. This is why I do not understand where the issue might be. If I expand the spatial integration things seem to work but I am interested in the He3 detector.
Thank you for your fast reply!
Posted: Fri Sep 28, 2018 3:55 pm
A possibly faulty feature of our STL-solids is that some of them are made in fact of several disconnected solids. So even if the tightness of the triangulation should be good enough (which we don't know yet), maybe we should further decompose that "solid" into a few separate ones. Since we started from a rather detailed CAD model, it's quite some effort to decompose it properly - but it might be necessary anyway, as soon as we have to assign different materials to different hardware components.
Do you think that this (several actual disconnected solids in one STL-solid) could be the reason of the faulty pixel in the geom.png's shown by Monika?
Posted: Fri Sep 28, 2018 11:45 pm
Serpent doesn't care about the gaps between the solids. Anything that is not a part of any solid is part of the outside world. So it shouldn't really matter whether the geometry is composed of a single or multiple solids.
The 96% pass rate for the consistency check may be a red flag. The test routine samples random points in the geometry and random rays from each point, and a failure occurs if two or more rays put the inside different side of the solid i.e one ray intersects with the outer boundary but another ray doesn't, or the direction is the opposite (inside-out vs. outside-in).
There have been some improvements in the STL routine, but I'm not sure if anything has been changed since 2.1.29. Have you tried with 2.1.30?
Posted: Thu Oct 11, 2018 7:00 pm
Using stl-repairing software on each component + shifting back the objects to their "real world" position did the trick! Now we have a consistency rate of 99.86%, as a result the broken pixel in the mesh geometry have disappeared
Thanks for helping!
Posted: Fri Oct 12, 2018 1:48 pm
Excellent. Before running any final calculations it is usually worthwhile to spent some time optimizing the way the STL geometry is set up, since this may affect the calculation time quite significantly.
When the geometry is processed, Serpent prints out something like:
Code: Select all
Adaptive search mesh:
- Dimensions: x = [-119.9, 119.9]; y = [0.0, 488.6]; z = [-120.0, 120.0]
- Depth: 9 5 3 2
- 7080559 mesh cells
- 81.9% of volume consists of pre-assigned data
- 1.91 Gb of memory allocated for search mesh
Try to set up the search mesh parameters in such way that the fraction of pre-assigned cells is above 90%. Serpent uses empty search mesh cells to store pre-assigned material data, and the higher this fraction is, the less CPU time is spent performing the computationally expensive ray tests for the STL geometry. Refining the mesh also increases the memory footprint and processing time, so the mesh cannot be refined indefinitely.
Another thing to consider is dividing the geometry into multiple levels. If you have a large number of STL solids describing separate components (shielding, vacuum vessel, coils, etc.), it may be beneficial for computational performance to define these components in separate universes nested inside each other. Each STL universe uses its own search mesh, and it can be easier to find optimal fill fractions when large components are separated from each other.
Posted: Fri Oct 12, 2018 2:41 pm
Thanks for the suggestions!
The fraction of pre-assigned cells appears to be large:
Code: Select all
Adaptive search mesh:
- Dimensions: x = [-1157.4, 1157.3]; y = [-1157.4, 1156.6]; z = [-990.4, 990.4]
- Depth: 5 4 3 2
- 244102 mesh cells
- 92.8% of volume consists of pre-assigned data
- 1.01 Gb of memory allocated for search mesh
Concerning multiple universes, we'll try that. We have still to fix the (point, Pu238) source and the actual (He3) detector Monika aims to calibrate, that's rather urgent.