On Tue, Oct 21, 2008 at 1:54 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John,
>
> What I mean is that SparseMatrix has all the functionality that ShellMatrix
> requires plus a lot of extra functionality. If we had a MatrixBase as Roy
> suggests, then what would be the additional functionali
Dear John/Roy/all,
Another question pops up in connection with my ShellMatrix, in
particular with the vector v and w that form a TensorShellMatrix.
When I assemble v and w (where the matrix B = v w'), I certainly have
to call something similar to DofMap::constrain_element_matrix(), but
I'm not
Dear John,
On Tue, 21 Oct 2008, Tim Kroeger wrote:
> On Mon, 20 Oct 2008, John Peterson wrote:
>
>> This one I disagree with. Inheritance should always follow the "is a"
>> organizational semantic, and a SparseMatrix (as we now define it) is
>> most definitely *not* a ShellMatrix.
>
> Nor is a S
Dear John,
On Mon, 20 Oct 2008, John Peterson wrote:
>> Also, I would suggest to derive SparseMatrix from ShellMatrix rather than
>> vice versa. This could actually make SparseShellMatrix unnecessary. This
>> is of course an advantage of the unification.
>
> This one I disagree with. Inheritan
On Oct 20, 2008, at 10:23 AM, Roy Stogner wrote:
> Because SparseMatrix is-not-a ShellMatrix (doesn't need to attach or
> even acknowledge the existance of a user's matvec shell function), and
> ShellMatrix is-not-a SparseMatrix (doesn't need sparsity pattern
> details in the constructor, can't ret
On Mon, 20 Oct 2008, John Peterson wrote:
> On Mon, Oct 20, 2008 at 11:14 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
Also, I would suggest to derive SparseMatrix from ShellMatrix rather than
vice versa. This could actually make SparseShellMatrix unnecessary.
This
is of cour
On Mon, Oct 20, 2008 at 11:14 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>>> Also, I would suggest to derive SparseMatrix from ShellMatrix rather than
>>> vice versa. This could actually make SparseShellMatrix unnecessary.
>>> This
>>> is of course an advantage of the unification.
>>
>> This one
On Mon, 20 Oct 2008, John Peterson wrote:
> On Mon, Oct 20, 2008 at 8:01 AM, Tim Kroeger
> <[EMAIL PROTECTED]> wrote:
>> Dear John,
>>
>> One problem would be that this makes it more difficult to differentiate
>> (e.g. in LinearSolver::solve()) which type of matrix is actually present.
>> On the
On Mon, Oct 20, 2008 at 8:01 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John,
>
> One problem would be that this makes it more difficult to differentiate
> (e.g. in LinearSolver::solve()) which type of matrix is actually present.
> On the other hand, that might easily be solvable using some
Dear John,
Thank you for your comments.
If you like to unify SparseMatrix and ShellMatrix after commiting my
patch, I would find that completely agreeable. I would guess that
it's a lot more difficult than it looks like on first glance, but I
might be wrong.
One problem would be that this ma
On Fri, Oct 17, 2008 at 7:17 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John/Roy/all
>
> On Thu, 16 Oct 2008, John Peterson wrote:
>
>> On Thu, Oct 16, 2008 at 10:46 AM, Roy Stogner <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Thu, 16 Oct 2008, Tim Kroeger wrote:
>>>
>>> I'm a bit unhappy with t
> In reality, none of us are that diligent, and if we're going to
> be lazy anyway we ought to make laziness more convenient. ;-
Agree 100%.
-Ben
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challen
On Thu, 16 Oct 2008, John Peterson wrote:
>> I think I'll withhold judgment until I've seen the new ShellMatrix
>> header file... It doesn't seem like they should necessarily be treated
>> as members of the SparseMatrix inheritance family. It's bad enough
>> that we can't simultaneously keep th
On Thu, Oct 16, 2008 at 11:20 AM, John Peterson <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 16, 2008 at 10:46 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, 16 Oct 2008, Tim Kroeger wrote:
>>
>>> As Roy predicted, preconditioning is tricky. I extended the ShellMatrix
>>> class (and all the
On Thu, Oct 16, 2008 at 10:46 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Thu, 16 Oct 2008, Tim Kroeger wrote:
>
>> As Roy predicted, preconditioning is tricky. I extended the ShellMatrix
>> class (and all the derived classes) by a get_diagonal() method, thus allowing
>> at least JACOBI prec
On Thu, Oct 16, 2008 at 10:20 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John/Roy/all,
>
> As Roy predicted, preconditioning is tricky. I extended the ShellMatrix
> class (and all the derived classes) by a get_diagonal() method, thus
> allowing at least JACOBI preconditioning, which for the
On Thu, 16 Oct 2008, Tim Kroeger wrote:
> As Roy predicted, preconditioning is tricky. I extended the ShellMatrix
> class (and all the derived classes) by a get_diagonal() method, thus allowing
> at least JACOBI preconditioning, which for the moment seems to be sufficient
> for my example. T
Dear John/Roy/all,
As Roy predicted, preconditioning is tricky. I extended the
ShellMatrix class (and all the derived classes) by a get_diagonal()
method, thus allowing at least JACOBI preconditioning, which for the
moment seems to be sufficient for my example. This required to add an
analo
Dear John,
On Thu, 9 Oct 2008, John Peterson wrote:
I enclosed all my PETSc calles with "#if PETSC_VERSION_LESS_THAN(2,3,3)" and
added error messages in the "#else" case since I am not familiar with
PETSc's API history. Whenever somebody might need the shell matrix
functionality together with o
John Peterson wrote:
> On Thu, Oct 9, 2008 at 7:04 AM, Tim Kroeger
> <[EMAIL PROTECTED]> wrote:
>> By the way, why is the .depend file contained in the repository?
>
> A couple of reasons: this way we don't require all users to have perl
> installed (though I don't know how they wouldn't...) to ge
On Thu, Oct 9, 2008 at 7:04 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear Roy and John and all,
>
> Please find attached my next version.
>
> I enclosed all my PETSc calles with "#if PETSC_VERSION_LESS_THAN(2,3,3)" and
> added error messages in the "#else" case since I am not familiar with
> PE
Dear Roy and John and all,
Please find attached my next version.
I enclosed all my PETSc calles with "#if
PETSC_VERSION_LESS_THAN(2,3,3)" and added error messages in the
"#else" case since I am not familiar with PETSc's API history.
Whenever somebody might need the shell matrix functionality
On Wed, Oct 8, 2008 at 12:05 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 8 Oct 2008, John Peterson wrote:
>
>> I'm a little nervous about casting a function pointer to a void*.
>> Technically this is not allowed (something about void* being reserved
>> for data pointers, google for "func
On Wed, Oct 8, 2008 at 12:55 PM, Jed Brown <[EMAIL PROTECTED]> wrote:
> On Wed 2008-10-08 12:42, John Peterson wrote:
>> Thanks Jed...
>>
>> On Wed, Oct 8, 2008 at 12:24 PM, Jed Brown <[EMAIL PROTECTED]> wrote:
>> >
>> > class MyShell {
>> > public:
>> > int mult(...);
>> > };
>> >
>> > PetscE
On Wed, 8 Oct 2008, John Peterson wrote:
> On Wed, Oct 8, 2008 at 12:05 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>>
>> How about a functor abstract base class? Anyone? We are using C++
>> still, right? ;-)
>
> I briefly considered this but MatShellSetOperation does required a
> pointer to a
On Wed, Oct 8, 2008 at 12:05 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 8 Oct 2008, John Peterson wrote:
>
>> I'm a little nervous about casting a function pointer to a void*.
>> Technically this is not allowed (something about void* being reserved
>> for data pointers, google for "func
On Wed, 8 Oct 2008, John Peterson wrote:
> I'm a little nervous about casting a function pointer to a void*.
> Technically this is not allowed (something about void* being reserved
> for data pointers, google for "function pointer to void*" on
> comp.lang.c++.moderated) which I assume is why you
On Wed, Oct 8, 2008 at 10:52 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear all,
>
> thank you very much for all your suggestions.
>
> I started implementing the thing now. Find attached a patch that contains
> my first attempt. It compiles well at the moment, but it most probably will
> not w
Dear all,
thank you very much for all your suggestions.
I started implementing the thing now. Find attached a patch that
contains my first attempt. It compiles well at the moment, but it
most probably will not work as expected, because I did not have the
time to test it yet, and I am not to
There is a way to do matrix free solving with libMesh and Petsc. Take
a look at the PetscNonlinearSolver (which you can get by using a
NonlinearImplicitSystem). If you just set the residual() function and
not the jacobian() then you are solving matrix free using Petsc SNES.
Note that there
On Tue, 7 Oct 2008, John Peterson wrote:
> On Tue, Oct 7, 2008 at 10:32 AM, Tim Kroeger
> <[EMAIL PROTECTED]> wrote:
>> As far as I see, there seems not to be any interface in libMesh to
>> solve a system in a matrix free way.
>>
>> I have to solve a linear system whose matrix basically has the
>
On Tue, Oct 7, 2008 at 10:32 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear libMesh team,
>
> As far as I see, there seems not to be any interface in libMesh to
> solve a system in a matrix free way.
>
> I have to solve a linear system whose matrix basically has the
> following structure:
>
> A
Dear libMesh team,
As far as I see, there seems not to be any interface in libMesh to
solve a system in a matrix free way.
I have to solve a linear system whose matrix basically has the
following structure:
A = B + v*w^T
where B is a sparse matrix and v and w are vectors, so that v*w^T is a
33 matches
Mail list logo
