-
Notifications
You must be signed in to change notification settings - Fork 35
Open
Labels
enhancementrefactorfor code that is functional but needs to be refactoredfor code that is functional but needs to be refactored
Description
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:
- 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.
- 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).
- 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
Labels
enhancementrefactorfor code that is functional but needs to be refactoredfor code that is functional but needs to be refactored