[petsc-users] Conditional Constraints

[Vijay S. Mahadevan]

> The stiff integrators in TS are intended for solving DAE. If you have
> consistent initial conditions, then TSGL should just work, perhaps after
> turning off error control or specifying your own controller (the built-in
> controllers are not robust at present). If you do not have consistent
> initial conditions, then they need to be solved for, which we don't
> currently have support for, but should be adding reasonably soon.

I saw from the documentation that the GL methods were capable of
handling DAE systems. But the intention of my question was about the
usage of the newton solver with functional constraints (with VI) for a
DAE since in a sense, the DAE systems are a composite of an ODE and a
constraint. So I was curious whether we could use temporal methods
that were not intended for DAEs but for stiff ODEs only and use the VI
solver to augment/restrict the solution with constraints. The reason
for this is due to the fact that in the creation of a stiff solver,
there are additional coefficient constraints that need to be satisfied
to be used for a DAE but this is less restrictive for solving ODEs.

But looking at the paper that Shri pointed out, this does not seem
like an option. I was probably just shooting in the dark there but it
just seemed like a neat idea.

Vijay

On Fri, Jul 29, 2011 at 4:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Mon, Jul 25, 2011 at 23:40, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>
>> I was also going to ask whether this can be used to solve a DAE by
>> decoupling it into a time dependent equation and an algebraic (functional)
>> constraint associated with it.
>
> The stiff integrators in TS are intended for solving DAE. If you have
> consistent initial conditions, then TSGL should just work, perhaps after
> turning off error control or specifying your own controller (the built-in
> controllers are not robust at present). If you do not have consistent
> initial conditions, then they need to be solved for, which we don't
> currently have support for, but should be adding reasonably soon.