Skip to content

Conversation

@chvillanuevap
Copy link
Member

Adds infrastructure to support higher-order time integration and multiphysics coupling:

  • Backward Differentiation Formula (BDF) time integrator.
  • Field extrapolation utility for multi-step schemes.
  • Tensor utility functions to support physics modules.

- Improved styling of residual norm output.
- Added a fixed-step Backward Differentiation Formula (BDF) integrator.
- Introduced an extrapolator operator for approximating fields using previous values.
- Added tensor utilities to compute rank and shape, and to copy tensors for vectors.
- Extended BasePhysics with:
  - Functions to compute absolute and relative state changes in time.
  - A method to retrieve checkpointed time for a given cycle.
  - A method to access previous steps by cycle index.
@chvillanuevap chvillanuevap requested review from btalamini and tupek2 May 31, 2025 06:17
@chvillanuevap chvillanuevap self-assigned this May 31, 2025
}

::std::vector<::serac::FiniteElementState>
BasePhysics::getPreviousStates(
Copy link
Collaborator

Choose a reason for hiding this comment

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

what is this for? we are really trying to get away from this type of thing with the new design.

*
* @tparam r_order The desired extrapolation order (0 = zero, 1 = constant, 2 = linear).
*/
template <int r_order>
Copy link
Collaborator

Choose a reason for hiding this comment

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

what is the point of templating this? Is there some performance optimization. If not, I'd suggest just having it be a constructor argument or and input to the () operator. In term, the details should be implemented in a .cpp file.

*/
virtual double getCheckpointedTimestep(int cycle) const;

/**
Copy link
Collaborator

@tupek2 tupek2 Jun 2, 2025

Choose a reason for hiding this comment

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

As a general rule: The base_physics interface exists as a public API for external use. At the moment, that external use is in LiDO. Do these newly added functions need to be called by LiDO for your new physics to work? If so, I'd like to understand that. If LiDO does not need to call these functions directly, they should be implementation details of your particular physics so that we do not bloat the base_physics interface even more.

*
* @return The absolute L2 norm of the difference: || u^k - u^{k-1} ||.
*/
double
Copy link
Collaborator

Choose a reason for hiding this comment

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

Operations like this, that may be reused by other physics, should be provided in, e.g., numerics, as a free function. Once again, we don't want to expand the public base_physics interface when its not strictly required.

template <typename T, int... n>
SERAC_HOST_DEVICE int constexpr
rank(
::serac::tensor<T, n...> const &
Copy link
Collaborator

Choose a reason for hiding this comment

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

stylistically, we don't really do the pre :: for ::serac or ::std in serac. I'd argue its best to keep the style consistent, even though its not enforced by our style guide.

*/
SERAC_HOST_DEVICE constexpr auto inner(double A, double B) { return A * B; }

/**
Copy link
Collaborator

Choose a reason for hiding this comment

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

These are confusing me (inner products with zeros). I thought they were already in the repo? I cannot figure out why its showing up here as a change.

@chvillanuevap chvillanuevap force-pushed the feature/hernan/chm branch 2 times, most recently from 22efa49 to 6482079 Compare July 14, 2025 20:20
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.

3 participants