Hello,Ben,
I change my libmesh to SVN code and the implicit part works well with
--implicit_neighbor_dofs on the command line,
the first step is much faster than libmesh0.62.
Thank you very much.
Kirk, Benjamin (JSC-EG) 写道:
> Can you try running the code with --implicit_neighbor_dofs on the
> c
On Mon, 19 May 2008, Nasser Mohieddin Abukhdeir wrote:
> John pointed this out too, all I can say is "oops," what meant to do was take
> the error from the last iteration of nonlinear solver which I think makes
> sense as an estimate of the LTE.
I'm not sure of that, either. The error on your
Roy Stogner wrote:
>
> On Mon, 19 May 2008, Nasser Mohieddin Abukhdeir wrote:
>
>>A while ago I mentioned something about the time stepping algorithm
>> employed by AdaptiveTimeSolver as being non-ideal for my PDE system. I
>> think I have implemented a very simple adaptive time solver based
On Mon, 19 May 2008, Nasser Mohieddin Abukhdeir wrote:
>A while ago I mentioned something about the time stepping algorithm
> employed by AdaptiveTimeSolver as being non-ideal for my PDE system. I
> think I have implemented a very simple adaptive time solver based on the
> local truncation e
On Mon, May 19, 2008 at 1:55 PM, Nasser Mohieddin Abukhdeir
<[EMAIL PROTECTED]> wrote:
> Hello:
>A while ago I mentioned something about the time stepping algorithm
> employed by AdaptiveTimeSolver as being non-ideal for my PDE system. I
> think I have implemented a very simple adaptive time s
Hello:
A while ago I mentioned something about the time stepping algorithm
employed by AdaptiveTimeSolver as being non-ideal for my PDE system. I
think I have implemented a very simple adaptive time solver based on the
local truncation error:
core_time_solver->du() / calculate_norm(_system
