heir
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/72748bed/attachment.html>
the type here but that is ok,
> that doesn't mean the process has to be turned on its head does it?
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/64ed197c/attachment.html>
ner
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/568deca7/attachment.html>
o which their
experiments lead.
-- Norbert Wiener
------ next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/9a0d69f6/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/8073763a/attachment.html>
On 9 November 2011 17:51, Barry Smith wrote:
>
> ?To summarize:
>
> ? ?In C we could do #define PETSC_NULL ? ? ? ? ?((void*) 0) and every thing
> would be fine
>
Yes, or just include stdlib.h and define to NULL.
> ? ?In C++ this won't work and there is no alternative except a standard that
> i
On Nov 9, 2011, at 5:06 PM, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 16:58, Barry Smith wrote:
> Error in parallel not sequential.
>
> Okay, just note that the concept of a local space that is different from a
> global space is useful even in serial (e.g. ghost points for boundary
> conditio
On 9 November 2011 17:26, Jed Brown wrote:
> #define PETSC_NULL ? ? ? ? ? 0
> This is an "int" value, though it's special in that it will be implicitly
> converted to a null pointer (not even necessary bitwise 0, according to the
> standard) if its value is assigned to a pointer. If we pass it to
nges/dev.html when
>> you make API changes.
>>
>
>
--
Stefano
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/0c74afd7/attachment.html>
of the
LocalToGlobalMapping.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/f797fa9a/attachment.html>
On 9 November 2011 16:50, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 13:42, Lisandro Dalcin wrote:
>>
>> But then, what's the point of memzeroing in VecCreate_Sec? Wouldn't it
>> be better to fill the array (in debug mode) with signaling NaNs ?
>
> I'm not opposed to this.
> There is a question of
On Nov 9, 2011, at 4:55 PM, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 16:50, Barry Smith wrote:
> We don't usually do things that way hence I think a specific checking
> function is better.
>
> 3 seconds later I like the idea of returning null if it does not exist and
> not having the other
ov/pipermail/petsc-dev/attachments/2009/48999b77/attachment.html>
On Nov 9, 2011, at 4:37 PM, Jed Brown wrote:
> On Tue, Nov 8, 2011 at 14:49, mspieg wrote:
> VecIsGhosted would be nice?
>
> Pushed to petsc-dev. The semantics are simply whether VecGhostGetLocalForm()
> will succeed (which is normally what you want in the degenerate case of a
> serial Vec wh
On 9 November 2011 16:28, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 13:25, Matthew Knepley wrote:
>>
>> The simpler answer is yes, I always initialize the Mat or Vec to zero when
>> I use it. Even if its initialized when created,
>> I almost always get something from DMGetGlobalVector() etc. whic
:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/a7330746/attachment.html>
PetscErrorCode DMSetFromOptions(DM dm)
{
PetscBool flg1 = PETSC_FALSE,flg;
PetscErrorCode ierr;
char mtype[256] = MATAIJ;
PetscFunctionBegin;
if (dm->ops->setfromoptions) {
ierr = (*dm->ops->setfromoptions)(dm);CHKERRQ(ierr);
}
ierr = PetscObjectOptionsBegin((P
While you have been jabbering away I have fixed the problem.
We didn't manage the initialization process properly when the user created
CUSP vectors but did not do something to them before using them in things like
VecView(). Please let me know if the problem is not resolved or if new pro
On Nov 9, 2011, at 3:30 PM, Matthew Knepley wrote:
> On Wed, Nov 9, 2011 at 9:28 PM, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 15:22, Matthew Knepley wrote:
> So the problem is that in C++, when using a variadic function, you cannot
> type PETSC_NULL directly into the argument list? When would
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/a9d941ad/attachment.html>
ern PetscErrorCode
DMCompositeGetEntries(DM,...);
include/petscdmcomposite.h:extern PetscErrorCode
DMCompositeRestoreLocalVectors(DM,...);
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/b99eebfd/attachment.html>
So one solution is
#define PETSC_NULL 0
#define PETSC_NULL_VARARGS (void*) 0
Drawbacks: ugly, requires user to be aware of vargs calls
Advantages: same for C and C++.
Barry
On Nov 9, 2011, at 3:19 PM, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 15:15, Satish Balay wrote:
>
> ex
t;http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/a0777269/attachment.html>
On Wed, 9 Nov 2011, Jed Brown wrote:
> On Wed, Nov 9, 2011 at 15:04, Lisandro Dalcin wrote:
> > actually, we could try to define PETS_NULL as "0" in 32bits and "0L"
> > in 64bits (OS X, Linux)... For WinDog 64, this does not work, I do not
> > remember if there is some way to specify literals for
How about using:
extern void* PETSC_NULL
static void* PETSC_NULL=0L [or null or nullptr - based on configure determined
flags]
[so as to avoid language/functionality based #def() code in petscsys.h
- that could potentially cause issues like what we had with isinf()
stuff]
Satish
On Wed, 9 No
izes TM3 %d %d\n",rows,columns);
ierr = MatGetSize(AUXMAT2,&rows,&columns);
printf("check sizes AUXMAT2 %d %d\n",rows,columns);
--
Stefano
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/aa7e1ed4/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/2e8a43e2/attachment.html>
because those
types aren't checked by the compiler).
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/607ccbc1/attachment.html>
/pipermail/petsc-dev/attachments/2009/6b28ab9e/attachment.html>
To summarize:
In C we could do #define PETSC_NULL ((void*) 0) and every thing
would be fine
In C++ this won't work and there is no alternative except a standard that
is 2 months old (but for those programming in C++ this is not really a problem
because there is really no n
it by
adding one more component to src/dm/examples/tests/ex16.c and passing
PETSC_NULL as the last argument to DMCompositeScatter (for example).
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/6fe78959/attachment.html>
than two months old.
>
>
> We could pass a "format string" indicating which entries we were actually
> requesting. Other ideas?
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/874c1bd4/attachment.html>
is less than two months old.
We could pass a "format string" indicating which entries we were actually
requesting. Other ideas?
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/db92cb8c/attachment.html>
s scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/1a1d0295/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/741b7cb6/attachment.html>
ec being zeroed.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/44cf9169/attachment.html>
On 8 November 2011 09:51, Matthew Knepley wrote:
> On Tue, Nov 8, 2011 at 10:37 AM, Jose E. Roman wrote:
>>
>> The following code prints a vector of uninitialized entries.
>>
>> ?ierr = VecCreate(comm,&v);CHKERRQ(ierr);
>> ?ierr = VecSetSizes(v,n,n);CHKERRQ(ierr);
>> ?ierr = VecSetType(v,VECSEQCU
Jed,
So what both Satish's and Ethan's email are saying is so long as you tell
the Fortran function the interface that shows the type being returned you can
"trick" the Fortran into thinking that data type is just coming from another
Fortran routine.
I think this should resolve your
Mark,
Run with '-matmattransmult_color' or without this option if you want
test MatMatTransposeMult
Hong
On Wed, Nov 9, 2011 at 9:58 AM, Mark F. Adams
wrote:
> FYI: I appear to be getting not great flop rates out of these methods on my
> Mac:
>
> MatMatMult ? ? ? ? ? ? 2 1.0 1.1382e+00 1.0 8.4
On Nov 9, 2011, at 11:02 AM, Barry Smith wrote:
>
> On Nov 9, 2011, at 7:58 AM, Mark F. Adams wrote:
>
>> FYI: I appear to be getting not great flop rates out of these methods on my
>> Mac:
>
> Known issue. Do you have alternative algorithms that would crank it up?
> This is something we a
Mark,
Unlike what we though, R*A*Rt turns to be more difficult than PtAP
because sparse dot product
is inefficient. Barry's cool idea only works well on A*Rt for your
ex56.c thus far.
We are trying to understand what we get and exploring
It is not ready for you dive into R*A*Rt yet :-(
I'll l
Doesn't the bag construct do just this?
http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-dev/src/sys/examples/tutorials/ex5f90.F90.html
and
src/sys/bag/f90-custom/zbagf90.c
Ethan
On Tue, 2011-11-08 at 22:11 -0600, Satish Balay wrote:
> On Tue, 8 Nov 2011, Jed Brown wrote:
>
> > We have
FYI: I appear to be getting not great flop rates out of these methods on my Mac:
MatMatMult 2 1.0 1.1382e+00 1.0 8.48e+07 1.0 0.0e+00 0.0e+00
4.0e+00 4 1 0 0 2 12 8 0 0 275
MatPtAPNumeric 2 1.0 4.3557e+00 1.0 7.82e+08 1.0 0.0e+00 0.0e+00
0.0e+00 14 11 0 0 0
scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/1cc230dd/attachment.html>
ty.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/7c114d59/attachment.html>
> Hong, please update?src/docs/website/documentation/changes/dev.html when you
> make API changes.
Done and pushed to petsc-dev.
Hong
ate src/docs/website/documentation/changes/dev.html when
> you make API changes.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/fd993bb5/attachment.html>
ber/006213.html
Hong, please update src/docs/website/documentation/changes/dev.html when
you make API changes.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/2009/bef39e66/attachment.html>
Stefano:
MatMatMultTranspose() has been renamed. With latest petsc-dev:
MatTransposeMatMult - Performs Matrix-Matrix Multiplication C=A^T*B.
MatMatTransposeMult - Performs Matrix-Matrix Multiplication C=A*B^T.
I'm currently working on C=A*B^T. Report to us if you encounter problems.
Hong
> Hi,
On Nov 9, 2011, at 7:58 AM, Mark F. Adams wrote:
> FYI: I appear to be getting not great flop rates out of these methods on my
> Mac:
Known issue. Do you have alternative algorithms that would crank it up? This
is something we are actively working on.
Barry
>
> MatMatMult
50 matches
Mail list logo
