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

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

Closed
MicheleLungaroni opened this issue Jul 12, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@MicheleLungaroni
Copy link

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

@MicheleLungaroni MicheleLungaroni added the bug Something isn't working label Jul 12, 2024
@MicheleLungaroni MicheleLungaroni changed the title [BUG] - title of the issue [BUG] - Different assignment/interpretation of materials between version 1.1.0 and 1.2.0 Jul 12, 2024
@psauvan
Copy link
Member

psauvan commented Jul 13, 2024

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)

@psauvan psauvan closed this as completed Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants