Barry Smith <[email protected]> writes: > The function below absolutely should not be called TSComputeIFunction()! It > does not just compute IFunction()
How is this different than SNESComputeFunction subtracting off the RHS? > The current code entangles too much of the user API to the methods, this can > be fixed. I agree that the logic/naming is perhaps too overloaded. >> If the user experiments with different ways of splitting the solution they >> would have to define RHS and IF or RHS and LHS in different ways (according >> to the splittings they experiment with). It may look disgusting, but I don't >> see another way around it unless you allow for a list of operators to be >> defined and then the user to assign them to LHS or RHS. > > Jed suggested having any number of "RHS" functions. I don't think we need > more than 2, 1 for left hand side and 1 for right. If that ends up being not > enough we can change to have any number of them. Just to be clear. I suggest > three functions > > IFunction which defaults to u_t plus TSSetMassMatrix() which changes the > default IFunction to M u_t > LHS function which defaults to 0, if provided defaults to being treated > implicitly by IMEX > RHS function which defaults to 0, if provided defaults to being treated > explicitly by IMEX Are you trolling me? Reactive fluid-structure interaction: 1. fluid splitting to isolate the acoustic wave (stiff) 2. fluid containing everything but the acoustic wave (non-stiff) 3. fast reactions 4. slow reactions 5. structure Note that when using conservative variables, every one of these splits requires evaluation of the equation of state (reactions rate coefficients depend on Temperature, structure boundary condition requires pressure and shear stress). This doesn't even have viscoelastics, sedimentation, or a turbulence model.
signature.asc
Description: PGP signature
