When you have 2+ linear solves that can be solved sequentially, PRISMS-PF forces them to be nonlinear.
For example, $\Delta u=f$ as equation one and $\Delta q = u$ as the second. If solved, sequentially, both should be linear solves. However, due to the architecture of solveIncrement.cc and the equation dependency parser, it forces these to be nonlinear.
Part of reason for this is because computeNonexplicitRHS is done outside of the field index loop in solveIncrement.cc , only recomputing the RHS for nonlinear equations. A simple fix would be moving it into the field index loop and recompute for all nonexplicit equations. This would change the way nonExplicitEquationRHS works into something more like nonExplicitEquationLHS.
It would look something like this
if (this->currentFieldIndex == 0)
{
vectorvalueType u_star = variable_list.get_vector_value(0);
variable_list.set_vector_value_term_RHS(0, u_star );
}
else if (this->currentFieldIndex == 2)
{
scalargradType px = variable_list.get_scalar_gradient(2);
variable_list.set_scalar_gradient_term_RHS(2, -px);
}
When you have 2+ linear solves that can be solved sequentially, PRISMS-PF forces them to be nonlinear.
For example,$\Delta u=f$ as equation one and $\Delta q = u$ as the second. If solved, sequentially, both should be linear solves. However, due to the architecture of
solveIncrement.ccand the equation dependency parser, it forces these to be nonlinear.Part of reason for this is because
computeNonexplicitRHSis done outside of the field index loop insolveIncrement.cc, only recomputing the RHS for nonlinear equations. A simple fix would be moving it into the field index loop and recompute for all nonexplicit equations. This would change the waynonExplicitEquationRHSworks into something more likenonExplicitEquationLHS.It would look something like this