"Zhang, Hong" <[email protected]> writes:
> It is a great idea to require IFunction to be M u_t or u_t. This
> allows us to eliminate the weird 'shift' parameter in the current
> interface. 

Noooooo!  That would prevent solving problems with moving meshes or with
transient statements written in terms of dependent variables, like

  d rho(pressure, momentum, temperature) / dt = div(momentum)

where (pressure, momentum, temperature) are the independent variables
but we want a statement of conservation.  There are important all-speed
flow formulations that look like this.

> But the LHS function would be as confusing as the old
> IFunction. Apparently it can be moved to the right hand side. So why
> don't we use
>
> IFunction
> RHS function 1 / RHSJacobian 1
> RHS function 2 / RHSJacobian 2
> ... (and more if needed)
>
> Also we can add command line options to control which RHS terms should be 
> treated explicitly/implicitly, e.g.,
> IMEX: -ts_implicit rhs1 -ts_explicit rhs2
> fully implicit: -ts_implicit rhs1,rhs2
> explicit: -ts_explicit rhs1,rhs2

If you want multiple RHS, then make TSPushRHSFunction(ts, "fname", ...);

Put these in a linked list, add

  -ts_rhs_implicit foo,bar,qux

Then TSComputeIFunction walks the list and evaluates anything that was
named while TSComputeRHSFunction evaluates everything else.

Attachment: signature.asc
Description: PGP signature

Reply via email to