Add fluid result averaging, FluidMeshInfo, and Faces #435
Conversation
Codecov Report
@@ Coverage Diff @@
## master #435 +/- ##
==========================================
- Coverage 83.49% 83.38% -0.11%
==========================================
Files 44 45 +1
Lines 4640 4959 +319
==========================================
+ Hits 3874 4135 +261
- Misses 766 824 +58 |
| A ``result_type_enum`` value to inform a test on requested zones is necessary. | ||
| An integrated result will for example only be available on faces. | ||
| integrated: | ||
| An integrated result cannot be requested on another location than its native_location. |
There was a problem hiding this comment.
Shouldn't we mention the actual definition of integrated result? Integrated results in Dpf are indeed able to be averaged. It's Fluids+integrated results the ones that aren't (to be compliant with FBU's directives)
There was a problem hiding this comment.
@rafacanton could you give me a description of why FBU's directive is to not average integrated fluid results?
| for every node at each element. Similarly, using `post.locations.elemental` | ||
| gives results with one value for each element, while using `post.locations.nodal` | ||
| gives results with one value for each node. | ||
| `post.locations.elemental`, and `post.locations.faces`. |
There was a problem hiding this comment.
Could we add post.locations.cell to comply with fluid vocabulary?
In the same topic, I'm wondering if we should have at least some docstrings mentioning "reconstruction" (the equivalent of "averaging" in fluid vocabulary) @rafacanton. It will help if people make a search in the doc
There was a problem hiding this comment.
@cbellot000 @rafacanton the issue is there is no gate.locations.cells, yet post.locations comes from core.locations which comes from gate.locations.
There was a problem hiding this comment.
@PProfizi @cbellot000 The issue with adding locations.cells in gate/pydpf-core is that they are the same thing as locations.Elemental, so I would be against adding them there.
| # Raise for integrated result queried on anything else than its native location | ||
| if integrated: | ||
| if (native_location == "Faces" and location != locations.faces) or ( | ||
| native_location == "Elements" and location != locations.elemental |
There was a problem hiding this comment.
why are we not using the locations strings in here?
There was a problem hiding this comment.
@cbellot000 because the native_location strings in the available results are not the same as what you can find in locations
…, select_faces_of_elements
…esh.face_to_node_connectivity
… location.faces too
… bug when querying with a faces_scoping
… result query with a face_scoping
| """Returns a string representation of _FaceList object.""" | ||
| return f"{self.__class__.__name__}({self}, __len__={len(self)})" | ||
|
|
||
| def _short_list(self) -> str: |
There was a problem hiding this comment.
Not sure that name is appropriate regarding what the function does...
PProfizi
changed the title
zone_idsandqualifiersdifferent from requested location for integrated resultszone_idsorqualifierswhen requesting results on cellszone_idsorqualifierswhen requesting results on facesto_nodal_fc(cells to nodes and faces to nodes)to_elemental_fc(nodes to cells, nodes to faces)Logic:
No averaging of integrated results anywhere else
No averaging between faces and cells
Averaging between nodes and cells
Averaging between faces and nodes