> On Jul 26, 2022, at 10:51 AM, Barry Smith wrote:
>
>
>
>> On Jul 26, 2022, at 10:49 AM, Boyce Griffith wrote:
>>
>>
>> clang-tidy can help with setting/enforcing C++ coding standards and avoiding
>> some “old” C++ conventions / suggesting “mod
> On Jul 26, 2022, at 9:55 AM, Barry Smith wrote:
>
>
>
>> On Jul 26, 2022, at 9:43 AM, Jacob Faibussowitsch
>> wrote:
>>
>>> even more importantly we would need a huge amount of education as to what
>>> to use and what not to use otherwise our hacking habits will fill the
>>> source co
> On Apr 26, 2022, at 8:12 PM, Barry Smith wrote:
>
> I didn't like PetscCall(ierr) in Fortran because it is strange, even
> freakish. PetscCall(AFunction(args)) makes sense in C but IMHO "call
> AFunction(args,ierr); PetscCall(ierr)" looks weird, what are you calling?
> Nothing. I'd like to
> On Jun 29, 2018, at 9:58 AM, Lisandro Dalcin wrote:
>
> On Thu, 28 Jun 2018 at 20:17, Lawrence Mitchell wrote:
>>
>>
>> OK, I've done some more benchmarking now, and cooked up a very simple test
>> case. I just solve a tiny problem 10 million times.
>>
>> On master, this completes on m
> On Jun 22, 2016, at 7:34 PM, Boyce Griffith wrote:
>
>
>
> On Jun 22, 2016, at 6:23 PM, Mark Adams <mailto:mfad...@lbl.gov>> wrote:
>
>>
>>
>> On Wed, Jun 22, 2016 at 8:14 PM, Boyce Griffith > <mailto:griff...@cims.nyu.edu>>
> On Jun 22, 2016, at 6:23 PM, Mark Adams wrote:
>
>
>
>> On Wed, Jun 22, 2016 at 8:14 PM, Boyce Griffith
>> wrote:
>>
>>> On Jun 22, 2016, at 2:06 PM, Barry Smith wrote:
>>>
>>>
>>> I suggest focusing on asm. Having b
> On Jun 22, 2016, at 2:06 PM, Barry Smith wrote:
>
>
> I suggest focusing on asm. Having blocks that span multiple processes seems
> like over kill for a smoother ? (Major league overkill) in fact doesn't one
> want multiple blocks per process, ie. pretty small blocks.
And with lots of sm
> On Feb 6, 2015, at 2:04 PM, Barry Smith wrote:
>
>
> If you don't see any memory leaks directly from PETSc routines then it is a
> problem in OpenMPI.
OpenMPI intentionally does stuff that is not Valgrind clean:
http://www.open-mpi.org/faq/?category=debugging#valgrind_clean
I've persona
On 2/21/13 8:57 PM, Jed Brown wrote:
>
> On Thu, Feb 21, 2013 at 7:53 PM, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
>
> These applications are mainly transient solvers in which regridding
> happens "between" time steps.
>
>
On Feb 21, 2013, at 8:44 PM, Jed Brown wrote:
> On Thu, Feb 21, 2013 at 7:28 PM, Boyce Griffith
> wrote:
>
> I would very happily use an "undefined" vector size. (I will also happily
> change the bogus local sizes from 0 to 1, and the global sizes according
"PETSc, pronounced PET-see (the S is silent), is a suite of data
structures and routines for the scalable (parallel) solution of
scientific applications that require algebraic solvers. Many such
applications are systems that are modeled by partial differential
equations (PDEs). PETSc may also
On 6/7/11 2:32 PM, Jed Brown wrote:
> On Tue, Jun 7, 2011 at 20:17, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> At one point, I tried implementing the local part of the matrix-free
> matrices use PETSc Mat's, but performance was modestly lower
On 6/7/11 2:42 PM, Jed Brown wrote:
> On Tue, Jun 7, 2011 at 20:41, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> Nope; to keep SAMRAI stuff working like regular SAMRAI stuff, the
> ghost values wind up in the middle of the vector. At least with th
On 6/7/11 2:32 PM, Jed Brown wrote:
> An alternative, which I had in mind when I said that I was
> interested in trying to use PETSc to provide the storage for the
> SAMRAI data structures, is to use SAMRAI to provide basic grid
> management, and to use PETSc to provide data stora
On 6/7/11 2:24 PM, Philip, Bobby wrote:
> Jed:
>
> SAMRAI has a fairly typical structured AMR design.There is a list or array of
> refinement levels that together form the AMR hierarchy and
> each refinement level has a set of logically rectangular patches. Data is
> only contiguous on a patch.
On 6/7/11 1:43 PM, Jed Brown wrote:
> On Tue, Jun 7, 2011 at 19:05, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> Another might be easier access to CUDA.
>
>
> What do SAMRAI matrices look like? In particular, how are they constructed?
There is
On 6/7/11 12:48 PM, Bobby Philip wrote:
>
> On Jun 6, 2011, at 4:26 PM, Boyce Griffith wrote:
>>
>> What I'd really like to do is to setup some SAMRAI stuff that actually
>> uses Vec / Mat for data storage, so that most of this wrapper stuff is
>> not nece
On 6/7/11 12:47 PM, Bobby Philip wrote:
>>
>> All I can tell you is that, many years ago, at least some of these calls
>> to PetscObjectStateIncrease() were needed in the Vec routines in order
>> to get PETSc solvers to work with the SAMRAI PETSc Vec class. To try to
>> avoid the issues that Bob
On 6/6/11 5:56 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 23:49, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> But if the model is that the Vec implementation is responsible for
> updating the state, then would it be better if PETSc did NOT
>
On 6/6/11 5:38 PM, Barry Smith wrote:
>
> On Jun 6, 2011, at 4:33 PM, Boyce Griffith wrote:
>
>>
>>
>> On 6/6/11 5:23 PM, Barry Smith wrote:
>>>
>>>Jed,
>>>
>>> Though VecRestoreArray() does increase the Vector state,
On 6/6/11 5:23 PM, Barry Smith wrote:
>
>Jed,
>
> Though VecRestoreArray() does increase the Vector state, we also have
> our base Vec class methods (and MatMult and friends) ALSO increase the state
> on appropriate Vec arguments (so for built-in Vec classes like VECSEQ the
> state
On 6/6/11 5:11 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 23:09, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> Oh, right, except that getVector() is called even on Vec's that are
> not modified.
>
>
> What comes out of getVector()?
On 6/6/11 5:06 PM, Boyce Griffith wrote:
>
>
> On 6/6/11 4:59 PM, Jed Brown wrote:
>> On Mon, Jun 6, 2011 at 22:49, Boyce Griffith > <mailto:griffith at cims.nyu.edu>> wrote:
>>
>> I stash a pointer to the SAMRAI vector object in the PETSc Vec as
>>
On 6/6/11 4:59 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 22:49, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> I stash a pointer to the SAMRAI vector object in the PETSc Vec as
> vec->data.
>
>
> Great, somewhere in your FormResidual()
On 6/6/11 4:45 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 22:41, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> At least in my code, and I expect in Bobby's too, all Mat and PC
> objects are just shells. So the only non-PETSc objects are
On 6/6/11 4:33 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 22:26, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> I'm sure you already know this --- but just to be clear --- Bobby
> and I are managing different SAMRAI-PETSc wrapper codes, which
On 6/6/11 4:31 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 22:21, Boyce Griffith <mailto:griffith at cims.nyu.edu>> wrote:
>
> Could calls to PetscObjectStateIncrease be added to SNES so that
> they are not needed anywhere in wrapper/application code?
>
>
&g
On 6/6/11 4:09 PM, Barry Smith wrote:
>
> On Jun 6, 2011, at 2:57 PM, Boyce Griffith wrote:
>
>> Does anyone actually use the PETSc wrappers that are provided by SAMRAI?
>> (Even you, Bobby? :-) )
>>
>> My impression is that none of the LLNL SAMRAI folks use th
On 6/6/11 4:16 PM, Barry Smith wrote:
>
> On Jun 6, 2011, at 3:14 PM, Boyce Griffith wrote:
>
>>
>>
>> On 6/6/11 3:55 PM, Barry Smith wrote:
>>>
>>> On Jun 6, 2011, at 2:50 PM, Boyce Griffith wrote:
>>>
>>>> I maintain similar SAM
On 6/6/11 3:55 PM, Barry Smith wrote:
>
> On Jun 6, 2011, at 2:50 PM, Boyce Griffith wrote:
>
>> I maintain similar SAMRAI-PETSc stuff, although I'm only synched up with
>> PETSc 3.1, not petsc-dev. VecNorm caching caused me endless grief until I
>>
Does anyone actually use the PETSc wrappers that are provided by SAMRAI?
(Even you, Bobby? :-) )
My impression is that none of the LLNL SAMRAI folks use the SAMRAI-PETSc
interface, nor do any of the LLNL SAMRAI-based codes, which means that
it rapidly gets out of date and/or buggy.
If SAMRAI
I maintain similar SAMRAI-PETSc stuff, although I'm only synched up with
PETSc 3.1, not petsc-dev. VecNorm caching caused me endless grief until
I started making lots of calls to PetscObjectStateIncrease(), both in
the Vec routines and in the Mat/nonlinear function wrappers.
If you are "buildi
On 9/27/10 5:36 PM, Boyce Griffith wrote:
>
>
> On 9/27/10 5:28 PM, Shri wrote:
>> Barry,
>> I've modified MatAXPY_SeqAIJ as follows when
>> DIFFERENT_NONZERO_STRUCTURE flag is true (i) create a new matrix and
>> do preallocation for it. For determining th
On 9/27/10 5:28 PM, Shri wrote:
> Barry,
>I've modified MatAXPY_SeqAIJ as follows when
> DIFFERENT_NONZERO_STRUCTURE flag is true (i) create a new matrix and do
> preallocation for it. For determining the number of nonzeros per row in the
> new matrix, i've used the number of nonzeros
Hi, Barry et al. --
I'm moving this over to petsc-dev, since that seems like the more
appropriate place.
I'm attaching my stab at implementing MatAXPY for pairs of sequantial
AIJ matrices. I've done only very minimal testing, but it appears to
work for my application.
In the implementation,
I maintain some code which is based on the original SAMRAI-PETSc
interface provided by SAMRAI --- basically, it creates/configures Vec
objects which use SAMRAI routines to evaluate the vector operations on
AMR data. My code currently hooks together SAMRAI 2.4.4 and PETSc
(currently stuck at PE
Hi, Folks --
I'm attaching the C++ code that I use when I need to add values in
parallel using VecSetValues/VecSetValuesBlocked. The only reason to use
this code instead of the standard implementation is to (try to)
guarantee exact reproducibility in parallel when values accumulated to a
part
Great, thanks!
Matthew Knepley wrote:
> Fixed in 3.0.0. It will go out with the next patch update.
>
> Matt
>
> On Thu, Jan 29, 2009 at 1:36 PM, Boyce Griffith
> wrote:
>> Hi, Folks --
>>
>> It appears that the documentation for KSPDefaultConverged may ne
Hi, Folks --
It appears that the documentation for KSPDefaultConverged may need to be
updated to indicate that the convergence context used by
KSPDefaultConverged is NOT unused and must be created
byKSPDefaultConvergedCreate.
Also, since the context is not an unused dummy variable, perhaps it
Hi, Barry et al. --
I may be mistaken, but I believe that sizeof(bool) is almost always one
bit in C++. This results in various problems, including the need to
have a specialized implementation of std::vector in the STL. See,
e.g.,
http://www.informit.com/guides/content.aspx?g=cplusplus&
Matthew Knepley wrote:
> On Tue, Apr 29, 2008 at 12:28 PM, Boyce Griffith
> wrote:
>
>> Hi, Matt et al. --
>>
>> Do people ever use standard projection methods as preconditioners for these
>> kinds of problems?
>>
>> I have been playing around
Hi, Matt et al. --
Do people ever use standard projection methods as preconditioners for
these kinds of problems?
I have been playing around with doing this in the context of a staggered
grid (MAC) finite difference scheme. It is probably not much of a
surprise, but for problems where an exac
Matthew Knepley wrote:
> On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith wrote:
>> Fortran90 has namespaces??
>
> Not in the way I was thinking. Damn F90. Anyway, it looks like you can
> selectively
> use interface modules, so we might be able to get away with redundant names
> by just not u
Hi, Rich --
I essentially do Lagrangian particle tracking in my AMR immersed
boundary code using PETSc, although if you are looking for a
quick-and-dirty solution, I'm pretty sure you don't want to do things
the way that I do. Also, I apologize in advance for the rambling response.
The basic
44 matches
Mail list logo
