Instrumenting numerical codes which already implement `conduit` mesh blueprints
Context
This issue has been opened as a part of an effort to instrument GEOSX, geological finite element simulation code with exa-scale pretensions, in this pull request. GEOSX already implements conduit
blueprints of its data structures and it would be best to adhere to DRY principles when instrumenting it with Catalyst.
Problem Statement
When instrumenting simulation codes that already integrate conduit
with Catalyst one would prefer to use the pre-existing native implementations of conduit
nodes mapping the code's data structures instead of reinventing the wheel using catalyst
's integrated conduit
library. This is important for maintainability of the code as well as "future-proofing" the catalyst
instrumentation in the simulation code.
When attempting to create bridges between the two conduit
instances and devising copying schemas from one type of conduit
node to the other, one runs into problems with two conduit
libraries being linked in the same translation unit. This leads to collisions and the compiler ultimately fails to untangle which conduit
to use simply using the first library it comes across.
Questions
- Are there any existing solutions to this type of problem that have been implemented by the
catalyst
community? - Is/Can it the responsibility of the
catalyst
library to provide solutions in this scenario? - What would be the best practice in this use case?