Skip to content
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

Merged
merged 35 commits into from
Nov 28, 2024
Merged

Conversation

untereiner
Copy link
Contributor

@untereiner untereiner commented Jan 26, 2024

May close #2953

More explanations:

There below is the situation today:

  • Every child of MeshGeneratorBase has to fulfill its API even if not compatible
  • ExternalMeshGeneratorBase has to have a file as input
classDiagram
namespace GEOS {

  class Group 

 class WellGeneratorABC

 class WellGeneratorBase
  
  class MeshGeneratorBase {
    generateMesh( Group & parent, SpatialPartition & partition ): void 
    importFieldOnArray( Block block, ....) : void virtual
    freeResources(): virtual void 
    getVolumicFieldsMapping(): std::map< string, string > const &
    getSurfacicFieldsMapping(): std::map< string, string > const & 
  }

  class ExternalMeshGeneratorBase {
    m_filePath: Path 
    m_translate: R1Tensor
    m_scale: R1Tensor
    m_volumicFieldsToImport: array1d< string >
    m_volumicFieldsInGEOS: array1d< string >
    m_surfacicFieldsToImport: array1d< string > 
    m_surfacicFieldsInGEOS: array1d< string >
  }

  class InternalMeshGenerator 
}

Group <|-- MeshGeneratorBase
MeshGeneratorBase <|-- ExternalMeshGeneratorBase
MeshGeneratorBase <|-- InternalMeshGenerator
Group <|-- WellGeneratorABC 
WellGeneratorABC <|-- WellGeneratorBase
Loading

What I expect after this PR:

  • A new class (ExternalDataRepository) with almost no constraints on what it expects allows me to create a proper API for another module (example: RESQML)
  • A new class (VTKHierarchicalDataRepository) to add the capability to load complex meshes with semantics (example provided on singlePhaseFlow)
  • A new class (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)
classDiagram
direction LR
namespace GEOS {

class Group

class ExternalDataRepository {
  virtual open(); void
}

class MeshGeneratorBase {
  generateMesh( Group & parent, SpatialPartition & partition ): void 
  importFieldOnArray( Block block, ....) : void virtual
  freeResources(): virtual void 
  getVolumicFieldsMapping(): std::map< string, string > const &
  getSurfacicFieldsMapping(): std::map< string, string > const & 
}

class ExternalMeshGeneratorBase {  
  m_translate: R1Tensor
  m_scale: R1Tensor
  m_volumicFieldsToImport: array1d< string >
  m_volumicFieldsInGEOS: array1d< string >
  m_surfacicFieldsToImport: array1d< string > 
  m_surfacicFieldsInGEOS: array1d< string >
}

class VTKMeshGenerator {
  m_filePath: Path 
}

class InternalMeshGenerator 

class VTKHierarchicalDataRepository

class MeshComponentBase

class WellGeneratorBase

class Region

}

Group <|-- ExternalDataRepository
Group <|-- MeshGeneratorBase
MeshGeneratorBase <|-- ExternalMeshGeneratorBase
MeshGeneratorBase <|-- InternalMeshGenerator
ExternalMeshGeneratorBase <|-- VTKMeshGenerator
ExternalDataRepository <|-- VTKHierarchicalDataRepository
Group <|-- MeshComponentBase
MeshComponentBase <|-- WellGeneratorBase
MeshComponentBase <|-- Region


namespace GEOS-RESQML {

class EnergyMLDataObjectRepository {
common::DataObjectRepository * getData()
COMMON_NS::AbstractObject* getDataObject(string const & id)
COMMON_NS::AbstractObject* getDataObjectByTitle(string const & name)

}


class EpcDocumentRepository

class RESQMLMesh 
}

ExternalDataRepository <|-- EnergyMLDataObjectRepository
EnergyMLDataObjectRepository <|-- EpcDocumentRepository
MeshGeneratorBase <|-- RESQMLMesh

Loading

@untereiner untereiner self-assigned this Jan 26, 2024
@untereiner untereiner marked this pull request as draft January 26, 2024 14:51
@untereiner untereiner requested a review from TotoGaz January 26, 2024 14:51
@untereiner untereiner marked this pull request as ready for review January 26, 2024 20:39
Copy link

codecov bot commented Jan 26, 2024

Codecov Report

Attention: Patch coverage is 34.70588% with 111 lines in your changes missing coverage. Please review.

Project coverage is 57.17%. Comparing base (b23c80e) to head (ebc60b9).
Report is 1 commits behind head on develop.

Files with missing lines Patch % Lines
...oreComponents/mesh/generators/VTKMeshGenerator.cpp 28.84% 37 Missing ⚠️
...ents/mesh/generators/VTKHierarchicalDataSource.cpp 0.00% 28 Missing ⚠️
src/coreComponents/mesh/ExternalDataSourceBase.cpp 17.64% 14 Missing ⚠️
.../coreComponents/mesh/ExternalDataSourceManager.cpp 33.33% 14 Missing ⚠️
src/coreComponents/mesh/generators/Region.cpp 0.00% 12 Missing ⚠️
src/coreComponents/mesh/generators/Region.hpp 33.33% 2 Missing ⚠️
...ents/mesh/generators/VTKHierarchicalDataSource.hpp 33.33% 2 Missing ⚠️
...reComponents/mesh/generators/MeshGeneratorBase.cpp 66.66% 1 Missing ⚠️
...oreComponents/mesh/generators/VTKMeshGenerator.hpp 50.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@untereiner untereiner force-pushed the feature/untereiner/meshbase branch from 9ed51e9 to 7d92c8a Compare June 3, 2024 08:00
@untereiner untereiner added ci: run CUDA builds Allows to triggers (costly) CUDA jobs flag: ready for review ci: run integrated tests Allows to run the integrated tests in GEOS CI labels Jun 3, 2024
@untereiner untereiner requested review from ryar9534 and paveltomin June 3, 2024 08:09
@paveltomin
Copy link
Contributor

hi @untereiner
i am not sure how adding MeshBase layer helps here, most probably i am missing soemthing
could you please add some description explaining that?
thank you

@untereiner
Copy link
Contributor Author

untereiner commented Jun 7, 2024

Hi @paveltomin,
I can link to the RESQML plugin. Adding this layer helps me creating a child node in Mesh by subclassing something more abstract that MeshGeneratoreBase

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

@paveltomin
Copy link
Contributor

Hi @paveltomin, I can link to the RESQML plugin. Adding this layer helps me creating a child node in Mesh by subclassing something more abstract that MeshGeneratoreBase

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!

Copy link
Contributor

@TotoGaz TotoGaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the 2 PRs (#3068 and #3063) that are deeply revamping this area of the code, this is unfortunately almost granted that this work (and all the work attached relying on it) will become obsolete quite soon.

@@ -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
Copy link
Contributor

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.

Copy link
Contributor Author

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 );
Copy link
Contributor

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.

Copy link
Member

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.

@MelReyCG
Copy link
Contributor

MelReyCG commented Aug 22, 2024

@untereiner does it modify this graph in the docs ?

@untereiner
Copy link
Contributor Author

untereiner commented Aug 22, 2024

@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.

@rrsettgast rrsettgast self-requested a review August 28, 2024 14:44
@untereiner untereiner force-pushed the feature/untereiner/meshbase branch from d3405a7 to 6f18a98 Compare September 3, 2024 10:01
@untereiner untereiner changed the title Add MeshBase feat: Add MeshBase Sep 3, 2024
@untereiner
Copy link
Contributor Author

Hi @rrsettgast, I put diagrams to explain a bit more what this PR is expected to improve

Copy link
Member

@rrsettgast rrsettgast left a 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?

* @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
Copy link
Member

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?

Copy link
Contributor Author

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 );
Copy link
Member

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
Copy link
Contributor Author

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?

I am open to suggestions !
I don’t have any good idea since MeshGeneratorBase is really ment to be a parent of a specific family of generators.

@untereiner untereiner changed the title feat: Add MeshBase feat: Add ExternalDataRepository Sep 4, 2024
@untereiner untereiner requested a review from corbett5 as a code owner September 4, 2024 13:12
@paveltomin
Copy link
Contributor

@wrtobin could you please have another look?

* This class has dataRepository::Group capabilities to allow for XML input.
*
*/
class Region : public MeshComponentBase
Copy link
Contributor

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?

Copy link
Member

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"?

@paveltomin paveltomin merged commit 89a6066 into develop Nov 28, 2024
23 of 25 checks passed
@paveltomin paveltomin deleted the feature/untereiner/meshbase branch November 28, 2024 00:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci: run code coverage enables running of the code coverage CI jobs ci: run CUDA builds Allows to triggers (costly) CUDA jobs ci: run integrated tests Allows to run the integrated tests in GEOS CI flag: requires rebaseline Requires rebaseline branch in integratedTests type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Handle input data from a complex source
6 participants