You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both essential and natural BCs are added (using PetscDSAddBoundary_UW) in the setup_discretisation method defined in petsc_generic_snes_solvers.pyx. In turn, the setup_discretisation method is called in build (or rebuild_after_mesh_update) function. This build function is then called in the solve functions defined in the generic solvers. However, setup_discretisation is also called in the solve of the child classes (e.g. SNES_AdvectionDiffusion). This results to duplicate addition of the essential and natural BCs.
Is this okay?
The text was updated successfully, but these errors were encountered:
We got a bit tied in knots with how the solver classes inherit functionality. They should not both be adding boundary conditions in this way though. I'm assigning @julesghub to clarify if there is a deliberate choice in here or a misunderstanding
There was a problem with the default naming of solvers which meant they were not respecting each other's namespace. Falling back to always numbering the solvers in a generic way (less error checking, fewer chances for user error).
Both essential and natural BCs are added (using
PetscDSAddBoundary_UW
) in thesetup_discretisation
method defined in petsc_generic_snes_solvers.pyx. In turn, thesetup_discretisation
method is called inbuild
(orrebuild_after_mesh_update
) function. Thisbuild
function is then called in thesolve
functions defined in the generic solvers. However,setup_discretisation
is also called in thesolve
of the child classes (e.g. SNES_AdvectionDiffusion). This results to duplicate addition of the essential and natural BCs.Is this okay?
The text was updated successfully, but these errors were encountered: