Open nilsdeppe opened 3 years ago
remove the old boundary communication and related code and actions. Some of these might be getting moved to the elliptic directory.
I'm preparing a PR that makes the elliptic DG operator independent of these, so they can just be deleted.
There are a lot of things that will need to be removed or cleaned up once the evolution code changes are complete. I'll use this issue to try and keep track of them all, but I'm sure I'll miss some.
Domain/boundary conditions
A list of things to clean up in domain, domain creators, etc. once boundary conditions are fully supported in the code. Since they're currently treated optionally to avoid breaking existing code there are cleanups and improvements to be done.
periodic_in
options in the domain creators. While we want to support creating a domain without boundary conditions for things like ExportCoordinates or a future ApplyObservers executable, these domains probably shouldn't be periodic either since the executables should just perform pointwise operations.nullptr
ERROR
in theBlock
constructor that is currently commented outboundary_conditions
inBlock
andDomain
constructorsTestHelpers::domain::BoundaryConditions::MetavariablesWithoutBoundaryConditions
since all domain creators will require boundary conditions~ We might want this since being able to construct a domain without boundary conditions is something people want.if (boundary_condition_ != nullptr)
checks increate_domain
functions of domain creators, since they all will require boundary conditions to be specified. Some exceptions might be necessary here for periodic domains.ImposeBoundaryConditions
action(s) and associated codeis_periodic_in
arguments, thenAlignedLattice
should useAlternative
options forIsPeriodicIn
andBlocksToExclude
instead of handling that as aPARSE_ERROR
MarkAsNone
out of the detail namespaceVolumeTermsImpl.tpp
andBoundaryConditionsImpl.hpp
Core evolution
Some cleanup not directly related to boundary conditions but that will be possible:
InitializeInterfaces
andInitializeMortars
action. This also depends on projecting the normal vectors/Jacobians to the boundaries, which is necessary to support weak+Gauss points with metric-identity satisfying Jacobians anyway.char_speeds_compute_tag
andchar_speeds_tag
from the system classes. Several will then no longer depend on the equation of state type, and just the thermodynamic dimension