>> Oh, my mistake, I just needed to add system.mesh_position_set() after
>> system.time_solver->advance_timestep(). It works nicely now, cool!
>
> No, that's not your mistake, that's mine - mesh_position_set() ought
> to be handled transparently by the library. The trick is trying to
> figure out h
On Tue, 11 May 2010, Roy Stogner wrote:
> You've still got a CFDLab login, right? Check out
> ~roystgnr/pecos/ale/doc/paper.pdf for some discussion of the problem.
Yikes - glancing at that doc again reminded me of the last remaining
problem: many of our finite element types depend on geometric
On May 11, 2010, at 3:01 PM, Roy Stogner wrote:
>
>
> On Tue, 11 May 2010, David Knezevic wrote:
>
So now I'm getting mesh motion, though if GMV is to be believed it's
only the outermost layer of elements that are moving. I'll have a
closer look at what's happening...
>>>
>>> T
On Tue, 11 May 2010, David Knezevic wrote:
>> Oh, my mistake, I just needed to add system.mesh_position_set() after
>> system.time_solver->advance_timestep(). It works nicely now, cool!
>
> One last post about this: I guess you didn't expect the numerical jacobian
> verification to work with mes
On Tue, 11 May 2010, David Knezevic wrote:
>>> So now I'm getting mesh motion, though if GMV is to be believed it's
>>> only the outermost layer of elements that are moving. I'll have a
>>> closer look at what's happening...
>>
>> Thanks!
>
> Oh, my mistake, I just needed to add system.mesh_pos
> Oh, my mistake, I just needed to add system.mesh_position_set() after
> system.time_solver->advance_timestep(). It works nicely now, cool!
One last post about this: I guess you didn't expect the numerical
jacobian verification to work with mesh motion? When I turned the
numerical jacobian veri
>> So now I'm getting mesh motion, though if GMV is to be believed it's
>> only the outermost layer of elements that are moving. I'll have a
>> closer look at what's happening...
>
> Thanks!
Oh, my mistake, I just needed to add system.mesh_position_set() after
system.time_solver->advance_timestep
On Tue, 11 May 2010, David Knezevic wrote:
> On 05/11/2010 12:44 PM, Roy Stogner wrote:
>>
>> So it's asserting that the solution vector hasn't been closed after
>> the solve? That mesh_position_get() call would have unclosed the
>> solution vector, but the solver should have closed it again.
>
On 05/11/2010 12:44 PM, Roy Stogner wrote:
>
> Copying to libmesh-devel; I know Ben's interested in the state of ALE
> too.
>
> On Tue, 11 May 2010, David Knezevic wrote:
>
>> I had a bit of spare time yesterday, so I thought I'd have another
>> look at some mesh motion in FEMSystem. The API seem
On Tue, 20 Apr 2010, Roy Stogner wrote:
> On Tue, 20 Apr 2010, Kirk, Benjamin (JSC-EG311) wrote:
>
>> I have no problem using the approach where we can, provided we don't
>> blow away the current capability for dealing with makefile-less
>> petsc installations.
>
> I was actually suggesting using
Copying to libmesh-devel; I know Ben's interested in the state of ALE
too.
On Tue, 11 May 2010, David Knezevic wrote:
> I had a bit of spare time yesterday, so I thought I'd have another look at
> some mesh motion in FEMSystem. The API seems simple enough: I've added two
> extra isoparametric
11 matches
Mail list logo
