On Thu, 7 Jan 2010 14:52:41 -0600, Barry Smith wrote:
> There would be no SNES in this context! One would be able to
> cleanly and simply (more so then today) put geometric multigrid inside
> a Schure fieldsplit preconditioner. If one can't then we screwed up
> our new design.
I think
On Fri, 8 Jan 2010, Kevin.Buckley at ecs.vuw.ac.nz wrote:
> Hello again,
>
> this follows on somewhat from my earliar posting regarding
> initial experiences building and running PETSc for the
> NetBSD platform.
>
> Having built both PETSc and the application that uses it
> for our NetBSD hosted
On Thu, 7 Jan 2010 14:19:48 -0600, Barry Smith wrote:
>
> On Jan 7, 2010, at 2:16 PM, Jed Brown wrote:
>
> > On Thu, 7 Jan 2010 14:09:21 -0600, Barry Smith
> > wrote:
> >>Yes we would lose that functionality. But maybe ok since the
> >> Cascadic multigrid is pretty much mesh sequencing.
>
On Thu, 7 Jan 2010 14:09:21 -0600, Barry Smith wrote:
> Yes we would lose that functionality. But maybe ok since the
> Cascadic multigrid is pretty much mesh sequencing.
> We could avoid supporting adaptive mesh refinement for linear problems
> (linear problems are silly anyways :-)).
Yes
On Thu, 7 Jan 2010 08:34:40 -0600, Barry Smith wrote:
>I would not like to see them split up again. Rather I would like to
> see the linear part of DMMG put into KSP/PC/DMMG somehow (not exactly
> sure how) so it can be properly nested and composed just like other
> preconditioners. I'm
On Thu, 7 Jan 2010 08:33:40 -0600, Barry Smith wrote:
>
>Change sounds reasonable to me.
Pushed ae3acc66e398
Jed
People.
> >24(PETSC_VERSION_RELEASE == 1))
> >
> > What is going on?
>
> No, you quoted a conditional. Look at the top of the file.
Yes, THAT is what I have been missing... My bad (or, y very bad).
I'll see what I can do with what I want to get done with this.
Many thanks Matt, Jed, an
On Thu, 7 Jan 2010 17:20:10 +0100 (CET), "Toby D. Young" wrote:
>
> > Sounds like you're getting a header from the wrong place
> >
> >
> > http://petsc.cs.iit.edu/petsc/petsc-dev/file/4466b94188f4/include/petscversion.h
>
> Could be that Jed, and anyways I am rebuilding from scratch.
> But on
On Thu, 7 Jan 2010 10:07:32 -0600, Matthew Knepley wrote:
> Where is all this stuff (and what) ?
C-. _n_
Possible completions are:
_n_ClassPerfLog
_n_ClassRegLog
_n_DMMG
_n_EventPerfLog
_n_EventRegLog
_n_ISColoring
_n_IntStack
_n_PetscBag
_n_PetscBagItem
_n_PetscDLLibrary
_n_PetscFLis
> Sounds like you're getting a header from the wrong place
>
>
> http://petsc.cs.iit.edu/petsc/petsc-dev/file/4466b94188f4/include/petscversion.h
Could be that Jed, and anyways I am rebuilding from scratch.
But on your link above PETSC_VERSION_RELEASE == 1 too...
author barrysmith at barry-s
On Thu, 7 Jan 2010 17:01:09 +0100 (CET), "Toby D. Young" wrote:
>
>
> > In petscversion.h there is PETSC_VERSION_RELEASE, which is 1 (release)
> > or 0 (development).
>
> Thank you Jose... so the solution exists already. Many thanks. I
> deliberately overlooked this because:
>
> The weird thin
> In petscversion.h there is PETSC_VERSION_RELEASE, which is 1 (release)
> or 0 (development).
Thank you Jose... so the solution exists already. Many thanks. I
deliberately overlooked this because:
The weird thing: my petsc-dev says PETSC_VERSION_RELEASE = 1, and it is
not! Same goes for SLEPC_
In petscversion.h there is PETSC_VERSION_RELEASE, which is 1 (release)
or 0 (development).
Jose
On 07/01/2010, Toby D. Young wrote:
> Dear developers,
>
> I am a satisfied user of PETSc and SLEPc through the interfaces
> provided
> by the deal.ii library. The problem I am trying to deal with
Dear developers,
I am a satisfied user of PETSc and SLEPc through the interfaces provided
by the deal.ii library. The problem I am trying to deal with is related to
changes in releases of PETSc that break the interfaces we have (because
for better or for worse the changes are not backward compati
You misunderstood my comment. I was not not trying to state that
linear problems are silly, not at all. Only that I'm not interesting
in adaptive mesh refinement on a purely linear problem.
Barry
On Jan 7, 2010, at 3:06 PM, Jed Brown wrote:
> On Thu, 7 Jan 2010 14:52:41 -0600, Barry
This currently prints the range scaled by da->w which is an
implementation detail (flattening) that users should not need to be
aware of. Any objections to having this report the ranges obtained by
DAGetLocalInfo?
Jed
On Jan 7, 2010, at 2:16 PM, Jed Brown wrote:
> On Thu, 7 Jan 2010 14:09:21 -0600, Barry Smith
> wrote:
>>Yes we would lose that functionality. But maybe ok since the
>> Cascadic multigrid is pretty much mesh sequencing.
>> We could avoid supporting adaptive mesh refinement for linear
>>
On Jan 7, 2010, at 2:16 PM, Jed Brown wrote:
> On Thu, 7 Jan 2010 14:09:21 -0600, Barry Smith
> wrote:
>>Yes we would lose that functionality. But maybe ok since the
>> Cascadic multigrid is pretty much mesh sequencing.
>> We could avoid supporting adaptive mesh refinement for linear
>>
I'm using a DMMG inside of a Schur fieldsplit, but I have to create it
before PCSetUp because the hierarchy is generated by refinement. It
doesn't make sense to call DMMGSetKSP before PCSetUp because that matrix
would be worthless, but I want to be able to view the DMMG even if only
to inspect the
On Jan 7, 2010, at 2:05 PM, Jed Brown wrote:
> On Thu, 7 Jan 2010 08:34:40 -0600, Barry Smith
> wrote:
>> I would not like to see them split up again. Rather I would like to
>> see the linear part of DMMG put into KSP/PC/DMMG somehow (not exactly
>> sure how) so it can be properly nested and
added the following.
Satish
--
2.5.3Simple PETSc Objects
There are some simple PETSc objects that do not need PETSCHEADER - and the
associated
functionality. These objects are internally named as _n_ as opposed to
_p_.
For eg: _n_PetscTable vs _p_Vec.
On Thu, 7 Jan 2010, Barry Sm
They are identical.
Also, is there a mnemonic for the _n_* prefix?
Jed
Thanks for the reminder. Now if hg's gui's didn't totally suck I
would have found that.
No, don't change it. It is good for them to be different. Please
add this sentence to developers.tex so we remember it.
Thanks
Barry
On Jan 7, 2010, at 10:45 AM, Satish Balay wrote:
>
>>
3d5df68fd46b
Author: balay at asterix.mcs.anl.gov 2005-05-26 14:19:16
PETSc ojects [with PETSCHEADER] - use _p_ - else use _n_
<
I don't remember the discussions at that time for this change - so I'm
fine with reverting..
Satish
On Thu, 7 Jan 2010, Jed Brow
On Jan 7, 2010, at 10:32 AM, Matthew Knepley wrote:
> On Thu, Jan 7, 2010 at 10:27 AM, Barry Smith
> wrote:
>
> On Jan 7, 2010, at 10:10 AM, Matthew Knepley wrote:
>
> On Thu, Jan 7, 2010 at 9:12 AM, Barry Smith
> wrote:
>
> Let's get this dang PETSc release out the door and then fix up th
You are looking at a macro check. The define is at:
4 #define PETSC_VERSION_RELEASE0
Since this is dev, PETSC_VERSION_(3,0,0) will always return 0
Satish
On Thu, 7 Jan 2010, Toby D. Young wrote:
>
> > Sounds like you're getting a header from the wrong place
> >
> >
> > http://pet
it.
>>
>> Is there value in having DMMG usable in the absence of libpetscsnes
>> (i.e. DMMGSetUp's dependency on SNES will be broken)?
>>
>> Jed
>>
>>
>>
>>
>>
>> --
>> 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
>>
>
>
--
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/20100107/b1af1a30/attachment.html>
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/20100107/724134a7/attachment.html>
ww.ippt.gov.pl/%7Etyoung>
> skype: stenografia
>
>
--
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/20100107/bdeb81e2/attachment.html>
On Jan 7, 2010, at 10:10 AM, Matthew Knepley wrote:
> On Thu, Jan 7, 2010 at 9:12 AM, Barry Smith
> wrote:
>
> Let's get this dang PETSc release out the door and then fix up the
> solvers by properly merging DMMG into KSP and SNES
>
> 1) What do we need for the release?
>
> 2) It seems that
Etags search for _n_ I assumed that you did this.
Barry
On Jan 7, 2010, at 10:07 AM, Matthew Knepley wrote:
> On Thu, Jan 7, 2010 at 8:22 AM, Barry Smith
> wrote:
>
> On Jan 7, 2010, at 3:50 AM, Jed Brown wrote:
>
> They are identical.
>
> Looks like someone added the DMMGGetDMMG()
nt of DMComposite+PCFieldSplit.
>>>
>>> Is there value in having DMMG usable in the absence of libpetscsnes
>>> (i.e. DMMGSetUp's dependency on SNES will be broken)?
>>>
>>> Jed
>>>
>>
>>
>
--
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/20100107/269d7a3d/attachment.html>
ranted 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/20100107/3c4687d1/attachment.html>
On Thu, 7 Jan 2010, Toby D. Young wrote:
>
>
> > In petscversion.h there is PETSC_VERSION_RELEASE, which is 1 (release)
> > or 0 (development).
>
> Thank you Jose... so the solution exists already. Many thanks. I
> deliberately overlooked this because:
>
> The weird thing: my petsc-dev says PE
Let's get this dang PETSc release out the door and then fix up the
solvers by properly merging DMMG into KSP and SNES
Barry
On Jan 7, 2010, at 8:34 AM, Barry Smith wrote:
>
> DMMG used to be split up (as you note from the stale comment). I
> ended up merging them because it wasn't
DMMG used to be split up (as you note from the stale comment). I
ended up merging them because it wasn't worth the effort and
complication to keep them in two parts.
I would not like to see them split up again. Rather I would like to
see the linear part of DMMG put into KSP/PC/DMMG so
Change sounds reasonable to me.
Barry
On Jan 7, 2010, at 8:23 AM, Jed Brown wrote:
> This currently prints the range scaled by da->w which is an
> implementation detail (flattening) that users should not need to be
> aware of. Any objections to having this report the ranges obtained by
On Jan 7, 2010, at 3:50 AM, Jed Brown wrote:
> They are identical.
Looks like someone added the DMMGGetDMMG() who didn't know about
the other one. I have removed it.
>
> Also, is there a mnemonic for the _n_* prefix?
Looks like someone went crazy encapsulating tons of stuff that
di
On Wed, 6 Jan 2010 14:45:33 -0600 (CST), Satish Balay
wrote:
> There was also a need to not include 'stdio.h' before mpi.h [for c++]
> - and we can't control this usage in user code. MPICH_SKIP_MPICXX has
> prevented this issue form coming up.
>
> [Perhaps newer versions of mpich/openmpi workarr
39 matches
Mail list logo
