Re: [Libmesh-users] update bounds based on old_local_solution

[Dmitry K. <ka...@mc...>]

One way to solve this problem while ensuring type safety (or at least get
rid of the need for dynamic casts)
is to attach all callbacks directly to the system, which wouldn't know
anything about the solver.
The solver then would have a reference to NonlinearImplicitSystem and
forward all PETSc callbacks to it.
That, however, would be a substantial design change.  In particular, the
user would have to
instantiate a solver with a given system and call solver.solve() instead of
system.solve().

Dmitry.

On Tue, Aug 7, 2012 at 11:06 AM, Roy Stogner <roy...@ic...>wrote:

>
> On Tue, 7 Aug 2012, Ataollah Mesgarnejad wrote:
>
> >> TransientNonlinearImplicitSystem& realsys =
> >>  libmesh_cast_ptr<TransientNonlinearImplicitSystem&>(sys);
> >>
> >
> > This didn't work and gave a not matching function error. However:
> >
> > TransientNonlinearImplicitSystem& realsys =
> dynamic_cast<TransientNonlinearImplicitSystem&>(sys);
> >
> > worked.
>
> My mistake - I meant libmesh_cast_ref, not libmesh_cast_ptr.
>
> dynamic_cast will definitely work here.  libmesh_cast_* does a
> dynamic_cast and tests the result when you're in debug/devel modes,
> and in opt mode does a static_cast and assumes the result is valid
> (it's for cases like this where the result always will be valid).
> ---
> Roy
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>