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

Feature/borio/vem refactoring #1288

Merged
merged 43 commits into from
Apr 1, 2021
Merged

Conversation

andrea-borio
Copy link
Contributor

@andrea-borio andrea-borio commented Jan 24, 2021

These methods could be moved to ComputationalGeometry.hpp.
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.
@andrea-borio andrea-borio marked this pull request as ready for review February 21, 2021 17:37
@andrea-borio
Copy link
Contributor Author

Since the LaplaceVEM class is not yet intended to use kernel launches, I commented all GEOSX_HOST_DEVICE flags in VEM classes, that generated compilation errors with cuda. The errors were due to the fact that the method ConformingVirtualElementOrder1::ComputeProjectors cannot access data members from the device.

Copy link
Contributor

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

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.

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 agree with option B, something like a LaplaceBase class would be the way to go. I can try to do that if you want.

Copy link
Contributor

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

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?

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 was able to make things work without dummy.cpp mimicking what was done in src/coreComponents/math/CMakeLists.txt.

* Where can I find an example of what it does?
* --------------------------------------------
*
* Integrated tests associated to this solver are found in the ./integratedTests/ folder
Copy link
Contributor

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.

Copy link
Contributor Author

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

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

Choose a reason for hiding this comment

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

VEM1?

Copy link
Contributor

@joshua-white joshua-white left a 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.

@joshua-white joshua-white added ci: run CUDA builds Allows to triggers (costly) CUDA jobs and removed flag: ready for review labels Mar 23, 2021
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.

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

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?

Copy link
Contributor Author

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

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?

Comment on lines +442 to +443
void LaplaceVEM::resetStateToBeginningOfStep( DomainPartition & GEOSX_UNUSED_PARAM( domain ) )
{}
Copy link
Member

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?

@francoishamon francoishamon merged commit 833e470 into develop Apr 1, 2021
@francoishamon francoishamon deleted the feature/borio/vemRefactoring branch April 1, 2021 18:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci: run CUDA builds Allows to triggers (costly) CUDA jobs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants