-
Notifications
You must be signed in to change notification settings - Fork 91
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
feat: Add ExternalDataRepository #2957
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2957 +/- ##
===========================================
- Coverage 57.22% 57.17% -0.05%
===========================================
Files 1143 1149 +6
Lines 98913 99044 +131
===========================================
+ Hits 56600 56628 +28
- Misses 42313 42416 +103 ☔ View full report in Codecov by Sentry. |
9ed51e9
to
7d92c8a
Compare
hi @untereiner |
Hi @paveltomin, The entry point of the RESQML C++ library is a repository of 3D objects that I want to put in the deck. I can also link an example deck if needed. Also, VTK has file formats storing composite data (grids and surfaces) with complex relationships ( see here). I claim that these files should be considered as « data repositories » to extract from them what’s needed where it’s needed. So, this MeshBase layer could also benefit to them |
thanks for the explanations! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -41,7 +38,7 @@ class CellBlockManager; | |||
* @brief The MeshGeneratorBase class provides an abstract base class implementation for different mesh types. | |||
* The MeshGeneratorBase is the Group specialization for different type of mesh handling. | |||
*/ | |||
class MeshGeneratorBase : public dataRepository::Group | |||
class MeshGeneratorBase : public MeshBase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing so, you make the (yet to become) generators
module depend on mesh
while we have been willing to de the exact opposite: generators
would become a "somehow" independent "source" of meshing informations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can rename it GeneratorBase. But that’s not the path you are drawing. I would be happy to revamp my work in a sibling modèle of the generator one called « data repository »
@@ -43,15 +43,15 @@ MeshManager::~MeshManager() | |||
Group * MeshManager::createChild( string const & childKey, string const & childName ) | |||
{ | |||
GEOS_LOG_RANK_0( "Adding Mesh: " << childKey << ", " << childName ); | |||
std::unique_ptr< MeshGeneratorBase > solver = MeshGeneratorBase::CatalogInterface::factory( childKey, childName, this ); | |||
return &this->registerGroup< MeshGeneratorBase >( childName, std::move( solver ) ); | |||
std::unique_ptr< MeshBase > mesh = MeshBase::CatalogInterface::factory( childKey, childName, this ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now MeshManager
depends on MeshBase
and MeshGeneratorBase
.
Couldn't we have one single concept and use it? I'd say that would make the things clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an answer to this question? To me, if MeshBase
and MeshGeneratorBase
have different responsibilities and MeshGeneratorBase
is intended to generate something derived from MeshBase
, then I don't see a problem....but perhaps I don't understand.
@untereiner does it modify this graph in the docs ? |
@MelReyCG it adds a level in the class hierarchy, so yes. The PRs of Thomas are modifying these files. I don’t know how to move this forward. |
d3405a7
to
6f18a98
Compare
Hi @rrsettgast, I put diagrams to explain a bit more what this PR is expected to improve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @untereiner .
Would it be better to rename the proposed MeshBase
to MeshGeneratorBase
, and rename the current MeshGeneratorBase
to something more specific to its use case?
src/coreComponents/mesh/MeshBase.hpp
Outdated
* @brief The MeshBase class provides an abstract base class implementation for different mesh types. | ||
* The MeshBase is the Group specialization for different type of mesh handling. | ||
*/ | ||
class MeshBase : public dataRepository::Group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So MeshBase
is currently just to hold the catalog definition/instantiation? Is there plans for specifying a pure virtual interface here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now no. It is to avoid implementing the API of MeshGeneratorBase
@@ -43,15 +43,15 @@ MeshManager::~MeshManager() | |||
Group * MeshManager::createChild( string const & childKey, string const & childName ) | |||
{ | |||
GEOS_LOG_RANK_0( "Adding Mesh: " << childKey << ", " << childName ); | |||
std::unique_ptr< MeshGeneratorBase > solver = MeshGeneratorBase::CatalogInterface::factory( childKey, childName, this ); | |||
return &this->registerGroup< MeshGeneratorBase >( childName, std::move( solver ) ); | |||
std::unique_ptr< MeshBase > mesh = MeshBase::CatalogInterface::factory( childKey, childName, this ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an answer to this question? To me, if MeshBase
and MeshGeneratorBase
have different responsibilities and MeshGeneratorBase
is intended to generate something derived from MeshBase
, then I don't see a problem....but perhaps I don't understand.
I am open to suggestions ! |
@wrtobin could you please have another look? |
* This class has dataRepository::Group capabilities to allow for XML input. | ||
* | ||
*/ | ||
class Region : public MeshComponentBase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rrsettgast @CusiniM is ok to call it Region?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Region seems like it is too generic? How does this "Region" differ from the other "Region"?
May close #2953
More explanations:
There below is the situation today:
What I expect after this PR:
ExternalDataRepository
) with almost no constraints on what it expects allows me to create a proper API for another module (example: RESQML)VTKHierarchicalDataRepository
) to add the capability to load complex meshes with semantics (example provided on singlePhaseFlow)Region
) to add the capability to load sets of cells (vtkDataSets) from a complex mesh data format (VTK or RESQML) and give it a id for internal purpose (aka regionAttribute for vtu files)