[petsc-users] TS question 1: how to stop explicit methods because they do not use SNES(VI)?

[Barry Smith]

> On Feb 14, 2017, at 9:36 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> 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
> 

 Ok, great examples! Are there any commonalities that can be leveraged in a better TS API than we currently have? Since there are these "families" of potential splittings can't we do better than saying "oh, that is all up to the (often naive and inexperienced) user"? Like the old days of the "templates" book, since there are a bunch of confusing, overlapping families of Krylov methods and preconditioners we'll just write a book instead of writing code? I'm not saying that my API is the best or even good but surely we can do better than just leaving it to the users. AND, of course, since I don't care about backward compatibility :-) what we do for an API now can evolve over time as we better understand what should be represented in the API and what shouldn't?



> 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.

  Ok, then where is the equation of state in TS? Since it is a universal abstraction ("every one"), according to you, why isn't it represented in TS? What else should TS have that is common to many simulations?