geos-dev / geos Goto Github PK

Is your feature request related to a problem? Please describe.
When accessing element data from outside the sub-region scope, it is difficult to get quick access to the data held in the subregion. The clunky way would be to traverse the element hierarchy to get to the data:
elementRegionManager.GetRegion(regionIndexOrName).GetSubRegion(subRegionIndexOrName).getData(fieldName)

Describe the solution you'd like
A multi-object view would essentially have the interface of a multi-dimensional array view, but be used to slice down to the data held in a subregion in a convenient fashion. So there would be a view creation stage that returned a view:
MOView myElemView = elementRegionManager.createView(fieldName); myElemView[regionIndex][subRegionIndex][elementIndex];

We could also extend this concept to be a "smart view" such that it would take in the mapping from the current scope (i.e. faceIndex, nodeIndex, etc) and directly deference the view for you:
MOView myElemView = elementRegionManager.createView(fieldName,regionMap,subRegionMap,elementMap); myElemView[faceIndex];

Describe alternatives you've considered
??

Additional context
none

Describe the bug
The TPLs do not build on Cori. There is an error when building the HDF5 tpls.

To Reproduce
Attempt to build the TPLs on CORI.

Expected behavior
TPL should build.

Screenshots

Platform (please complete the following information):
LBNL/Cori

Additional context
Add any other context about the problem here.

We're opening an issue to keep track of suggested improvements to the NonlinearImplicit algorithms. These are low priority for the moment.

• Instead of having NonlinearImplicitStep() do convergence check, we could have each solver implement its of isConverged() function. This would allow for more sophisticated convergence checks than the current residual check we use.
• In the future, we will also want to implement other algorithms beyond Newton with backtracking: trust region methods, nonlinear multigrid, etc. Highly specialized ones can just overload NonlinearImplicitStep(), but generic ones could go into SolverBase.

Describe the issue
Currently the constitutive map is a pair< localIndex_array2d, localIndex_array2d,> where the first component is the index of the constitutive model, and the second component is the index in the material array of that constitutive model.

The use of pair hides this object from automatically being communicated across ranks. No ghosting, no syncing, etc. The object should be broken up into separate arrays or a single 3d array.

To Reproduce
Screenshots
Platform (please complete the following information):
Additional context

Is your feature request related to a problem? Please describe.
Need to operate in hetergeneous memory systems.

Describe the solution you'd like
use CHAI as the resource manager for ManagedArray.

Describe alternatives you've considered
Could directly use UMPIRE rather than CHAI

Additional context
none

Is your feature request related to a problem? Please describe.
Develop a well documented single phase, two point flux finite volume solver to serve as a template for finite volume solvers.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Under a uniform structured grid, shape function derivatives are the same across different elements. It would be nice to have a feature that leverages this.

Describe the solution you'd like
It would be nice to have kernels that were aware of the domain geometry.

Describe alternatives you've considered
N/A

Additional context
N/A

Determine where / how to host code documentation. Need both a publicly accessible portion and a private space with access controls for non-open projects.

Options:

1. Short term: add index.rst link to GEOSX front page
2. Medium term: create a separate GEOSXDOCS repository, and push html documentation there. Do the same for private repos.
3. Long term: geosx.org

Create a separate repo for baseline comparisons, to keep huge data files out of the main repository.

Develop interface for writing parallel HDF files for the purposes of coupling with Chombo.

Add simple indexing wrapper, so that Solvers can index materials as [e][er][k], instead of [matIndex1][matIndex2]. This will hide the distinction between mesh storage and constitutive data storage patterns during assembly.

Is your feature request related to a problem? Please describe.
the edge manager has been disabled in the new version of GEOS. We now need it for topology change.

Describe the solution you'd like
Re-implement the edge manager.

Describe alternatives you've considered
none

Additional context
none

Is your feature request related to a problem? Please describe.
The third-party lib cmake configuration script is horrible.

Describe the solution you'd like
Make a python script to run cmake or configure each TPL.

Describe alternatives you've considered
none

Additional context
none

The initial conditions were recently refactored as part of the SinglePhase_TPFA solver development. The Boundary conditions should follow suit. Also, the Boundary Condition files could use some cleanup.

The LaplaceFEM solver needs to be cleaned up and documented. It will serve as the template for developing new solvers via the Finite Element Method.

Is your feature request related to a problem? Please describe.
We need to re-enable timers in the code.

Describe the solution you'd like
Please re-enable caliper implementation, and update such that it is portable across platforms.

Describe alternatives you've considered
none

Additional context

The legacy directory should be removed from the repo. There should be old code that is used any longer.

Is your feature request related to a problem? Please describe.
Abaqus file format is not an opensource standard. There are a lot of open source meshing tools that exist and could be used to generate meshes usable with GEOSX. If the user has not an abaqus license or a meshing tool which can export mesh to Abaqus format, he will not be able to load his mesh with GEOSX.

Describe the solution you'd like
It will be great if GEOSX supports other mesh format. I was thinking of the Medit ".mesh" format which is a standard in libmesh (available in the repositories of many linux distos) and which is supported by a lot of free meshing tools (tetgen, GMSH...).

Describe alternatives you've considered
Use external tools to convert mesh to Abaqus file... but I think its not very convenient

Additional context
If you are ok with this, I can do it. For me it will be a good way to understand how the mesh management is working in GEOSX. It will be a first step for my work in the Maelstrom project.

Thanks ! And sorry for the amount of message I post on this github, I hope I am not annoying you to much !

Produce a Quick start guide using sphinx. This should include how to clone, setup submodules, build the code, and an intro on how to run the code.

Is your feature request related to a problem? Please describe.
Solvers don't have access to field data during FinalInitialization(), because it is provided as an "initial condition".

Describe the solution you'd like
An additional initialization step performed after field data is loaded. Alternatively, separate "constant" data vs initial condition on "state" data in the input (although the line between the two may not always be clearly drawn).

Describe alternatives you've considered
Currently certain precomputations (e.g. FV transmissibilities) have to be postponed until the first time step setup.

Additional context

We need a DoFManager to handle global degree-of-freedom index assignment. Ideally, user would identify the solution fields to index, perhaps by providing the field keys. A very general case would be displacements on the nodes, pressures in the cells, and Lagrange multipliers on the faces. The DoFManager would loop through the element regions and create global_index field(s) in the data repository with unique global numbers. The dof numbers can then be readily accessed by the physics solver during assembly.

Suggested implementation:
(1) User indicates (somehow) they need global dof numbers for a few existing fields in the dataRepository. For example, a node-based array<R1Tensor> displacements and a cell-based array<real64> pressures.
(2) The DofManager loops over elements and allocates integer index storage next to the fields being indexed, using some agreed on ordering convention. In this example, each node gets a 3-integer vector (array2d<global_index>) for the displacement dofs, numbered 0 to n_displacements-1. Each cell gets a single integer index for the pressures (array<global_index>) numbered n_displacements to n_displacements+n_pressures-1. Index fields can be synchronized using standard MPI communications.
(3) During assembly, user can then access global index data in the same manner as they access the field data, and in a one-to-one way because they live on the same objects.

Once a global_index field is available, linear algebra classes can handle more sophisticated indexing issues, like block-partitioning the matrices.

Describe the bug
One can register a non-owning viewWrapper. For example, a member variable can be registered with the repository, and ownership will remain with the class, not with the repository. If you register a viewWrapper with the same name through a conventional registration where the repository takes ownership of the object it creates, you can get the double free error upon program termination.

To Reproduce
Register a class member
register a viewWrapper with the same name.
run a simulation.

Expected behavior
the second registration should throw an error.

Screenshots

Platform (please complete the following information):
all

Additional context

Describe the bug
Default linear solver (AztecOO) spits a whole lot of diagnostics on screen that makes output unreadable. Something I see in code tells me this was not intended (Aztec output option was applied incorrectly).

To Reproduce
Run any test case with default solver (i.e. LaplaceFEM), see block of information about matrix condition numbers, preconditioner densities, etc. on every time step/iteration. Changing verbosity in the input file does not affect this.

Expected behavior
No output from linear solver unless there are errors/convergence problems.

Screenshots

Platform (please complete the following information):
any

Additional context
I know a linear solver interface overhaul is coming, but this is a one line quick fix that would make it easier to develop and debug solvers for now.

For the axom version of hdf5, we need to add:

1. --enable-parallel to the configure command
2. -fPIC to the compilation flags

This is required for use of geosx_core as a shared library, and for our code coupling strategy for chombo.

Add an AggregationManager to provide essential data for implementing various types of multilevel schemes. The manager will identify which cells belong to different aggregates at various levels of a multilevel hierarchy. It will also implement specific structured and unstructured aggregation methods.

Is your feature request related to a problem? Please describe.
When performing topology change, we must split nodes, edges, faces, elements.

Describe the solution you'd like
ObjectManagerBase should implement split() functions to achieve this.

Describe alternatives you've considered
none

Additional context
none

Currently, the repository tree has too many levels in terms of depth.

We have the following

|-- host-configs
|-- ide_files
|-- scripts
|-- src
|   |-- cmake
|   |-- components
|   |   |-- PhysicsSolverPackage1
|   |   |   |-- src
|   |   |   |-- tests
|   |   |-- core
|   |   |   |-- src
|   |   |   |   |-- MPI_Communications
|   |   |   |   |-- codingUtilities
|   |   |   |   |-- common
|   |   |   |   |-- constitutive
|   |   |   |   |-- dataRepository
|   |   |   |   |-- depricated
|   |   |   |   |-- fileIO
|   |   |   |   |-- finiteElement
|   |   |   |   |-- main
|   |   |   |   |-- managers
|   |   |   |   |-- physicsSolvers
|   |   |   |   |-- python
|   |   |   |   |-- rajaInterface
|   |   |   |   |-- systemSolverInterface
|   |   |   |-- tests
|   |   |-- cxx-utilities
|   |   |-- docs
|   |   |   |-- doxygen
|   |   |-- newComponentTemplate
|   |       |-- src
|   |       |-- tests
|   |-- docs
|   |   |-- sphinx
|   |-- thirdparty
|       |-- optionparser
|           |-- src
|           |-- tests
|-- travis-data

Proposal 1:

 geosx
|-- applicationTests
|   |-- problem1
|   |-- problem2
|   |-- problem3
|   |-- problem4
|   |-- …
|-- host-configs
|-- ide_files
|-- scripts
|-- cmake
|-- components
|   |-- MPI_Communications
|   |   |-- src
|   |   |-- unitTests
|   |-- codingUtilities
|   |   |-- src
|   |   |-- unitTests
|   |-- common
|   |   |-- src
|   |   |-- unitTests
|   |-- constitutive
|   |   |-- src
|   |   |-- unitTests
|   |-- dataRepository
|   |   |-- src
|   |   |-- unitTests
|   |-- depricated
|   |   |-- src
|   |   |-- unitTests
|   |-- fileIO
|   |   |-- src
|   |   |-- unitTests
|   |-- finiteElement
|   |   |-- src
|   |   |-- unitTests
|   |-- main
|   |   |-- src
|   |   |-- unitTests
|   |-- managers
|   |   |-- src
|   |   |-- unitTests
|   |-- physicsSolvers
|   |   |-- src
|   |   |-- unitTests
|   |   |-- integratedTests
|   |-- python
|   |   |-- src
|   |   |-- unitTests
|   |-- rajaInterface
|   |   |-- src
|   |   |-- unitTests
|   |-- systemSolverInterface
|   |   |-- src
|   |   |-- unitTests
|   |-- externalComponents
|   |   |-- cxx-utilities
|   |   |   |-- src
|   |   |   |-- unitTests
|   |   |-- MAELSTROM
|   |   |   |-- src
|   |   |   |-- unitTests
|   |   |   |-- integratedTests
|   |   |-- PhysicsSolverPackage1
|   |   |   |-- src
|   |   |   |-- unitTests
|   |   |   |-- integratedTests
|-- docs
|   |-- doxygen
|   |-- sphinx
|-- thirdparty
|-- continuousIntegrationTesting

Proposal 2:

Is your feature request related to a problem? Please describe.
Currently every ElementRegion requires a Finite Element numerical method attached to it in the input file. This does not make sense for Finite Volume solvers.

Describe the solution you'd like

• At minimum, we can simply make the numericalMethod attribute optional and adjust initialization logic in ElementRegion accordingly (i.e. skip the shape function precomputations if an FE space is not provided). The FV solver will then simply assume its default scheme is applied to all regions.
• Further, we can decide on a way to describe FV discretization schemes and map them to regions in a similar fashion (and whether having more than one is even possible).
• This also leads to the question of how coupled solvers (that require both methods, or even just separate FE spaces for different DOFs) will be linking their numerical methods to regions in the input.

Describe alternatives you've considered
Just keeping the unused input.

Additional context

Produce a Developer Guide. This should be a comprehensive reference for developing in the framework.

Clean and document the contents of the data repository folder. Specifically:

• the doxygen comments should be completed,
• unused code should be deleted.

Create template host config file for new users

Hi,

I was not able to compile the third party libraries following the getting started guide.

checking for hdf5... configure: checking for hdf5 and supporting libraries...
configure: error: problem with directory specified for hdf5 includes
CMakeFiles/silo.dir/build.make:107: recipe for target 'silo/src/silo-stamp/silo-configure' failed
make[2]: *** [silo/src/silo-stamp/silo-configure] Error 1
CMakeFiles/Makefile2:429: recipe for target 'CMakeFiles/silo.dir/all' failed
make[1]: *** [CMakeFiles/silo.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I have checked in the Travis script and found the additional step make hdf5. That solved the problem

If you want, I can whether make a pull request with the getting started guide update or check if this step can be controlled by the Makefile.

Thanks !

setup sphinx documentation generation in cmake (blt).

Is your feature request related to a problem? Please describe.
there are too many submodules that are no longer necessary.

Describe the solution you'd like
Take the submodules that should not be in their own repo, and subtree merge them into the geosx repo.

Describe alternatives you've considered

Additional context

In GEOS, a field has two independent options in terms of whether to be include in silo files: in or not in restart files, and in or not in restart files. Since developers tend to want to see more variables during development and debugging, we often end up with a lot of fields not needed by users.

Suggest have two or more tiers so that some are included in plot files if it is a debug build and not included for regular users.

• Bring the eventManagerOverhaul branch up to date
• Update input xml files in repo
• Update documentation

Describe the issue
The current use of EpetraBlockSystem suffers from two things:

1. it is specific to trilinos
2. it has it's own registration system for the blocks.

We need a portable (trilinos, hyper, petsc) solution.

We could just use the existing data repository in geosx to manage the block objects.

To Reproduce
Screenshots
Platform (please complete the following information):
Additional context

In order to have code that is not subject to LGPL, it must dynamically link with GEOSX. The build system needs to be modified in order allow for dynamic linking. Note that the static factory catalog must remain functional with this option.

Describe the bug
constitutive data is not properly ghosted. In fact, it is not ghosted at all.
The constitutive maps are not ghosted either!

To Reproduce
run a parallel problem with range checking.

Expected behavior
proper execution without busting array bounds.

Screenshots

Platform (please complete the following information):
all

Additional context
parallel simulations that require access to constitutive data structure doesn't work until this is fixed.

Centralize the interface for working with different sparse linear algebra packages: Hypre, Trilinos, Petsc, etc.

Is your feature request related to a problem? Please describe.
Rework the constitutive package and interface.

Describe the solution you'd like
flexible constitutive package and interface that will allow sufficient specialization for material types, and avoid large performance penalties when calling updates, and accessing data.

Describe alternatives you've considered
Current method has a ConstitutiveBase class that defines interface for all models.
This may cause clutter in the interface.

It may be acceptable to have a set of intermediate classes to define interfaces for specific classes of constitutive laws. (i.e. EOS, fluid shear, solid, component constitute relations, full integrated tensorial relations.

Additional context
Add any other context or screenshots about the feature request here.

Add formatter files for common IDEs to help enforce desired style guidelines. Here is an example eclipse xml file for google's style guide.