Skip to content

Refactoring Self-Gravity and Static-Gravity #429

@mabruzzo

Description

@mabruzzo

Currently the standalone static-gravity solver and the self-gravity solver both support static gravitational potentials, but a lot of the machinery is effectively duplicated between both locations. When we have a moment, it would be nice to refactor the machinery to remove the duplication.

I have a few thoughts about this:

  1. I think it would be nice to create a file that is filled with struct/classes that describe the various choices of gravitational potentials. By doing this we can avoid duplicating the logic every time we need to use the logic (commonly, the logic is used to initialize initial conditions as well as for evolving fluids/particles). This already exists for the static potentials that can be used with the self-gravity solver.
  2. Ideally, handling of static-potentials should be handled completely independently from self-gravity. (I think this would involve adding some basic functionality to let the static-gravity module support particles).
  3. Ideally, the decision to use a static potential (and the choice of potential) could be determined at runtime. This might involve creating callback functions (we already do this for other kinds of source terms like cooling and feedback). A consequence is we would need to decouple the static-gravity source terms from the cell-update step in the hydro solver (I think we probably want to do this anyway to make the code easier to reason about).

Obviously, the above describes a lot of changes. We definitely don't need to do it all at once (in fact even just addressing thought 1 would be a significant improvement).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementrefactorfor code that is functional but needs to be refactored

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions