Derek Gaston writes:
>> It's necessary to catch errors if a symbol is removed from the library.
>> Automake/make has no way to know if changes have that effect.
>>
>
> The binaries that Roy is talking about aren't "test' binaries though.
> They're just utilities that libMesh has grown over the ye
Roy Stogner writes:
> ... Is this something that normal people do in practice? Or is it
> just the sort of thing an Obfuscated C Code Contest winner does when
> language-only madness gets too boring and no longer calms the shakes?
It's mainly used for testing, especially if you need to use stat
Roy Stogner writes:
> On Thu, 30 Aug 2018, Paul T. Bauman wrote:
>
>> I would love to see how it could be sped up. The vast majority of
>> time in make install is spent in linking the library and there's no
>> getting around that.
>
> Looping over directory after directory costs some time, and I'
"Paul T. Bauman" writes:
>> No need to modify Makefiles. No need to run scripts - all done within my
>> editor with source linking to compile errors. Not currently possible.
>>
>
> Again, the building within the editor may be an issue. I'm willing to bet
> it's fixable given the number of devel
Derek Gaston writes:
> Or: like I said earlier, maybe we just maintain two systems. PETSc has had
> several different build systems all at the same time because developers
> wanted different things.
It's important to note that all build systems have used the same
underlying specification. Th
John Peterson writes:
> How does the abstract submission work? Are there specific
> sessions/topics you're supposed to target? I checked out the
> easychair submission form and there weren't really any more detailed
> instructions.
Just submit the abstract for whatever you want and the PC will
Derek Gaston writes:
> 4. Loading up dense matrices of shape function evaluations so that all
> variable's values and gradients (of the same FEType) can be computed
> simultaneously with one single mat*vec. This creates perfectly vectorizable
> operations. I tried using Eigen for this as well as t
Roy Stogner writes:
>> Interesting. Can you include the full unpreconditioned output? And
>> please compare with and without -ksp_gmres_modifiedgramschmidt.
>
> From "./main-opt -ksp_monitor_true_residual -ksp_norm_type unpreconditioned":
>0 KSP unpreconditioned resid norm 1.137340546775e-01
Roy Stogner writes:
> By "neither seems to do much"?
>
> I mean that if I set either "-ksp_pc_side right" or "-ksp_norm_type
> unpreconditioned", then instead of ending up falsely "converged" at
> 10 KSP preconditioned resid norm 1.580464771307e-13 true resid norm
> 3.084021824157e-04 ||r(i)||
Roy Stogner writes:
> On Thu, 8 Jan 2015, Jed Brown wrote:
>
>>> 10 KSP preconditioned resid norm 1.580464771307e-13 true resid norm
>>> 3.084021824157e-04 ||r(i)||/||b|| 2.711608086867e-03
>>> number of iterations to solve adjoint: 10 final residual o
John Peterson writes:
> Are you definitely allowed to pass the same matrix for both "A" and
> the preconditioner when you call KSPSolveTranspose()?
Yes, at least with KSPs capable of transpose solves. Can you send
-ksp_view along with the output requested in my last email?
signature.asc
Descri
Roy Stogner writes:
> On Thu, 8 Jan 2015, Jed Brown wrote:
>
>> Can you provide output with -ksp_monitor_true_residual? Are you
>> comparing a preconditioned residual to an unpreconditioned residual?
>
> Yes, and yes:
>
>0 KSP preconditioned resid norm 5.89
Roy Stogner writes:
> Copying discussion from libmesh-users, both because it looks like a
> library- rather than a user-level problem and because I'm hoping one
> of our PETSc expert lurkers will chime in.
>
> Summary: running a libMesh adjoint_solve() on a particular coupled
> multiphysics syste
"Kirk, Benjamin (JSC-EG311)" writes:
> This would be my fault
>
> Two options, listed in my preferential order:
>
> (1) I'll try to track down the original author and ask about distributing
> under a different license
> (2) investigate something like this
> https://github.com/adrpar/libhilbert?f
Ignore this, obviously. I auto-archive libmesh-devel if it doesn't have
certain keywords so I missed Derek's parallel thread.
I had asked him a Hilbert curve question and he pointed me to
libHilbert. I noticed that it was GPL and pointed that out in chat last
night.
Jed Brown wr
Derek Gaston writes:
> However, "binary form" isn't the only issue. You also can't distribute
> things in source form under a license that further restricts its
> distribution. ie - you can't distribute a libMesh based code under NDA.
I think Roy's point was that you could build an application
I notice that libHilbert is GPLv2+. This is not apparent when running
configure, but if libHilbert is activated, the user's app must be
GPL-compatible. I would suggest adding a license indicator in
./configure --help so that users know what they're agreeing to.
This also turns up a disturbing n
[My lab email was just moved to Exchange and I don't have enough fingers
to count the number of ways in which they violate RFC-2822 in the simple
process of forwarding a message.]
Roy Stogner writes:
> On Mon, 13 Jan 2014, Jed Brown wrote:
>
>> Note that you might also ha
Roy Stogner writes:
> Anyone stuck in this situation should know that installing and using a
> new gcc is easier than it used to be
Note that you might also have to rebuild the entire software stack due
to ABI incompatibilities, e.g.,
http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
pgp_QJoCAsF
Dmitry Karpeyev writes:
> In this particular instance (libMesh) it's a libMesh macro. libMesh doesn't
> rely on petscversion.h,
> but rather detects the petsc version numbers during configure. It doesn't
> use PETSC_VERSION_RELEASE,
> so it's not an entirely trivial fix (at least for me).
> I bui
Nov 13 10:51:48 2013 -0700
Patch from Jed Brown fixing PetscDMLibMesh on Petsc >= 3.5.
diff --git a/src/solvers/petscdmlibmesh.C b/src/solvers/petscdmlibmesh.C
index 09dc324..c36ff06 100644
--- a/src/solvers/petscdmlibmesh.C
+++ b/src/solvers/petscdmlibmesh.C
@@ -934,7 +93
John Peterson writes:
> Ah, I'm using 3.3-p4, so that checkPESSL function looks for pdgemm in that
> version:
Oh, now I remember that WTF moment.
commit 73dbc7173f5993ebbea13e62f9c58773df1a1b5b
Author: Jed Brown
Date: Sun Jan 20 13:09:14 2013 -0600
Detect PESSL using ipessl
John Peterson writes:
> Thanks, that definitely seems to have worked, but it triggers a strange
> error during configure:
>
> "Cannot use PESSL instead of ESSL!"
>
> This is presumably due to some function in the MKL scalapack libraries
>
> /opt/intel/mkl/lib/intel64/libmkl_scalapack_ilp64.so
>
John Peterson writes:
> We are interested in attempting to run on the host CPUs and use automatic
> offloading to MIC with MKL, so the website recommended the following:
>
> linker options: -lmkl_scalapack_ilp64 -lmkl_cdft_core
> -lmkl_blacs_intelmpi_ilp64 -lpthread -lm
> compiler options: -DMK
John Peterson writes:
> I got access to a machine with Intel-14, and it looks like libmesh master
> (sans PETSc at the moment, working on figuring out the right way to link
> against MKL) compiles and the examples run OK for me (no segfaults at the
> end of apps).
If you are using Intel compilers
Hui Zhang writes:
> I have a question to use the patch, the petsc version number was
> (3,4,3) for PETSC_VERSION_GIT
> "a61ea2a881f906cd3f3ff3c8a0af27e23148237c" on my mac. Has it been
> changed now?
PETSc version comparison macros, such as PETSC_VERSION_LT, consider
petsc-dev (PETSC_VERSION_RELE
John Peterson writes:
> I saw it, but I don't know exactly how to fix the problem and haven't had a
> chance to dig into it. Maybe Dmitry will comment.
Totally untested, but I think this is all you need:
diff --git i/src/solvers/petscdmlibmesh.C w/src/solvers/petscdmlibmesh.C
index 09dc324..c36
"Kirk, Benjamin (JSC-EG311)" writes:
> Jed, does the PETSc team have any experience with the NBC algorithm
> deadlocking with OpenMPI-1.7?
>
> I know they don't officially advertise MPI_Ibarrier(), but it is there...
I've had problems with other things in the past, but I don't recall this
speci
"Kirk, Benjamin (JSC-EG311)" writes:
> MPI_Win_create (&recv_buf[0], recv_buf.size()*sizeof(unsigned int),
> sizeof(unsigned int),
> MPI_INFO_NULL, MPI_COMM_WORLD,
> &win);
In practice, this is implemented using something like an MPI_Allreduce
with 3*int*comm_s
These large nearly-diagonal blocks pessimal for BAIJ. If you want to split
into a few blocks that are each nearly-dense then a combination of BAIJ and
Nest should be good.
On Jul 27, 2013 10:30 PM, "Derek Gaston" wrote:
> Oops accidentally hit send! Look below for the real email :-)
>
> Sent fro
Cody Permann writes:
> Well, yes... I used that tip from Roy to see all the pull requests.
> There around 80 of them out there already in the short life of libMesh
> on github. 95% of those have long been merged back into trunk but
> that ref spec still shows them all. It's not a big deal, I h
Cody Permann writes:
> Ah close - looks like I need 'git pull --prune'!
I guess I don't know what you're looking for. You want to prune the
remote tracking branch while it still exists upstream? That's not
really the point of remote tracking branches so you should just make
sure they are clo
Cody Permann writes:
> Nice! Now I just need to figure out how to filter out closed requests. My
> "git branch -av" command is a mess now :)
Are you looking for 'git fetch --prune'?
--
Precog is a next-generation ana
On Wed, Apr 3, 2013 at 7:27 PM, Roy Stogner wrote:
> On Wed, 3 Apr 2013, Jed Brown wrote:
>
> (PETSc just went through this "uncrustify" process.
>>
>
> Do you mean metaphorically or "literally, we used the uncrustify
> command"? uncrustify was my sec
Roy Stogner writes:
> Yelling "We just wanted to strip off trailing white space, what the
> hell!?!" at me would also be reasonable.
>
> There's no need to do any of this any time soon (and certainly not
> while Ben's got a major branch outstanding for the communicators
> stuff) but it couldn't h
On Wed, Feb 27, 2013 at 11:31 AM, Dmitry Karpeev wrote:
> Sure. petscdmlibmesh assumes !PETSC_VERSION_LESS_THAN(3,3,0) at the very
> top.
>
Okay, I missed that. You could have used an exact match
PETSC_VERSION_(3,3,0) in the conditional.
--
On Wed, Feb 27, 2013 at 9:31 AM, Dmitry Karpeev wrote:
> I made some line comments. Did you test this with petsc-3.2 or earlier?
>>
> I tested with petsc-dev, petsc-3.3 and petsc-3.2.
>
Can you explain how the preprocessor accepted this line without having
PETSC_VERSION_LE defined?
#if !PETSC_V
On Wed, Feb 27, 2013 at 2:09 AM, Dmitry Karpeev wrote:
> Here it is: https://github.com/libMesh/libmesh/pull/51
>
I made some line comments. Did you test this with petsc-3.2 or earlier?
> DMlibMeshCreateXXXDecomposition() is "broken" (produces no decompositions
> at the moment),
> but the API
Dmitry, are you going to do this?
On Mon, Feb 25, 2013 at 3:59 PM, Jim Fonseca wrote:
> Hi,
> Does anyone have a guess when this issue about DMSetFunction and
> DMSetJacobian might be resolved?
>
> http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg04574.html
>
> Thanks,
> Jim
On Sat, Feb 9, 2013 at 11:12 AM, Derek Gaston wrote:
> On Feb 8, 2013, at 11:52 PM, Jed Brown wrote:
>
> > So what do you folks do when you're hacking on both libmesh and moose?
> Do you 'make install' libmesh after every change?
>
> Yes, currently (becau
On Fri, Feb 8, 2013 at 9:35 PM, Derek Gaston wrote:
> On Fri, Feb 8, 2013 at 8:13 PM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> I have added a flag inside libmesh-config that indicates whether its been
>> installed yet or not, but haven't done anything with it yet. I fi
$ ~/src/libmesh/build-petsc33-mpich/contrib/bin/libmesh-config --include
-I/usr/local/include -I/usr/include -I/usr/include/eigen3
-I/home/jed/petsc-3.3/include -I/home/jed/petsc-3.3/mpich/include
-I/opt/mpich/include
It seems to me that this needs to include
-I/home/jed/src/libmesh/build-petsc33
On Thu, Feb 7, 2013 at 1:17 PM, Derek Gaston wrote:
> I'm honestly not sure if it's worth bastardizing the rest of the libMesh
> interface to handle this one case when it can be handled pretty simply by
> just providing a libMesh::swap_communicator() function. I mean... it's
> worked this way fo
On Mon, Feb 4, 2013 at 4:43 PM, Derek Gaston wrote:
> On Mon, Feb 4, 2013 at 3:23 PM, Jed Brown wrote:
>
>> I should add a test in PETSC if it doesn't. Is there a libmesh example I
>> can use to reproduce this?
>>
>
> There isn't... but there is a MO
On Mon, Feb 4, 2013 at 4:20 PM, Derek Gaston wrote:
> Thanks Jed PCReset() somewhat fixed it... but now I get this:
>
> [0]PETSC ERROR: Error in external library!
> [0]PETSC ERROR: Error in HYPRE_IJMatrixAssemble()!
> ...
> [0]PETSC ERROR: MatHYPRE_IJMatrixFastCopy_SeqAIJ() line 183 in
> src/
On Mon, Feb 4, 2013 at 3:44 PM, Derek Gaston wrote:
> After updating to Petsc 3.3 (and the new libMesh... so it's not clear
> where the error is). One of our fancier preconditioning routines that
> relies on matrices added using system.add_matrix() calls is failing when we
> try to apply the pre
On Sat, Feb 2, 2013 at 7:05 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Try fetching master and
>
> $ ./bootstrap --build-autotools
>
> That should install our preferred versions and use them to run autoreconf.
>
This works and comes through clean, but it rebuilds everythi
On Sat, Feb 2, 2013 at 6:47 PM, Derek Gaston wrote:
> What are you changing? If you're changing something in an m4 file then
> you will see a lot of diffs. If you're adding a new file there will be
> some diffs but they're not bad. If you're not doing either one of those
> things there should
On Sat, Feb 2, 2013 at 4:34 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> > ~/src/libmesh$ git diff --shortstat
> > 80 files changed, 19707 insertions(+), 7912 deletions(-)
>
> We aren't *that* pedantic about forcing you to use the same versions.
> ./bootstrap will detect o
On Sat, Feb 2, 2013 at 4:24 PM, Roy Stogner wrote:
> And Ben's really gone above-and-beyond in making that easy. The last
> time I ran his bootstrap on a system where I'd forgotten to update
> automake from an older version, the script detected that and then
> built and used our contrib/autotools
On Sat, Feb 2, 2013 at 4:00 PM, Dmitry Karpeev wrote:
> I was actually considering maintaining backward-compatibility since there
> may be a small number of people (perhaps only Ata) that could be using this
> functionality, although it is still pretty new. Replacing these entirely
> with DMSNES
;
> On Sat, Feb 2, 2013 at 2:27 PM, Jed Brown wrote:
>
>> Dmitry, this patch used an API (DMSetFunction and DMSetJacobian) that was
>> deprecated at that time and has since been removed.
>>
>>
>> https://github.com/libMesh/libmesh/commit/d6a70b22dc6db38805851
Dmitry, this patch used an API (DMSetFunction and DMSetJacobian) that was
deprecated at that time and has since been removed.
https://github.com/libMesh/libmesh/commit/d6a70b22dc6db38805851dc01533c73a26ca21e8
It would be pretty easy to update this code to use DMSNESSetFunction and
DMSNESSetJacobi
Hmm, what about having a branch that was automatically regenerated based on
'master'? It would be 'reset' after build files were regenerated, and
patches would always go on top of a normal branch, so it would never show
up in the history.
This is somewhat similar to the throw-away integration bran
When I run ./bootstrap, it creates generates massive diffs (Makefile.in,
configure, aclocal.m4, build-aux) as compared to the checked-in versions.
80 files changed, 19707 insertions(+), 7912 deletions(-)
This makes 'git diff' worthless and I have to 'git checkout .' before 'git
pull'. Is your id
On Fri, Feb 1, 2013 at 9:17 AM, Paul T. Bauman wrote:
> I agree and have learned to take the bad with the good. Sorry to be a
> broken record, but just in case you missed earlier in the thread, you,
> personally, shouldn't need to mess with the environment, just do
>
> libtool --mode=execute valg
On Sat, Jan 19, 2013 at 8:53 PM, Derek Gaston wrote:
> I'm with you... but can't "make" _build_ the example... and not run it?
> That's kind of what I would expect. It's weird that there is no way to
> just build an example without running it. This is somewhat annoying during
> the development
---
src/solvers/petscdmlibmesh.C | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/solvers/petscdmlibmesh.C b/src/solvers/petscdmlibmesh.C
index dce3f46..273a7e3 100644
--- a/src/solvers/petscdmlibmesh.C
+++ b/src/solvers/petscdmlibmesh.C
@@ -204,7 +204,7 @@ PetscErrorCo
I fixed a few here, but there are lots more. They light up if you build
with clang.
--- i/include/numerics/type_n_tensor.h
+++ w/include/numerics/type_n_tensor.h
@@ -67,7 +67,7 @@ public:
/**
* Return a proxy for the \f$ i^{th} \f$ slice of the tensor.
*/
- const TypeNTensor slice (con
attached
0001-Support-SLEPc-3.3-and-later.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT manag
On Thu, Mar 22, 2012 at 22:26, Roy Stogner wrote:
> I can definitely state that, but I'd be happier if I was certain it's
> true. ;-) Have you tested it yet? If not, I can check against our
> nightly tarball tomorrow.
>
I've been running some examples every few days, including today. So it
de
Some of us PETSc developers are wondering if you can state (at least on the
website, post-release) that this works with petsc-3.3 (which we plan to
release in about a week with no further API changes).
On Thu, Mar 22, 2012 at 14:24, Roy Stogner wrote:
>
> Now available in gzip and xzip tarballs
On Wed, Feb 15, 2012 at 20:12, Roy Stogner wrote:
> On Wed, 15 Feb 2012, Jed Brown wrote:
>
> Changing the matrix type loses preallocation information. This issue
>> arose on the mailing list by a user trying to use CUSP matrices.
>>
>
> Thanks for the fix!
>
>
Changing the matrix type loses preallocation information. This issue
arose on the mailing list by a user trying to use CUSP matrices.
---
src/numerics/petsc_matrix.C | 95 ++
1 files changed, 32 insertions(+), 63 deletions(-)
diff --git a/src/numerics/pe
Resending from an email address that is accepted by libmesh-devel
On Mon, Feb 13, 2012 at 14:41, Jed Brown wrote:
> On Mon, Feb 13, 2012 at 12:11, Cody Permann wrote:
>
>> This is to be expected - if you think about what happens in assembly we
>> are looping over elements an
Put this stone-age device in a museum. ;-)
On Fri, Jan 20, 2012 at 14:57, John Peterson wrote:
> Hi all,
>
> The MOOSE team has been discussing the possibility of removing the SVN
> $Id$ and friends keywords from the libmesh source.
>
> One reason this would be a good change is that most new fil
On Mon, Oct 24, 2011 at 10:24, John Peterson wrote:
> On Tue, Oct 18, 2011 at 10:18 PM, Jed Brown wrote:
> >
> > I rebuilt everything and sadly, the same problem is still present with
> > r4873.
>
> One other difference between Mac and Linux we noted was the order
On Thu, Oct 13, 2011 at 23:32, Derek Gaston wrote:
> Indeed - I suspected as much.
>
> Are you coming to the meeting tomorrow morning Jed? We can definitely work
> on this some then…
>
Yeah, I'll be there.
I was using gcc-4.6.1 on Arch Linux. I tried to rebuild with clang-2.9, but
ran into -fP
I'm tripping an assert that Derek and John are not seeing. From the
debugging session below, I have no idea why, unless they really aren't
building with DEBUG on.
Reproduce with: ./ex3-dbg -d 2
#ifdef DEBUG
libmesh_assert (tot_size == di.size());
#endif
... because tot_size is 6, di.size()
On Mon, Aug 1, 2011 at 14:48, John Peterson wrote:
> Hmm... I think there used to be. We used to need to define
>
> EXTERN_C_FOR_PETSC_BEGIN
> EXTERN_C_FOR_PETSC_END
>
> inside petsc_macro.h, before we could include any other petsc headers.
> (At some point the petsc headers began extern C'ing
On Mon, Aug 1, 2011 at 12:49, John Peterson wrote:
> I think it's because petsc_macro.h is #include'd *before* the relevant
> petsc header, so the macro is defined before the extern XXDestroy
> functions are declared, at which point they get macro-fied...?
>
Hmm, I wonder why this would be diffe
On Sun, Jul 31, 2011 at 14:03, Derek Gaston wrote:
> Sweet! Any timing numbers on this? We see a pretty good chunk of our
> runtime getting eaten up by mapping...
>
This patch does not change the algorithm at all, it just uses a public API
to access the local-to-global mapping (which we have m
---
include/numerics/petsc_macro.h | 10 +
include/numerics/petsc_vector.h |2 +-
src/numerics/petsc_matrix.C |8 ++--
src/numerics/petsc_vector.C | 20 +-
src/solvers/petsc_diff_solver.C |2 +-
src/solvers/petsc_linear_solver.C|
---
include/numerics/petsc_vector.h | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/numerics/petsc_vector.h b/include/numerics/petsc_vector.h
index fcce800..3d77dbb 100644
--- a/include/numerics/petsc_vector.h
+++ b/include/numerics/petsc_vector.h
@@
On Thu, Jun 16, 2011 at 19:16, Roy Stogner wrote:
> The GNU STL implementation is a twisty maze of passages, all alike, so
> I may have missed something, but the only obvious specializations I
> see are the memset-based char one and the vector implementation.
>
Why don't you disassemble the func
On Fri, Jun 10, 2011 at 19:21, Roy Stogner wrote:
> It sounds as if we ought to allow a couple optional bool arguments to
> the PetscVector(Vec) constructor?
>
Yeah, and of course you could have a way to change them later.
> There's no way for that method to
> efficiently infer the state of a
On Fri, Jun 10, 2011 at 17:56, Derek Gaston wrote:
> This happens during the call to update() in the Petsc callback to compute
> the residual (and other callbacks). It's not from user code at all. Petsc
> is actually giving us a vector that isn't closed.
This comes from an impedance mismatch
On Wed, Jun 1, 2011 at 15:38, Derek Gaston wrote:
> Has anyone done any MMS verification on cubic hermite convergence rates? I
> thought they were supposed to be O(h^4) but we're only seeing O(h^2) on
> a fairly simple 2D poisson problem with an assumed solution of
> u=sin(8*pi*x).
Are you
On Mon, Apr 25, 2011 at 22:46, Roy Stogner wrote:
> And there's one place that's more worrisome:
> what's the next step up from MPI_LONG_DOUBLE? There's standard MPI
> Real*16 support for Fortran; would that work for 16 byte C/C++ FP too?
>
I don't know if that works. The latest MPICH2 defines
On Mon, Apr 25, 2011 at 22:23, Derek Gaston wrote:
> This has definitely peaked my interest... it would be interesting to see
> how some of our JFNK code behave if we're able to pick extremely small
> differencing parameters. Seems like we should be able to get better
> approximations of Jv
On Mon, Apr 25, 2011 at 22:08, Roy Stogner wrote:
> I don't know where 34 came from.
>>
>
> log10(2^(112+1))
>
>
> This is 16-byte. It's quad, not quad-double.
>>
>
> 128-bit float == 113 bit precision ~= 34 digit precision, no?
Of course, somehow I misread as "34 bytes" which seemed a strange
On Mon, Apr 25, 2011 at 21:09, Roy Stogner wrote:
> Hmm... I added long double support to libMesh because those extra
> couple digits can be a useful last resort for verifying when your
> convergence is bottoming out due to floating point error.
>
Yeah, it's handy to check what's going wrong wit
On Mon, Apr 25, 2011 at 16:03, John Peterson wrote:
> enable-tripleprecision
I don't know anything about this specific example, but I'd like to mention
that gcc-4.6 supports __float128 which is a *usable* quad-precision type. It
is supported in petsc-dev, configure --with-precision=__float128
-
On Wed, Feb 23, 2011 at 14:05, Roman Vetter wrote:
> Exactly. That's kind of the point. In order to be able to call
> SNESConvergedReasons[reason], the reason enum/int must be stored
> before _snes gets destroyed, which it isn't currently. Which brings be
> back to my initial suggestion.
>
So the
On Wed, Feb 23, 2011 at 11:12, Roman Vetter wrote:
> - The PETSc linear solver provides a print_converged_reason() member,
> which includes the KSPConvergedReason enums, but not all of them!
>
Having a switch statement like that is pretty silly. You can get the reason
in string form (const char *
On Tue, Dec 21, 2010 at 14:42, Jan Biermann wrote:
> first, I sent the stuff to Petsc and they want to include it (otherwise it
> would not make any sense to make the changes in libmesh I guess).
>
Okay, I asked because I hadn't seen it go by and it's not in the petsc-dev
repository yet.
to ans
On Fri, Dec 17, 2010 at 10:49, Jan Biermann wrote:
> I just implemented two new solvers in Petsc that make use of Krylov
> subspace recycling, which means that if you have to solve a sequence of
> linear systems, the overall cost can be reduced significantly (by 10 to
> 100).
Have you sent thes
It appeared in 3.0.0.
Jed
On Nov 23, 2010 8:49 AM, "Tim Kroeger"
wrote:
On Mon, 22 Nov 2010, Derek Gaston wrote:
> Getting a compile error after updating libMesh:
>
> Comp...
Yes, so it is my fault. I suggest the attached patch, which calls
libmesh_not_implemented() if this part of code is re
On Mon, Nov 22, 2010 at 16:18, John Peterson
wrote:
> > Petsc provides a MatCopy
>
> Make that MatDuplicate
Both exist. MatDuplicate creates a new object and optionally copies values
as well. MatCopy copies values into an existing matrix.
Jed
--
On Mon, Nov 22, 2010 at 22:33, Derek Gaston wrote:
> It appears that the function ISComplement() does not exist in petsc 2.3.3.
> I'm not familiar enough with what this code is supposed to be doing to be
> able to say if it's possible to achieve with 2.3.3 or if it should just be
> ifdef'd out.
On Thu, Oct 14, 2010 at 23:25, Roy Stogner wrote:
> It worked in my tests against 3.1-p5; then broke against whatever's in
> Ubuntu 10.04 (which looks like 3.1-p0?)
>
3.1 was out then, but only a couple weeks before 10.04 was released.
http://packages.ubuntu.com/search?keywords=petsc&searchon=n
On Thu, Oct 14, 2010 at 23:09, Roy Stogner wrote:
>
> Reasonable, but too fragile. On a couple system/compiler/app
> combinations I now get errors like this:
>
> /usr/lib/petsc/include/petscis.h:29:99: error: macro "ISCreateGeneral"
> requires 5 arguments, but only 4 given
>
Are you including p
On Thu, Oct 14, 2010 at 21:36, Roy Stogner wrote:
>
> I committed the first patch without changes; thank you very much!
>
> Would you mind if I futzed with the names on this one? E.g.
>
> # if PETSC_VERSION_LESS_THAN(2,2,1) // Cannot avoid a copy
> # define LibMeshISCreate(comm,n,idx,
---
include/numerics/petsc_macro.h |3 +++
include/numerics/petsc_matrix.h |2 +-
src/base/libmesh.C |2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/numerics/petsc_macro.h b/include/numerics/petsc_macro.h
index f11019b..57e39b8 100644
--- a/i
PetscCopyMode was added, ISCreateGeneral takes an additional parameter
---
include/numerics/petsc_macro.h |8
src/numerics/petsc_matrix.C|2 ++
src/numerics/petsc_vector.C| 10 ++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/numerics/pe
On Wed, 1 Sep 2010 12:58:11 -0500 (CDT), Roy Stogner
wrote:
> I'm not sure I understood Jed's suggestion - eliminate parallel
> non-ghosted vectors entirely, then write our own ghosting support to
> handle the non-PETSc backends? That seems like a lot of work to get
> slightly more robust suppor
On Tue, 31 Aug 2010 15:24:55 -0500 (CDT), Roy Stogner
wrote:
>
> On Tue, 31 Aug 2010, Jed Brown wrote:
>
> >> But it would be sufficient for your case to just create ghosted
> >> instead of parallel vectors. We can't do that in general in
> >> Numeric
On Tue, 31 Aug 2010 15:13:02 -0500 (CDT), Roy Stogner
wrote:
> We don't want to create ghosted instead of serial vectors - sometimes
> code is going to ask for a serial vector because it really needs data
> that's not on the local processor or its ghost cells. (and because
> it's too lazy to buil
On Tue, 31 Aug 2010 13:24:44 -0600, Derek Gaston wrote:
> On Aug 31, 2010, at 1:11 PM, Jed Brown wrote:
>
> > If a VecGhost was passed in to SNES, then all the Krylov vectors
> > will also be VecGhost. If not, create a new VecGhost
> > (VecCreateGhost() or VecDuplicat
On Tue, 31 Aug 2010 11:18:17 -0500 (CDT), Roy Stogner
wrote:
>
>
> On Tue, 31 Aug 2010, Derek Gaston wrote:
>
> > So... up until now I've only ever needed one "ghosted" vector... for
> > the solution vector. And, just as we do in petsc_nonlinear_solver.C
> > I've just been bastardizing System
1 - 100 of 173 matches
Mail list logo
