Forced nonlinearity for multiple linear solves

[landinjm]

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);
    }

[landinjm]

@david-montiel-t @fractalsbyx @wband This issue is bordering that line where we might start making major changes on the user end. How do we want to approach this?

Personally, I don't like the serial if statements that the user would have to make (I mean not necessarily because it we just recompute equations unnecessarily) since it feels unintuitive and sloppy. I feel like a better way to do this would be for the user to call some other function and do their math in that, calling it for each nonexplicit field.

I'm not exactly sure how it would work, but I want to hear your thoughts about how users should interact with PRISMS-PF

[landinjm]

Note that this dependence is warranted in #382.

[fractalsbyx]

My opinion is that using if-statements is still going to be the smoothest way we would be able to do this, however I think we should refactor out currentFieldIndex and make it a function argument rather than a class-scope variable.
(i thought i commented this a week ago, but i found it in an open tab)