Well what I gave you was non optimal for sure... And not exactly what
we have implemented... But there will always be some overhead with
this scheme. We get away with it by caching references/pointers to
the data and only updating them when necessary. Also you don't have
to use maps. You
On Fri, 9 Jan 2009, Derek Gaston wrote:
> (Sorry if you get multiples I was having trouble sending it)
In an odd coincidence, one thing I don't like about your idea is the
inefficiency. ;-)
It sounds like you've got a pretty good solution for some cases, but
it won't work for my user appli
Let's see... we _do_ have a similar situation in one part of our
code and one solution is instead of storing data as member
variables of a class store them in containers in that class
that way there is one interface... but any of the derived objects can
provide whatever data the
(Sorry if you get multiples I was having trouble sending it)
Let's see... we _do_ have a similar situation in one part of our code
and one solution is instead of storing data as member variables of a
class store them in containers in that class that way there is one
interface... bu
To enable a bit more modularity, automatic multithreading, etc., as
I've mentioned before, I'd like to change the DiffSystem/FEMSystem
interface.
Right now, the library has methods like:
DiffSystem::element_residual()
Which, overridden by the user, can access DiffSystem member variables
with st
On Fri, Jan 9, 2009 at 4:07 PM, David Knezevic wrote:
> Hi all,
>
> I am doing some eigenvalue computations (using the SLEPc interface in
> libMesh) on matrices assembled from a PDE with a Dirichlet boundary
> condition, and in this situation the penalty method that is typically
> used in libMesh
Hi all,
I am doing some eigenvalue computations (using the SLEPc interface in
libMesh) on matrices assembled from a PDE with a Dirichlet boundary
condition, and in this situation the penalty method that is typically
used in libMesh is not very good because the penalty term messes up the
matrix
