> I agree about not tying LibMesh too much to PETSc but since there is a
> PetscNonlinearSolver class, I definitely want to use its full potential when
> solving nonlinear problems. And hence exposure to the actual snes object
> either through a property or function is necessary to have better con
On Wed, 23 Jan 2008, Roy Stogner wrote:
Real min_realpart(const std::vector &v)
I finally realized that here was not the best place to bring in the
template specialization. We've had some little-used functions
libmesh_norm(x) (returning std::norm(x) or x*x as appropriate) and
libmesh_real(x
On Jan 23, 2008 10:17 AM, Vijay M <[EMAIL PROTECTED]> wrote:
> I understand your point of view but even Petsc can work with just residuals
> to obtain the Jacobian matrix (numerical Jacobian). But when the dof's are
> in the order of millions in a 3D case and I wouldn't even bother finding the
> nu
On Wed, 23 Jan 2008, John Peterson wrote:
> How about
>
> #ifdef USE_COMPLEX_NUMBERS
> // use ::real syntax
> #else
>
> #endif
>
>
> I didn't try this so if that makes no sense sorry.
That was actually the first thing I started coding, so hopefully it
makes some sense. ;-) But DistributedVecto
How about
#ifdef USE_COMPLEX_NUMBERS
// use ::real syntax
#else
#endif
I didn't try this so if that makes no sense sorry.
-J
Derek Gaston writes:
> Well... I made up a little toy code here... and got several other
> people from around the office (who are _very_ knowledgeable in C++
> lor
To expand on that you could even do something like:
template
void auxDoSomething()
{}
template<>
void something >::doSomething()
{
auxDoSomething();
}
That way each of your specializations don't have to have code copied
and pasted into them
Derek
On Jan 23, 2008 11:11 AM, Derek Gaston <[
Well... I made up a little toy code here... and got several other
people from around the office (who are _very_ knowledgeable in C++
lore) to come try and make it compile... with no luck. It just
doesn't seem to be possible.
I _did_ actually get it to compile with something like this:
template<>
On Wed, 23 Jan 2008, Derek Gaston wrote:
> 2008/1/23 Roy Stogner <[EMAIL PROTECTED]>:
>> template
>> Real DistributedVector >::min () const {...}
>
> Have you tried:
>
> template
> Real DistributedVector >::min () const {...}
No; I didn't even know that was valid syntax. Are you sure you don't
2008/1/23 Roy Stogner <[EMAIL PROTECTED]>:
> template
> Real DistributedVector >::min () const {...}
Have you tried:
template
Real DistributedVector >::min () const {...}
Derek
>
> with:
>
> error: invalid use of undefined type 'class
> DistributedVector >'
> ---
> Roy
--
Ben,
Thanks a bunch. I still havent had a chance to look at the code or compile,
run it yet but I hope it will run without any glitches. I will modify my
existing code along the same lines and see where it leads me. Again,
appreciate your effort in adding this example !!
Derek,
I understand you
On Wed, 23 Jan 2008, Derek Gaston wrote:
Sure you can... I do it with some of my classes in my code like this
In something.h:
template
class Something
{
T doSomething();
};
template<>
double Something::doSomething();
The situation here's a little more complicated.
This works:
templ
On Jan 23, 2008 9:22 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> The fix looks simple enough (we ought to be explicitly using
> std::complex::real()), but I'm not sure of the cleanest way to do
> it in standard C++. You can't partially specialize one method or two
> in a templated class without r
This is an interesting development...
One thing I would warn against is tying ourselves too close to Petsc.
I am currently waiting on a project to get green lighted where I will
be tying Trilinos into libMesh... where we will have access to other
matrix free solvers (like NOX, which can work with
On Wed, 23 Jan 2008, John Peterson wrote:
> Wow, I think you are exactly right. So could this have compiled all
> this time because operator< is valid for two iterators, which may be
> all the internals of std::min() would have needed? Looks like the
> code has been this way as far back as SVN
>> Is that line of code even correct for Reals? std::min isn't supposed
>> to operate on container iterators, it's just supposed to return the
>> minimum of two elements with a defined operator<. There's a
>> std::min_element which is probably what the author (I hope it wasn't
>> me...) was think
Roy Stogner writes:
>
>
> On Wed, 23 Jan 2008, John Peterson wrote:
>
> > Jan Biermann writes:
> > > Hi developers,
> > >
> > > I just downloaded the latest libmesh version and when I compile it in
> > > complex mode, the compiler throws an error from distributed_vector.h:
> > >
> > >
On Wed, 23 Jan 2008, John Peterson wrote:
Jan Biermann writes:
> Hi developers,
>
> I just downloaded the latest libmesh version and when I compile it in
> complex mode, the compiler throws an error from distributed_vector.h:
>
> In member function »Real DistributedVector::min() const [with T
Here is a really, really raw example, the comments are not clear right now,
but I wanted to keep you informed. This requires the latest svn branch to
work.
Unpack it in the ./examples directory and run make.
Run it as
$ ./ex19-dbg -snes_view -r 4
for a successive approximation which will conver
Jan Biermann writes:
> Hi developers,
>
> I just downloaded the latest libmesh version and when I compile it in
> complex mode, the compiler throws an error from distributed_vector.h:
>
> In member function »Real DistributedVector::min() const [with T =
> std::complex]«:
> src/numerics/nu
Hi developers,
I just downloaded the latest libmesh version and when I compile it in
complex mode, the compiler throws an error from distributed_vector.h:
In member function »Real DistributedVector::min() const [with T =
std::complex]«:
src/numerics/numeric_vector.C:182: instantiated from here
20 matches
Mail list logo