search

GEOUNED-org / GEOUNED

A tool to convert CAD to CSG & CSG to CAD for Monte Carlo transport codes
European Union Public License 1.2
54 stars 29 forks source link

[BUG] - Different assignment/interpretation of materials between version 1.1.0 and 1.2.0 #256

Closed MicheleLungaroni closed 2 months ago

MicheleLungaroni commented 2 months ago

Description of the bug

I am using your code and I've encountered a potential problem. This concerns the assignment of materials/density, and the splitting number of the cells, an operations that I cannot do well with version 1.2.0. The two folders containing the files used with Version 1.1.0 and Version 1.2.0 are attached

Actions performed with Version 1.1.0

However, with version 1.1.0 I can do well this. What I did in version 1.1.0 is:

  1. Select 8 cells from a step file (with 3 different materials)
  2. Rename each components to *_mXX_dYY.YY with XX = 1, 2, 3 and YY.YY = always 1.0
  3. Write the materials.txt file, as below: 1 7.8 Eurofer 2 7.9 SS316L 3 1.0 Water
  4. Set to config.json -> "matFile": "materials.txt"
  5. Launch the conversion

In this way everything works well, as you can verify from the code present in the "Version_1.1.0" folders. It is very useful to assign specific materials only to the component (in the tree) so that each body underlying the component automatically acquires the material without ever losing the segmentation information (the number of cells, in this case 8)

Test with Version 1.2.0

However, using the same procedures I cannot obtain the same good result with the version 1.2.0. First of all, by always feeding the same step file in the conversion, I obtain a number of cells equal to the number of components and not equal to the number of bodies as in the previous version. So the new cell number 3 corresponds to [3 4 5 6 7 8] as I had segmented.

Even bypassing this obstacle, which would mean:

  1. select all bodies and give spaceclaim option "move each to new component"
  2. rename each component by adding the string _mXX_dYY.YY (this could take a long time when there are over 1000 cells/bodies)
  3. Launch the conversion

But, the output that I get in the end fails to read the density values assigned in the materials.txt file. It assigns the right materials to the cells, but I don't understand why it doesn't assign the density (-100). In the "Version 1.2.0" folder you can easily see that the outputs are not consistent.

Suggestions

From my point of view, how the code in version 1.1.0 is structured is perfect:

  1. I can segment the bodies as I want,
  2. Group the segmented bodies into a single Component, where I can put a material string on the name and consequently all the bodies associated with the component take that material.
  3. I verified that the same applies to the Assembly/Component hierarchy. If I group many Components in an Assembly and change the name of the Assembly, all the Components will have the same material as the Assembly. I verified that if at the same time one of the Components of the Assembly is another material, its specific name can be changed. The Assembly will all be of the material "1" and the particular Component with the modified string will have another material, e.g. "2".
  4. Does not lose cell segmentation information
  5. I can give a material and density to each cell.

Versions.zip

psauvan commented 2 months ago

This bug happens because of the sequence of reading step_file (and materials card) and setting class settings options. This problem was solved with PR #248

To solve your issue you can either change the lines in your code or use the dev branch (which includes other solved issues)