dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Aug 31, 2005 at 06:56:06PM +0200, Garth N. Wells wrote:
> 
> Quoting Anders Logg <logg@xxxxxxxxx>:
> 
> > On Tue, Aug 23, 2005 at 08:28:32PM +0200, Garth N. Wells wrote:
> > > Attached are some patch files which, if they could be added to Dolfin,
> > would be
> > > really useful for me. They involve:
> > > 
> > > 1) Time-dependent boundary conditions (BoundaryCondtion.cpp_patch
> > > and BoundaryCondtion.h_patch). I've done this in the same way as
> > > it's done for a function. It might be nice in the future if the time
> > > could be more globally available.
> > 
> > One possibility would be to add the time as an argument to operator()
> > in BoundaryValue:
> > 
> >     virtual const BoundaryValue operator() (const Point& p, real t);
> > 
> > but that would require FEM::assemble() to know the time.
> > 
> > The current implementation (your patch) has the advantage that it
> > works in the same way as the Function class. In both cases, a Function
> > or a BoundaryValue represents a field on a mesh at a given time
> > t. It's not a function of time, but rather a sample at a given time so
> > the user needs to explicitly change the time.
> > 
> 
> A nicer implementaion would be to somehow have the time available for all
> objects. The danger now is that time time might be updated for a particular
> object and not for another.

Tell me if you have any suggestions (other than putting real t in the
global namespace).

Maybe we could add to BoundaryCondition and Function a member function
that can be called to connect any object to a given real t. Something
like

class Function
{
public:

    void synchronize(const real& t)
    {
       this->t = &t;
    }

private:

    const real* t;

}

Then in a time-stepping loop, one can keep a variable t and do

    t += k;

and all synchronized Functions and BoundaryConditions will be
automatically updated.

In addition, one could create a base class Synchronizable and put the
functionality in there so we don't have to duplicated. Then Function
and BoundaryCondition just inherit from Synchronizable.

> > > 2) Computing eigenvalues of a matrix directly using PETSc
> > > (GMRES.cpp_patch and GMRES.h_patch). The function replaces the usual
> > > "solve". It solves the system and returns n eigenvales in two
> > > Vectors - one for the real component and one for the complex
> > > component. I haven't added a version for virtual matrices.
> > 
> > I think this looks a little strange, a function that both solves the
> > system and computes eigenvalues. Looks like these two computations are
> > carried out independently, so maybe they should be two separate
> > functions?
> 
> A new class would be nicer. The reason I mades it a PETSc seems to require a
> solve before being able to compute the eigenvalues. I'll make a new class that
> computes the eigenvalues given a matrix and returns the result in two vectors.
> If necessary, I'll just solve a system with a trivial RHS to compute the
> eigenvalues. 

Sounds good, perhaps something like

class EigenSolver // or any other suitable name, should be intuitive
{
public:

    static void eig(const Matrix& A, Vector& l, uint n); // or solve() ?

}

Then one can do

EigenSolver::eig(A, l);

or perhaps just eig(A, l) if we make a shortcut.

/Anders

> > 
> > Maybe a new class for computing eigenvalues?
> > 
> > A related question: should we put some shortcuts for some of the basic
> > operations in the dolfin namespace, like
> > 
> >   dolfin::solve(A, x, b)
> >   dolfin::eig(A, l, n)
> >   dolfin::assemble(a, A, mesh)
> > 
> > or should we add easy access as member functions:
> > 
> >   A.solve(x, b)
> >   A.eig(l, n)
> > 
> > Or both?
> > 
> > /Anders
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/