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

First iteration of adaptivity hooks #1105

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Conversation

bartgol
Copy link
Collaborator

@bartgol bartgol commented Jan 10, 2025

This PR adds a first version of the adaptivity hooks. We may change them later if/when we realize they are insufficient/overkill/wrong/whatever. The goal was to get something working.

Some details:

  • Added a version of PiroObserver that is also Tempus-compatible (so it can be called by Tempus during the time integration)
  • Modified SolutionManager to
    • provide DxDp (not just x)
    • update vector spaces
  • Added interfaces to discretization for calling adaptivity
  • Moved AdvDiff test to corePDEs
  • Added a simple 1d adaptivity test for AdvDiff: starts with a mesh too coarse (hence, solution oscillates), then refines the mesh to get a stable solution.
  • Added a simple adaptivity for STK 1d meshes. If user requested it, we refine the 1d mesh if the solution oscillates AND an approx of the hessian is large enough. This check really only works with 1 MPI rank, so should not be used in general. It was just for the unit test. I could do a few mods for the partitioned case, but didn't want to spend too much effort, since we really won't be doing adaptivity with STK meshes...

@bartgol bartgol requested review from cwsmith and mperego January 10, 2025 22:57
@@ -389,6 +392,16 @@ class AbstractDiscretization
const bool overlapped = false,
const bool force_write_solution = false) = 0;

// Check if mesh adaptation is needed, and if so what kind (topological or just mesh-movement)
virtual Teuchos::RCP<AdaptationData>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm thinking I may change this. Namely, this may just return an AdaptationType enum. The reason is that instead of doing

auto data = disc->checkForAdaptation(x,xdot,xdotdot,dxdp);
if (data->type!=None) {
  disc->adapt(data);
}

We could just do

auto type = disc->checkForAdaptation(x,xdot,xdotdot,dxdp);
if (type!=None) {
  disc->adapt(x,xdot,xdotdot,dxdp);
}

without forcing the disc to stuff the OLD x/xdot/xdotdot/dxdp inside the returned type (the caller site already has them anyways).

@@ -54,6 +54,9 @@ class AbstractMeshFieldAccessor
virtual void fillSolnMultiVector (Thyra_MultiVector& soln,
const dof_mgr_ptr_t& sol_dof_mgr,
const bool overlapped) = 0;
virtual void fillSolnSensitivity (Thyra_MultiVector& dxdp,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This, and all the dxdp changes in the PR, are so that we can run a pb that computes sensitivities and do adaptation. I haven't tested the dxdp functionality though, so more work may be needed down the road.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant