> On Feb 11, 2015, at 8:32 PM, Dmitry Karpeyev wrote:
>
> Hong, I could stop by your office tomorrow to chat a bit more about the
> "funky system" I'm talking about.
> Is tomorrow good for you?
> Dmitry.
>
> On Wed Feb 11 2015 at 8:30:47 PM Hong Zhang wrote:
> This is a good heads-up for me.
Hong, I could stop by your office tomorrow to chat a bit more about the
"funky system" I'm talking about.
Is tomorrow good for you?
Dmitry.
On Wed Feb 11 2015 at 8:30:47 PM Hong Zhang wrote:
> This is a good heads-up for me. Actually I wanted that our adjoint models
> could handle forward integr
This is a good heads-up for me. Actually I wanted that our adjoint models could
handle forward integrations like this:
TSSolve(ts,u);
TSStep(ts);
TSSolve(ts,u);
Then the reverse run would look like:
TSAdjointSolve(ts);
TSAdjointStep(ts);
TSAdjointSolve(ts);
This flexibility should be very use
On 2/8/15 8:41 PM, Barry Smith wrote:
I never said remove TSStep() or make it completely private. I just want to
limit its use to when it is really needed by the user.
Then, how about we move TSSetSolution from beginner to intermediate or
lower level (the same level where we have TSStep
If the number of degrees of freedom do not change and they have essentially
the same "meaning" regardless of which process they are on then we can "hide"
inside the Vec object (and Mat object) the fact that they move around between
processors so TS shouldn't care.
BUT note that if the user
This is a bit off-topic, but I'm dealing exactly with this sort of "funky
system" -- particles+field.
Since degrees of freedom do move between processors, it's unclear how it
fits into the current
TS framework short of rebuilding the TS every timestep. That's a bit
inconvenient, since now I
have to
> On Feb 8, 2015, at 8:11 PM, Jed Brown wrote:
>
> Barry Smith writes:
>> Why can't TS handle that? Users always prefer to use the lowest
>> level thing available, that doesn't mean it is right.
>>
>> In the language of TS what does a "funky system, liked mixed
>> particle-field," mean
Barry Smith writes:
>Why can't TS handle that? Users always prefer to use the lowest
>level thing available, that doesn't mean it is right.
>
>In the language of TS what does a "funky system, liked mixed
>particle-field," mean, does it require a little more API on our
>side? I'
> On Feb 8, 2015, at 7:48 PM, Jed Brown wrote:
>
> Barry Smith writes:
>> Why would a user want to do TSStep() instead of calling TSSolve()?
>
> The user is stepping a funky system, liked mixed particle-field, and
> prefer to roll a loop instead of inject all their logic into a bunch of
> ca
Barry Smith writes:
>Why would a user want to do TSStep() instead of calling TSSolve()?
The user is stepping a funky system, liked mixed particle-field, and
prefer to roll a loop instead of inject all their logic into a bunch of
callbacks.
signature.asc
Description: PGP signature
> On Feb 8, 2015, at 12:12 PM, Emil Constantinescu wrote:
>
> On 2/6/15 9:35 PM, Jed Brown wrote:
>> Barry Smith writes:
>>>I am not proposing removing the solution from TSSolve() argument
>>>list, far from it. I am proposing removing the TSSetSolution(),
>>>keeping the solution in
On 2/6/15 9:35 PM, Jed Brown wrote:
Barry Smith writes:
I am not proposing removing the solution from TSSolve() argument
list, far from it. I am proposing removing the TSSetSolution(),
keeping the solution in TSSolve() as the standard approach, but
also allowing a callback for w
On Sat, Feb 7, 2015 at 11:00 AM, Barry Smith wrote:
>
> Hmm, we should definitely debug this because SNESComputeFunction()
> should be usable as a stand-alone function. In a quick look at the code I
> cannot see why a SNESSetSolution() call should be needed, nor would I want
> it to be needed i
Hmm, we should definitely debug this because SNESComputeFunction() should be
usable as a stand-alone function. In a quick look at the code I cannot see why
a SNESSetSolution() call should be needed, nor would I want it to be needed in
order to use SNESComputeFunction(). How can I reproduce y
On Fri, Feb 6, 2015 at 9:35 PM, Jed Brown wrote:
> Barry Smith writes:
> >I am not proposing removing the solution from TSSolve() argument
> >list, far from it. I am proposing removing the TSSetSolution(),
> >keeping the solution in TSSolve() as the standard approach, but
> >also
Barry Smith writes:
>I am not proposing removing the solution from TSSolve() argument
>list, far from it. I am proposing removing the TSSetSolution(),
>keeping the solution in TSSolve() as the standard approach, but
>also allowing a callback for when the user wants the DM passed to
> On Feb 6, 2015, at 9:28 PM, Jed Brown wrote:
>
> Barry Smith writes:
>> Nonsense. They could always put the initial conditions in an
>> appropriate vector and the callback just be a vec copy, then you get
>> back the effect of TSSet"Initial"Solution()
>
> How is that simpler or clearer th
Barry Smith writes:
> Nonsense. They could always put the initial conditions in an
> appropriate vector and the callback just be a vec copy, then you get
> back the effect of TSSet"Initial"Solution()
How is that simpler or clearer than passing it as an argument to
TSSolve? I didn't say it'
> On Feb 6, 2015, at 9:16 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Feb 6, 2015, at 8:59 PM, Jed Brown wrote:
>>>
>>> Barry Smith writes:
So going back to my email, now with more clarity, do we get rid of
the XXXSetSolution/RightHandSide() paradigm; this would void
>
Barry Smith writes:
>> On Feb 6, 2015, at 8:59 PM, Jed Brown wrote:
>>
>> Barry Smith writes:
>>> So going back to my email, now with more clarity, do we get rid of
>>> the XXXSetSolution/RightHandSide() paradigm; this would void
>>> questions like Mark's about what the differences are b
> On Feb 6, 2015, at 8:59 PM, Jed Brown wrote:
>
> Barry Smith writes:
>> So going back to my email, now with more clarity, do we get rid of
>> the XXXSetSolution/RightHandSide() paradigm; this would void
>> questions like Mark's about what the differences are between
>> them**. But do
Barry Smith writes:
>So going back to my email, now with more clarity, do we get rid of
>the XXXSetSolution/RightHandSide() paradigm; this would void
>questions like Mark's about what the differences are between
>them**. But do we lose any useful functionality?
I think the main po
> On Feb 6, 2015, at 7:58 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Feb 6, 2015, at 12:28 PM, Mark Adams wrote:
>>>
>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSolve.html#TSSolve
>>>
>>> The TSSolve web page does not have an output parameter. It is not
Barry Smith writes:
>I note that with the current code if you run TSSolve() with
>TS_EXACTFINALTIME_INTERPOLATE and then another TSSolve to continue
>solving for later time it actually uses the "interpolated" value as
>the starting point for the next solve (and not the final solut
Barry Smith writes:
>> On Feb 6, 2015, at 12:28 PM, Mark Adams wrote:
>>
>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSolve.html#TSSolve
>>
>> The TSSolve web page does not have an output parameter. It is not clear to
>> my why you would use TSSetSolution. Is there an
I note that with the current code if you run TSSolve() with
TS_EXACTFINALTIME_INTERPOLATE and then another TSSolve to continue solving for
later time it actually uses the "interpolated" value as the starting point for
the next solve (and not the final solution of the previous TSSolve()). Is
> On Feb 6, 2015, at 12:28 PM, Mark Adams wrote:
>
> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSolve.html#TSSolve
>
> The TSSolve web page does not have an output parameter. It is not clear to
> my why you would use TSSetSolution. Is there any difference between using
27 matches
Mail list logo
