On Thu, 18 Jun 2009 16:54:05 -0500, John Peterson <jwpeterson@...>
> On Thu, Jun 18, 2009 at 4:42 PM, Roy Stogner<roystgnr@...>
>> On Thu, 18 Jun 2009, Brent Kraczek wrote:
>>> Please let me know if you want anything changed.
>> We can ignore my criticisms if other developers disagree, but:
>> Doing matrix-based norms in LinearImplicitSystem rather than in
>> SparseMatrix doesn't make sense to me. Every LinearImplicitSystem
>> user can use a new SparseMatrix easily, but the converse is not true.
> Agree with Roy here.
I guess I was trying to not to go too deep into the library. But I can do
that. I also agree that it would be nice to define it for each different
linear algebra package, but I don't know if I have the time to figure it
out with each one.
>> is a little more involved than
>> but it would be a lot more flexible. At most, the latter call should
>> be a nicely named pseudonym that calls the former.
I can do that as well. I had written system.calc_sys_energy() first, and
then decided to write the other in order to test it with a uniform vector.
>> The only reason for I can see for the library rather than the user to
>> manage creation of an energy matrix is if we want the library itself
>> be able to make use of an energy norm. For example, we're now
>> standardizing on "adjoint_solution" as a vector name just so that
>> adjoint-based library infrastructure can know what it should access.
>> Are there circumstances in which we'd want the library itself to call
One of the main motivations I had for doing this in LinearImplicitSystem
was that the energy matrix was nearly the same as the main matrix. As
things stand right now, I don't know how to have the assemble function
access a matrix that is not a member of the EquationSystems object. I
suppose the energy matrix could be calculated in its own function, but that
would repeat a lot of the same code and operations as are used to build the
My other motivation was that, whether or not the library itself has other
uses for the system energy (you would know better than I), the energy is a
fairly common operation that I think would still have a place in a library
for use in external implementations. This is the most common energy to
calculate for a linear implicit system. I don't know about other
implementations equations the library is being used to solve.
>> Your tmpVec is serial; better would be to clone() the input vector so
>> as to avoid wasting memory when the input vector (e.g. the solution)
>> is parallel. Best still would be to directly calculate v'*A*v without
>> the temp vector, but that would require linear algebra package
>> specific implementations.
> Which I think is the right way to do it... whether we call it energy
> or whatever else, this should be a method of SparseMatrix which takes
> a NumericMatrix and returns a scalar. That way we do it once and for
> all, and we do it efficiently with specialized code or fall back on a
> generic implementation sitting in the base class.
That's fine I can do this.
> BTW, sorry I never got back to you on why we call
> libmesh_assert(this->closed()); at the beginning of operator=. Did
> you ever determine if that was actually necessary...?
It's not completely clear to me. I don't see a reason why it needs to be
closed beforehand (initialized, yes, closed no).