You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/docs/sphinx/blueprint_mesh.rst
+218-4Lines changed: 218 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -548,13 +548,227 @@ Material Sets
548
548
549
549
Materials Sets contain material name and volume fraction information defined over a specified mesh topology.
550
550
551
-
A material set is a type of **o2mrelation** that houses per-material, per-element volume fractions that are defined over a referenced source topology.
552
551
Each material set conforms to a schema variant based on:
553
552
554
-
* The layout of its per-material buffers.
555
-
* The indexing scheme used to associate volume fractions with topological elements.
553
+
* Single or multiple buffers for volume fraction data.
554
+
* Element or material dominance.
556
555
557
-
The options for each of these variants are detailed in the following sections.
556
+
These two choices yield four material set schema variants: **multi-buffer element-dominant** material sets, **multi-buffer material-dominant** material sets, **uni-buffer element-dominant** material sets, and **uni-buffer material-dominant** material sets.
557
+
558
+
These variants are detailed in the following sections.
559
+
All of the ensuing examples in this section were created using the ``venn`` Mesh Blueprint example:
A **multi-buffer** material set is a material set variant wherein the volume fraction data is split such that one buffer exists per material.
574
+
An **element-dominant** material set is a material set variant wherein the volume fractions and material ids are grouped by element.
575
+
It is easy to fetch information grouped by element and much harder to fetch information grouped by material in an **element-dominant** material set.
576
+
The schema for this variant dictates that each material be presented as an *Object* entry of the ``volume_fractions`` field with the material name as the entry key and the material volume fractions as the entry value.
577
+
**Multi-buffer element-dominant** material sets are a *non-sparse* representation, as they contain a volume fraction entry for each element.
578
+
**Multi-buffer** material sets also support an optional ``material_map``, which is an *Object* that maps human-readable material names to unique integer material identifiers.
579
+
If omitted, the map from material names to ids is inferred from the order of the material names in the ``volume_fractions`` node, with ids running from ``0`` to ``N - 1``, where ``N`` is the number of materials in the material set.
580
+
If the ``material_map`` is provided, children of the ``volume_fractions`` node are a subset of the children of the children of the ``material_map`` node, which is to say that a material map may reference materials for which we do not have volume fractions, but the volume fractions may not reference a material that is not present in the material map.
581
+
582
+
To conform to protocol, each ``matsets`` child of this type must be an *Object* that contains the following information:
583
+
584
+
* matsets/matset/topology: "topo"
585
+
* matsets/matset/volume_fractions: (object)
586
+
* matsets/matset/material_map: (optional, object with integer leaves)
587
+
588
+
The following plot and representative ``YAML`` illustrate a simple **multi-buffer element-dominant** material set example:
589
+
590
+
.. figure:: venn_matsets.png
591
+
:width:600px
592
+
:align:center
593
+
594
+
A plot of a 3x3 ``venn``'s material boundaries with meshlines and element ids shown. Cyan represents the ``background``, red represents ``circle_a``, green represents ``circle_b``, and blue represents ``circle_c``.
Again, **multi-buffer element-dominant** material sets contain a volume fraction entry for each element.
612
+
To find out what the volume fractions are for each material for a specific element, we simply look at values for the associated element index.
613
+
For example, for element 0, we take the 0th index of each array: ``background`` has a value of ``1.0``, ``circle_a`` has a value of ``0.0``, ``circle_b`` has a value of ``0.0``, and ``circle_c`` has a value of ``0.0``. To determine if a material is in a element, we must check that it has a nonzero volume fraction for that element. Therefore, we can infer that element 0 is 100% the ``background`` material, and the other materials are not present.
614
+
If we want to see the volume fractions for element 10, we go to the 10th index of each array: ``background`` has a value of ``0.0``, ``circle_a`` has a value of ``0.333333333333333``, ``circle_b`` has a value of ``0.333333333333333``, and ``circle_c`` has a value of ``0.333333333333333``.
615
+
Therefore we can infer that element 10 is evenly split between the circle materials and there is no ``background`` material present.
616
+
If we want to know the material ids of the materials in a specific element, we can examine the material map entry for each material in that element that has a volume fraction greater than ``0.0``.
617
+
If no material map is present, we can infer the material id from the order of the material volume fraction arrays under the ``volume_fractions`` node.
A **multi-buffer** material set is a material set variant wherein the volume fraction data is split such that one buffer exists per material.
623
+
A **material-dominant** material set is a material set variant wherein the volume fractions and element ids are grouped by material.
624
+
It is easy to fetch information grouped by material and much harder to fetch information grouped by element in a **material-dominant** material set.
625
+
The schema for this variant dictates that each material be presented as an *Object* entry of both the ``volume_fractions`` field and the ``element_ids`` field with the material name as the entry key and the material volume fractions as the entry value for the former and the per-material element ids as the latter.
626
+
**Multi-buffer material-dominant** material sets are a *sparse* representation, as they only include volume fraction data for elements that have greater than 0% volume.
627
+
**Multi-buffer** material sets also support an optional ``material_map``, which is an *Object* that maps human-readable material names to unique integer material identifiers.
628
+
If omitted, the map from material names to ids is inferred from the order of the material names in the ``volume_fractions`` node, with ids running from ``0`` to ``N - 1``, where ``N`` is the number of materials in the material set.
629
+
If the ``material_map`` is provided, children of the ``volume_fractions`` node are a subset of the children of the children of the ``material_map`` node, which is to say that a material map may reference materials for which we do not have volume fractions, but the volume fractions may not reference a material that is not present in the material map.
630
+
631
+
To conform to protocol, each ``matsets`` child of this type must be an *Object* that contains the following information:
632
+
633
+
* matsets/matset/topology: "topo"
634
+
* matsets/matset/volume_fractions: (object)
635
+
* matsets/matset/element_ids: (object)
636
+
* matsets/matset/material_map: (optional, object with integer leaves)
637
+
638
+
The following plot and representative ``YAML`` illustrate a simple **multi-buffer material-dominant** material set example:
639
+
640
+
.. figure:: venn_matsets.png
641
+
:width:600px
642
+
:align:center
643
+
644
+
A plot of a 3x3 ``venn``'s material boundaries with meshlines and element ids shown. Cyan represents the ``background``, red represents ``circle_a``, green represents ``circle_b``, and blue represents ``circle_c``.
**Multi-buffer material-dominant** material sets are sparsely organized by material.
668
+
To find out what the volume fractions are for each element for a specific material, we simply look at associated element ids and volume fractions for that material.
669
+
For example, for ``circle_c``, we see that it is present in element ``6``, where it has a volume fraction of ``1.0``, by which we can infer that it represents the entirety of that element.
670
+
We also can see that ``circle_c`` is present in element 10, where it has a volume fraction of ``0.333333333333333``.
671
+
If we want to know the material id for a material, we can examine the material map entry for that material.
672
+
If no material map is present, we can infer the material id from the order of the material volume fraction arrays under the ``volume_fractions`` node.
A **uni-buffer** material set is one that presents all of its volume fraction data in a single data buffer.
678
+
An **element-dominant** material set is a material set variant wherein the volume fractions and material ids are grouped by element.
679
+
It is easy to fetch information grouped by element and much harder to fetch information grouped by material in an **element-dominant** material set.
680
+
In this case, the material set schema must include a volume fraction data buffer, a parallel buffer associating each volume with a material identifier, and an *Object* (the ``material_map``) that maps human-readable material names to unique integer material identifiers.
681
+
Additionally, the top-level of this schema is an **o2mrelation** that sources from the volume fraction/material identifier buffers and targets the material topology.
682
+
**Uni-buffer element-dominant** material sets are a *sparse* representation, as they only include volume fraction data for elements that have greater than 0% volume.
683
+
684
+
To conform to protocol, each ``matsets`` child of this type must be an *Object* that contains the following information:
685
+
686
+
* matsets/matset/topology: "topo"
687
+
* matsets/matset/material_map: (object with integer leaves)
As an **o2mrelation**, the following values may also be present:
692
+
693
+
* matsets/matset/sizes: (integer array)
694
+
* matsets/matset/offsets: (integer array)
695
+
* matsets/matset/indices: (integer array)
696
+
697
+
.. note::
698
+
It can help to think of how the data are traversed when understanding this structure. An
699
+
element's size and offset can be obtained by indexing the ``sizes`` and ``offsets`` with the
700
+
element id. These are used to look up a tuple of data from ``indices``. The resulting
701
+
indices for the element are array indices into the ``material_ids`` and ``volume_fractions``
702
+
arrays for the current element.
703
+
704
+
The following plot and representative ``YAML`` illustrate a simple **uni-buffer element-dominant** material set example:
705
+
706
+
.. figure:: venn_matsets.png
707
+
:width:600px
708
+
:align:center
709
+
710
+
A plot of a 3x3 ``venn``'s material boundaries with meshlines and element ids shown. Cyan represents the ``background``, red represents ``circle_a``, green represents ``circle_b``, and blue represents ``circle_c``.
Again, **uni-buffer element-dominant** material sets are sparsely organized by element.
728
+
We can use information from the **o2mrelation** to understand the ``volume_fractions`` and ``material_ids`` arrays.
729
+
Let's say we want to know the material ids and volume fractions of materials in element 0.
730
+
First, we examine the **o2mrelation** arrays. We see that our size is ``1``, meaning there is one material present in this element.
731
+
Our offset is ``0``, meaning our starting index into the ``indices`` array is zero.
732
+
The 0th entry in ``indices`` is also ``0``, meaning that the 0th values in both the ``volume_fractions`` and ``material_ids`` arrays correspond to data in element 0.
733
+
If indices are not present, then we use the ``sizes`` and ``offsets`` information to get the starting index directly into the ``volume_fractions`` and ``material_ids`` arrays.
734
+
If ``sizes`` and ``offsets`` are not present, then it is assumed that all sizes are ``1`` and ``offsets`` is a trivial prefix sum.
735
+
For element 0, we see that the only material id is ``0`` and the volume fraction is ``1.0``.
736
+
Looking at the material map, we can see that ``background`` is the material corresponding to material id ``0``.
737
+
Therefore, element 0 is wholly filled with the ``background`` material.
738
+
739
+
If we want to know which materials are in element 10, we first go to the 10th index in the ``sizes`` and ``offsets`` arrays.
740
+
We can see that the size is ``3`` and the offset is ``10``.
741
+
Therefore, we know there are three entries in each of the ``volume_fractions``, ``material_ids``, and ``indices`` arrays, corresponding to three materials in element 10.
742
+
The ``indices`` for element 10 are ``10``, ``11``, and ``12``, telling us to look in ``volume_fractions`` and ``material_ids`` at those array indices to find the relevant information.
743
+
If ``indices`` were not present, then we would use ``offsets`` to find the starting index into the data arrays, and the ``sizes`` to know how many elements to read.
744
+
If ``sizes`` and ``offsets`` are not present, then it is assumed that all sizes are ``1`` and ``offsets`` is a trivial prefix sum.
745
+
For element 10, we can see that the three material ids are ``1``, ``2``, and ``3``, and the volume fractions are ``0.333333333333333``, ``0.333333333333333``, and ``0.333333333333333``.
746
+
Looking at the material map, we can see that ``circle_a`` is the material corresponding to material id ``1``, ``circle_b`` is the material corresponding to material id ``2``, and ``circle_c`` is the material corresponding to material id ``3``.
747
+
Therefore, element 10 is split evenly between the circle materials.
748
+
749
+
//////
750
+
751
+
752
+
uni-buffer material-dominant
753
+
- spec
754
+
- example
755
+
- unsupported
756
+
757
+
how do I know what I am?
758
+
759
+
info:
760
+
- mat ids need not be in a normal range
761
+
- multi-buffer volfracs children must be a subset of material map children
762
+
- material map children can be in any order with any material ids; vol frac children do not need to be in the same order. But the order of the material map is the order the materials appeare in the matset for things like matset accessors
763
+
- o2m relation options (having indices, having no sizes, no offsets, no indices)
0 commit comments