-
Notifications
You must be signed in to change notification settings - Fork 51
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
Remove necessity for RecordComponent::SCALAR #1154
Remove necessity for RecordComponent::SCALAR #1154
Conversation
@franzpoeschel ready for rebase (#1115 is in) 🎉 |
468489f
to
d6e1bca
Compare
d6e1bca
to
3b9acfd
Compare
@franzpoeschel please rebase due to You might find this helpful: pre-commit/pre-commit#1696 (comment) :) |
3b9acfd
to
54b5810
Compare
5509b3b
to
f69116b
Compare
@franzpoeschel this PR seems as it needs to be merged first for a chain of other PRs like the graceful error handling. |
@ax3l This PR is not necessary for any others, but it brings in a lot of changes in our middle-end logic, so I should rebase it some time next week (and cross fingers that it will be somehow mergeable with other PRs) |
Ah, I had entered the wrong base PR in #1237 |
Currently following this again on the https://github.com/franzpoeschel/openPMD-api/tree/topic-remove-scalar-component-redo branch. Instead of managing weird inheritance hierarchies like here, that branch tries out composition over inheritance by inheriting virtually from Attributable. Let's see how that goes. |
f69116b
to
f734cbd
Compare
Changed to the new branch now |
d5f68d0
to
4f75a31
Compare
474699a
to
17ff682
Compare
C++ implementation is now mostly working, Python bindings compile, but fail It's an existing bug in our codebase that is triggered by this PR. In our container bindings for Python we hand out references to C++ objects: // keep same policy as Container class: missing keys are created
cl.def(
"__getitem__",
[](Map &m, KeyType const &k) -> MappedType & { return m[k]; },
// ref + keepalive
py::return_value_policy::reference_internal); After calling Solution: We have shared_ptr semantics for our object model anyway, so change the return value policy to UPDATE: Now using copy semantics and propagating keepalive through the object hierarchy. Python bindings now working again. |
a6959ec
to
5521753
Compare
486fcab
to
b9750aa
Compare
See in-code documentation.
BaseRecord is now derived by its contained RecordComponent type. If it is scalar, the idea is that the BaseRecord itself is used as a RecordComponent, without needing to retrieve the [SCALAR] entry. No logic implemented yet around this, this just prepares the class structure. Notice that this will write some unnecessary attributes since the RecordComponent types initialize some default attributes upon construction.
Not yet supported: Backward compatibility for still allowing legacy access to scalar entries
No longer needed, as one object in the openPMD hierarchy is no longer represented by possibly multiple Writable objects.
Either this way, or make all of them virtual
Special care for legacy usage of SCALAR constant. Implement iteration API such that it works for scalar components as well.
insert() and reverse iterators
Will later be called by Record-type classes, too
Similarly to the Container API, we will need to apply this to Record-type classes. Defining `__setitem__` and `__getitem__` for them is sufficient, as all other members are inherited from RecordComponent. `__setitem__` and `__getitem__` need special care, as they are inherited from Container AND from RecordComponent, so some conflict resolution is needed.
This somewhat demonstrates that this change is slightly API-breaking. Since openpmd-pipe acts directly on the class structure via `instanceof()`, fixes are necessary.
"A scalar component can not be contained at the same time as one or more regular components."
9c51435
to
8b9239a
Compare
Restarting CI for latest version |
Follow-up to openPMD#1154 which changed its behavior.
Follow-up to #1154 which changed its behavior.
The last layer in the openPMD hierarchy is used for specifying different dimensions (often: x, y, z) for a dataset. In the openPMD-api:
However, this last layer is not always needed:
The purpose of
RecordComponent::SCALAR
in here is to state that the last layer should be skipped. From the view of the type system, this makes sense asmeshes["e_all_chargeDensity"]
andmeshes["e_all_chargeDensity"][RecordComponent::SCALAR]
have different types.From an API perspective however, this is an unfortunate situation and experience shows that it can be hard to explain to users. It would be better if users could directly write:
This feature affects the same interface components and requires many of the same changes as another planned feature: The ability to specify entirely custom datasets, e.g.
series.iterations[0].customDatasets()["my"]["custom"]["hierarchy"]
. Development of this PR should keep this planned feature in mind.Done so far:
TODO:
A scalar component can not be contained at " "the same time as one or more regular components.
Attributable::myPath()
go ok with Axel's usage (SCALAR
is no longer printed out)openpmd-pipe
, there are still some unneeded attributes written by this (basis is a PIConGPU KelvinHelmholtz dataset):Map of the commits in this PR:
Auxiliary helpers
b71f94a Add helper: openPMD::auxiliary::overloaded
Prepare for virtual inheritance of Attributable
0435622 Prepare Attributable for virtual inheritance
e7cd246 Fix default constructors/operators of Container and BaseRecordComponent
This PR uses virtual inheritance to solve the diamond problem in order to combine the functionalities of
Container<RecordComponent>
(vector meshes) andRecordComponent
(scalar meshes) intoBaseRecord
:Auxiliary helpers
4afb23c Add helper: openPMD::auxiliary::overloaded
Prepare for virtual inheritance of Attributable
fc20df1 Prepare Attributable for virtual inheritance
dbd07b7 Fix default constructors/operators of Container and BaseRecordComponent
This PR uses virtual inheritance to solve the diamond problem in order to combine the functionalities of
Container<RecordComponent>
(vector meshes) andRecordComponent
(scalar meshes) intoBaseRecord
:State that will be used to track if a BaseRecord is scalar or not
d6f8057 Add m_datasetDefined
Main implementation part 1: Implement new class structure
a65eda3 Prepare class structure without applying logic yet
Main implementation part 2: Implement new logic, no longer use SCALAR
86d478e No longer use map entry SCALAR in application logic
Follow-up: Remove logic that is no longer needed, adapt tests
60b063f Remove KEEP_SYNCHRONOUS task
a98eacd Adapt Coretests
Follow-up: Properly apply
Container
interface toBaseRecord
and some fixes for Container interface itselff60bdac No virtual methods in Container class
10933c3 Fully override Container methods in BaseRecord
908789d Adapt Container API to C++17
Follow-up: Remove SCALAR from
myPath
e692ff5 Adapt myPath() functionality
Python bindings preparation: Refactoring
8d3ff46 Factor out create_and_bind_container() function template
e616c32 Factor out RecordComponent.setitem and getitem
c792883 Consistently use copy semantics in Python API
Python bindings: Main implementation
af7dc76 Apply new class structure to Python API as well
Follow-up: Fix up openpmd-pipe (it interacted directly with openPMD types via
isinstance()
, so it needs to be fixed641bf9a Adapt openpmd-pipe to new design
Follow-up: some safeguards
5bab5d0 Safeguard: No scalar and vector components side by side
d53578e Avoid object slicing when using records as scalar components
Examples and documentation
73a6c69 Remove [SCALAR] from all examples
4202b77 Documentation
Note to myself: For updating the commit map after rebasing: