-
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
Feature/borio/vem refactoring #1288
Conversation
These methods could be moved to ComputationalGeometry.hpp.
…nd removing the use of tensorOps.
Removed virtual method in base class (to be reinstated). Updated unit tests according to new method signature.
This also serves as example of use of the method ComputeProjectors.
Update documentation. Update unit tests accordingly.
Also added GEOSX_HOST_DEVICE macro to all member methods.
Add empty loop on sub-regions and getters.
Fix bug in xml files.
Since the |
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.
Looks good to me, thank you @andrea-borio
// are implemented at the SolverBase class level and can thus be used in Laplace without needing reimplementation. | ||
|
||
//START_SPHINX_INCLUDE_02 | ||
class LaplaceVEM : public SolverBase |
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.
One small change that could potentially reduce significantly the amount of code in the new LaplaceVEM
would be to either A) inherit from LaplaceFEM
or B) create a base class containing all the common functions and inherit from it.
In the LaplaceVEM
class, you would only need to 1) define the catalog name, 2) define SetupSystem
(to call SolverBase::SetupSystem
, and 3) define AssembleSystem
.
If the plan for the SimplePDEs
is to ultimately have a LaplaceDG
, LaplaceMFD
, etc, maybe implementing B is the way to go, but I don't know what others think.
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 agree with option B, something like a LaplaceBase
class would be the way to go. I can try to do that if you want.
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.
Yes, let's do a LaplaceBase class, but in a separate PR now that the overlap is clear.
VirtualElementBase.hpp | ||
) | ||
# | ||
# Specify all sources | ||
# | ||
set( virtualElement_sources | ||
ConformingVirtualElementOrder1.cpp | ||
dummy.cpp |
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.
If you don't have a dummy.cpp
in this folder, then the content of the folder is not compiled? Is there a way to make this work without the dummy.cpp
?
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 was able to make things work without dummy.cpp
mimicking what was done in src/coreComponents/math/CMakeLists.txt.
src/coreComponents/virtualElement/ConformingVirtualElementOrder1.hpp
Outdated
Show resolved
Hide resolved
src/coreComponents/virtualElement/ConformingVirtualElementOrder1.hpp
Outdated
Show resolved
Hide resolved
src/coreComponents/virtualElement/ConformingVirtualElementOrder1.hpp
Outdated
Show resolved
Hide resolved
src/coreComponents/virtualElement/ConformingVirtualElementOrder1_impl.hpp
Outdated
Show resolved
Hide resolved
src/coreComponents/virtualElement/ConformingVirtualElementOrder1_impl.hpp
Outdated
Show resolved
Hide resolved
* Where can I find an example of what it does? | ||
* -------------------------------------------- | ||
* | ||
* Integrated tests associated to this solver are found in the ./integratedTests/ folder |
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.
@andrea-borio, Does this actually describe your integrated tests? This header looks like cut and paste from the FEM version, so we should make sure it is still accurate.
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.
It is indeed a cut and paste of the text that you wrote in LaplaceFEM.cpp
, but I changed all mentions to finite elements into mentions to virtual elements. The text is valid, it tells the truth. When we write a base class, we will have just one.
{ | ||
SteadyState, | ||
ImplicitTransient, | ||
ExplicitTransient |
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 don't know why we have the explicit option for Laplace at all. Perhaps something to remove when we put the base class in place.
<Solvers> | ||
<LaplaceVEM | ||
name="laplace" | ||
discretization="FE1" |
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.
VEM1?
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.
This looks great. I pointed out a few things we should clean up, but probably in a follow up PR. Many will be addressed by creating a LaplaceBase. We will also have to figure out what to do with the discretization key.
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.
Mostly some formatting changes. You can look at the suggestions in the "Files changed" tab and batch them into a single commit, or you can make them manually yourself. The LEAF
comment should be addressed.
set( dependencyList common) | ||
endif() | ||
# if( BUILD_OBJ_LIBS) | ||
# set( dependencyList dataRepository codingUtilities) |
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.
You have to be dependent on something don't you? At the very least you must be dependent on common
?
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.
These dependencies are commented out because I am currently not compiling anything in the VEM folder and cmake fails if I declare dependencies. I left these lines as comments for future reference.
arrayView1d< globalIndex const > const & dofIndex = | ||
nodeManager.getReference< array1d< globalIndex > >( dofManager.getKey( m_fieldName ) ); | ||
|
||
real64 const diffusion = 1.0; |
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.
maybe make this an input variable?
void LaplaceVEM::resetStateToBeginningOfStep( DomainPartition & GEOSX_UNUSED_PARAM( domain ) ) | ||
{} |
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.
Does this not need to be filled?
Related to https://github.com/GEOSX/integratedTests/pull/129