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
In the call to adios2::IO::Open( file, mode ), engines according to file, mode and options are picked.
For some situations when we use ADIOS2, i.e. #2487, but also future transitions to new transports and formats, we would like to know before the Open() call which engine will be picked by it.
Why is this feature important?
This allows us to quickly address some high-level selections and work-arounds, i.e. if an engine is not 100% compatible with older functionality and/or if we do breaking changes in the way we represented data in ADIOS1, ADIOS2 or future versions of ADIOS2.
What is the potential impact of this feature in the community?
It would allow us to implement robust "workflow"/"backend"/"engine" selectors in openPMD-api without having to test-open potentially large files.
Is your feature request related to a problem? Please describe.
It's related to confusion for users in issues such as:
Describe the solution you'd like and potential required effort
A potential solution could implement an GetEngine( file, mode ) function that takes the same parameters as Open() but does only perform the quick logic checks outlined in #2487 and returns an enum or string that uniquely describes the engine it would pick.
I am not sure if GetEngine() would need to be a member of the adios2::IO object, since in some cases we might decide to not use the adios::IO object to read the file at all based on the result of it. So potentially, a standalone function will do.
Describe alternatives you've considered and potential required effort
Alternatives would need to probe-open files (can be slow).
We can also duplicate the logic inside ADIOS2's IO::Open() in openPMD-api, but this would not be very robust since it might change over time (e.g. with new engines being added).
Additional context
Discussed in the WarpX-ADIOS2 meeting on Oct 21st, 2020.
@ax3l@pnorbert just an idea as I ran into a similar situation in another project. This could be another Mode to Open the file to just verify if it exist, only Engine::bool(), Engine::Name() and Engine::Type() would work. That way the API is not altered.
//Ping is an option, I don't have a good name
adios2::Engine engine = io.Open("file.bp", adios2::Mode::Ping);
if( engine && engine.Type() == "BP3" ){ //do something }
In the call to
adios2::IO::Open( file, mode )
, engines according to file, mode and options are picked.For some situations when we use ADIOS2, i.e. #2487, but also future transitions to new transports and formats, we would like to know before the
Open()
call which engine will be picked by it.Why is this feature important?
This allows us to quickly address some high-level selections and work-arounds, i.e. if an engine is not 100% compatible with older functionality and/or if we do breaking changes in the way we represented data in ADIOS1, ADIOS2 or future versions of ADIOS2.
What is the potential impact of this feature in the community?
It would allow us to implement robust "workflow"/"backend"/"engine" selectors in openPMD-api without having to test-open potentially large files.
Is your feature request related to a problem? Please describe.
It's related to confusion for users in issues such as:
Describe the solution you'd like and potential required effort
A potential solution could implement an
GetEngine( file, mode )
function that takes the same parameters asOpen()
but does only perform the quick logic checks outlined in #2487 and returns an enum or string that uniquely describes the engine it would pick.I am not sure if
GetEngine()
would need to be a member of theadios2::IO
object, since in some cases we might decide to not use theadios::IO
object to read the file at all based on the result of it. So potentially, a standalone function will do.Describe alternatives you've considered and potential required effort
Alternatives would need to probe-open files (can be slow).
We can also duplicate the logic inside ADIOS2's
IO::Open()
in openPMD-api, but this would not be very robust since it might change over time (e.g. with new engines being added).Additional context
Discussed in the WarpX-ADIOS2 meeting on Oct 21st, 2020.
cc @pnorbert @guj @franzpoeschel @dmitry-ganyushin
The text was updated successfully, but these errors were encountered: