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

Allow components to be input outside of a block in blueprints #504

Open
ntouran opened this issue Dec 1, 2021 · 2 comments
Open

Allow components to be input outside of a block in blueprints #504

ntouran opened this issue Dec 1, 2021 · 2 comments
Assignees
Labels
complex Expected to be a complex issue enhancement New feature or request

Comments

@ntouran
Copy link
Member

ntouran commented Dec 1, 2021

For lots of reasons (e.g. this discussion), we'd like to be able to define components in a components: root level in the blueprints rather than just inside blocks.

⚠️ This might be a hard task. But actually maybe not if we keep it limited to just allowing input and loading them into a new blueprint.componentDesigns alongside e.g. blockDesigns and assemDesigns, etc.

Complexities and questions:

  • This will require updating the is3D logic and having explicit height included on "2D" components.
  • We will need new syntax and block construction logic to bring components into blocks. Will we use strings instead of anchors?
  • Will we still support the current style of inputs? I don't see why not. This could start as a way to just add more componentDesigns to a blueprints.
  • There is the question of groups of components as well. In a pin lattice, you often want to place clad, fuel, spacers, gap/bond, liner together in a bunch of positions. How will we group these? Just sharing a grid specifier may work.
@ntouran ntouran added enhancement New feature or request complex Expected to be a complex issue labels Dec 1, 2021
@ntouran ntouran self-assigned this Dec 2, 2021
@ntouran
Copy link
Member Author

ntouran commented Dec 2, 2021

I'll take a stab at this and get a branch going to be collaborated on with @john-science

ntouran added a commit to ntouran/armi that referenced this issue Jan 6, 2022
This just allows the user input of component groups intended to mix
different free components in different fractions. As is, this only
allows the input but does not implement any actual construction of
objects. It is a follow-up to terrapower#505 as part of the larger terrapower#504 task
related to improving input flexibility.
ntouran added a commit to ntouran/armi that referenced this issue Jan 18, 2022
This just allows the user input of component groups intended to mix
different free components in different fractions. As is, this only
allows the input but does not implement any actual construction of
objects. It is a follow-up to terrapower#505 as part of the larger terrapower#504 task
related to improving input flexibility.
ntouran added a commit to ntouran/armi that referenced this issue Jan 20, 2022
This allows the user to input component groups intended to mix different
free components in different fractions. It is a follow-up to terrapower#505 as
part of the larger terrapower#504 task related to improving input flexibility.

This implements the addition of groups of components to blocks, which
can be used to create more complex and flexible models.

The code changes solved a few residual issues where iterating over the
children of a block were assuming all children would be Components. Now
they can be Composites with multiple Components or Components.

Some upgrades to DerivedShapes were necessary so that they could work
with volumetric components in addition to pure 2D ones.

These are additional steps toward terrapower#504, but true practical usage of
these groups is not quite done yet. More followups are needed.

Added a new test covering negative volume in derived shapes
ntouran added a commit that referenced this issue Jan 20, 2022
This allows the user to input component groups intended to mix different
free components in different fractions. It is a follow-up to #505 as
part of the larger #504 task related to improving input flexibility.

This implements the addition of groups of components to blocks, which
can be used to create more complex and flexible models.

The code changes solved a few residual issues where iterating over the
children of a block were assuming all children would be Components. Now
they can be Composites with multiple Components or Components.

Some upgrades to DerivedShapes were necessary so that they could work
with volumetric components in addition to pure 2D ones.

These are additional steps toward #504, but true practical usage of
these groups is not quite done yet. More followups are needed.

Added a new test covering negative volume in derived shapes
scottyak pushed a commit to scottyak/armi that referenced this issue Oct 27, 2022
This allows the user to input component groups intended to mix different
free components in different fractions. It is a follow-up to terrapower#505 as
part of the larger terrapower#504 task related to improving input flexibility.

This implements the addition of groups of components to blocks, which
can be used to create more complex and flexible models.

The code changes solved a few residual issues where iterating over the
children of a block were assuming all children would be Components. Now
they can be Composites with multiple Components or Components.

Some upgrades to DerivedShapes were necessary so that they could work
with volumetric components in addition to pure 2D ones.

These are additional steps toward terrapower#504, but true practical usage of
these groups is not quite done yet. More followups are needed.

Added a new test covering negative volume in derived shapes
@john-science
Copy link
Member

@ntouran This ticket is still assigned to you. That's cool with me, but if you aren't planning on working on it, please un-assign it.

(You are not being singled out, I am just trying to go through all the ARMI tickets.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complex Expected to be a complex issue enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants