Ed Bueler writes:
> Jed --
>
>> My point was that including sliding potentially adds another
>> stiff/algebraic term so whatever interface we choose better be able to
>> support at least two stiff terms.
>
> Yes, totally agreed w.r.t. the interface design. (The DAE that you are
> solving in that
Jed --
> My point was that including sliding potentially adds another
> stiff/algebraic term so whatever interface we choose better be able to
> support at least two stiff terms.
Yes, totally agreed w.r.t. the interface design. (The DAE that you are
solving in that case is stiff.)
However, *my*
Ed Bueler writes:
> Jed --
>
>>> u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)
>>Are you also interested in the case with sliding?
>
> You must be getting grumpy. There is this 2009 paper about sliding ...
> Yes I am interested in sliding but I was trying to keep things simple for
> you. ;-)
> On Feb 14, 2017, at 11:59 PM, Emil Constantinescu
> wrote:
>
> We seem to be needing more than two components and ways to pack them.
> Allowing them to be dynamically assigned at run time would be really cool.
>
> We seem to like an API that allows us to specify M and u_t; but would also
>
We seem to be needing more than two components and ways to pack them.
Allowing them to be dynamically assigned at run time would be really cool.
We seem to like an API that allows us to specify M and u_t; but would
also like to keep support for f(t,u,u_t)=0.
How about a costly experiment: bui
> 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 TSSet
Jed --
>> u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)
>Are you also interested in the case with sliding?
You must be getting grumpy. There is this 2009 paper about sliding ...
Yes I am interested in sliding but I was trying to keep things simple for
you. ;-)
The code in question is an under
"Zhang, Hong" 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.
Noo! That would prevent solving problems with moving meshes or with
transient statements written in terms of dependent va
On Feb 14, 2017, at 9:20 PM, Barry Smith
mailto:bsm...@mcs.anl.gov>> wrote:
On Feb 14, 2017, at 8:56 PM, Emil Constantinescu
mailto:emcon...@mcs.anl.gov>> wrote:
On 2/14/17 4:10 PM, Barry Smith wrote:
Ok, you don't recompile but forcing that into user code is still disgusting.
With my api t
Barry Smith writes:
>> On Feb 14, 2017, at 9:36 PM, Jed Brown wrote:
>> 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 example
> On Feb 14, 2017, at 9:56 PM, Jed Brown wrote:
>
> Ed Bueler writes:
>> Your question makes me think about why I am splitting the way I am. For
>> sure *yes*, in my case they are separate terms and *no* I am not just
>> subtracting Lu from both sides.
>>
>> The ice sheet thickness problem (u
Ed Bueler writes:
> Your question makes me think about why I am splitting the way I am. For
> sure *yes*, in my case they are separate terms and *no* I am not just
> subtracting Lu from both sides.
>
> The ice sheet thickness problem (u(t,x,y) >= 0 is thickness) is like
> degenerate p-bratu, righ
> On Feb 14, 2017, at 9:36 PM, Jed Brown wrote:
>
> Barry Smith 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 ent
Barry Smith 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 fix
> On Feb 14, 2017, at 8:56 PM, Emil Constantinescu wrote:
>
> On 2/14/17 4:10 PM, Barry Smith wrote:
>> Ok, you don't recompile but forcing that into user code is still
>> disgusting. With my api the user code is
>>
> TSSetRHSFunction(ts,NULL,RHSFunction,&ptype[0]);
> TSSetLHSFunctio
On 2/14/17 4:10 PM, Barry Smith wrote:
Ok, you don't recompile but forcing that into user code is still disgusting.
With my api the user code is
TSSetRHSFunction(ts,NULL,RHSFunction,&ptype[0]);
TSSetLHSFunction(ts,NULL,LHSFunction,&ptype[0]);
TSSetRHSJacobian(ts,Jac,Jac,RHSJacobian,&ptyp
Jed --
> Yup, this is the form I have,
> >u_t - f(u) = g(u)
> Are these really separate terms? As I mentioned, a very common case is
> to write
> u_t - L u = f(u) - L u
> where L is some stiff part of the operator (linear or non). This is
> common for stiff waves in fluid problems or stiff
> On Feb 14, 2017, at 3:18 PM, Emil Constantinescu wrote:
>
>
>
> On 2/14/17 3:04 PM, Barry Smith wrote:
>>
>>> On Feb 14, 2017, at 2:55 PM, Emil Constantinescu
>>> wrote:
>>>
>>> On 2/14/17 2:33 PM, Zhang, Hong wrote:
I think many users (including me) would like to start with academi
On 2/14/17 3:04 PM, Barry Smith wrote:
On Feb 14, 2017, at 2:55 PM, Emil Constantinescu wrote:
On 2/14/17 2:33 PM, Zhang, Hong wrote:
I think many users (including me) would like to start with academic examples,
e.g. u_t=f(u)+g(u), when they try to learn PETSc TS solvers. This simple form
> On Feb 14, 2017, at 2:55 PM, Emil Constantinescu wrote:
>
> On 2/14/17 2:33 PM, Zhang, Hong wrote:
>> I think many users (including me) would like to start with academic
>> examples, e.g. u_t=f(u)+g(u), when they try to learn PETSc TS solvers. This
>> simple form allows for easy switch betwe
Criminy, that's disgusting. You implement options
-term1 rhs -term2 lhs ...
In your FormIFunction:
if (term1 == LHS) { ... }
and similarly in your FormRHSFunction.
On February 14, 2017 1:55:42 PM MST, Emil Constantinescu
wrote:
>On 2/14/17 2:33 PM, Zhang, Hong wrote:
>> I think many users (i
On 2/14/17 2:33 PM, Zhang, Hong wrote:
I think many users (including me) would like to start with academic examples,
e.g. u_t=f(u)+g(u), when they try to learn PETSc TS solvers. This simple form
allows for easy switch between all kinds of different integration methods.
Right, but then you can
I think many users (including me) would like to start with academic examples,
e.g. u_t=f(u)+g(u), when they try to learn PETSc TS solvers. This simple form
allows for easy switch between all kinds of different integration methods.
Experienced users or experts who need to solve DAEs or complicate
I think
> u_t = f(u) + g(u)
where one wishes to switch from fully implicit to imex to fully explicit
(with a likely small time-step constraint) is common enough that we should
support it (we don't currently). The reason is that users may not know which
form they should use and the eas
Barry Smith writes:
> Hence my suggestion to have TSSetLeftHandSideFunction() (or Jed's
> suggestion to have multiple Right Hand side functions) this will allow
> comparison of implicit, explicit, imex without recompiling (which we don't
> have currently) for the case with no mass matrix. Wit
> On Feb 14, 2017, at 6:53 AM, Matthew Knepley wrote:
>
> On Mon, Feb 13, 2017 at 3:59 PM, Zhang, Hong wrote:
>
>> On Feb 13, 2017, at 3:08 PM, Ed Bueler wrote:
>>
>> Barry --
>>
>> > Sounds like a bug to me. The methods should be checking if an
>> > IFunction is being provided and error
Matthew Knepley writes:
> I see that is it not one-to-one, but its a pattern I think a lot of people
> will want, and one of the most common
> things people ask is "when does implicit beat explicit?". We should think
> about ways to make this easier.
Note that one of the most common splittings is
On Tue, Feb 14, 2017 at 8:55 AM, Emil Constantinescu
wrote:
> On 2/14/17 6:53 AM, Matthew Knepley wrote:
>
>>
>> Explicit methods use only RHSFunction and ignore IFunction, so in
>> your case, if you change TS type to rk and ssp at run time, you are
>> actually solving u_t = G(t,u). I
On 2/14/17 6:53 AM, Matthew Knepley wrote:
Explicit methods use only RHSFunction and ignore IFunction, so in
your case, if you change TS type to rk and ssp at run time, you are
actually solving u_t = G(t,u). If RHSFunction is not provided, PETSc
will assume the RHS is zero (u_t=0
On Mon, Feb 13, 2017 at 3:59 PM, Zhang, Hong wrote:
>
> On Feb 13, 2017, at 3:08 PM, Ed Bueler wrote:
>
> Barry --
>
> > Sounds like a bug to me. The methods should be checking if an
> > IFunction is being provided and error out in that case.
>
> I don't think it is that simple. I.e. having a
On Feb 13, 2017, at 3:08 PM, Ed Bueler
mailto:elbue...@alaska.edu>> wrote:
Barry --
> Sounds like a bug to me. The methods should be checking if an
> IFunction is being provided and error out in that case.
I don't think it is that simple. I.e. having an IFunction and an explicit
scheme is
> On Feb 13, 2017, at 3:08 PM, Ed Bueler wrote:
>
> Barry --
>
> > Sounds like a bug to me. The methods should be checking if an
> > IFunction is being provided and error out in that case.
>
> I don't think it is that simple. I.e. having an IFunction and an explicit
> scheme is not, by its
Barry --
> Sounds like a bug to me. The methods should be checking if an
> IFunction is being provided and error out in that case.
I don't think it is that simple. I.e. having an IFunction and an explicit
scheme is not, by itself, a bug. I think.
If the user has provided IFunction
F(t,u,u
I think it just wasn't implemented. Note that these have custom code
because of the weighting vectors -- it isn't just a call to VecNorm.
Patches welcome.
Ed Bueler writes:
> Dear Petsc --
>
> This is the second of two short TS usage questions.
>
> I would like my TS, for MOL on a PDE based on
> On Feb 13, 2017, at 1:53 PM, Ed Bueler wrote:
>
> Dear Petsc --
>
> This is the first of two short TS usage questions.
>
> My problem is both stiff (diffusive PDE) and constrained, so I require
>
>-snes_type vinewton{rs|ss}ls
>
> *and* I split my ODE system into IFunction and RHSFuncti
Dear Petsc --
This is the second of two short TS usage questions.
I would like my TS, for MOL on a PDE based on a spatial grid (DMDA) of
course, to be tolerant of crap at a few locations. Thus I set
-ts_adapt_wnormtype 1
and I got a very clear error saying "Only 2-norm and infinite norm
suppor
Dear Petsc --
This is the first of two short TS usage questions.
My problem is both stiff (diffusive PDE) and constrained, so I require
-snes_type vinewton{rs|ss}ls
*and* I split my ODE system into IFunction and RHSFunction
F(t,u,u_t) = G(t,u)
where F(t,u,u_t) = u_t + f(t,u) in my case
On Thu, Feb 9, 2012 at 03:20, Boyce Griffith wrote:
> I was wondering if there was a reference for the time-stepping method
> implemented by TSARKIMEX2E?
Emil, is there something to cite yet?
Boyce, we are working on a paper with several new schemes and comparisons
of methods for a few applica
Hi, Folks --
I was wondering if there was a reference for the time-stepping method
implemented by TSARKIMEX2E?
Thanks!
-- Boyce
39 matches
Mail list logo
