fix for initing / seting up preconditioners with adaptivity #38

Merged
merged 25 commits into from Feb 5, 2013

Projects

None yet

5 participants

@friedmud
Owner
friedmud commented Feb 4, 2013

This changes the way Preconditioners work. If people have custom Preconditioners they may need to update their objects to implement setup()

If you want to wait until after the 0.9 release to apply this, that's ok with me.

jwpeterson added some commits Feb 4, 2013
@jwpeterson jwpeterson Changes in adaptivity_ex2.C for -Wshadow.
Issue #24.
b4da774
@jwpeterson jwpeterson Changes in adaptivity_ex3.C for -Wshadow.
Issue #24.
e17c79e
@jwpeterson jwpeterson Changes in adaptivity_ex5.C for -Wshadow.
Issue #24.
729541a
@jwpeterson jwpeterson Changes in adjoints_ex1 for -Wshadow.
Issue #24.
b657617
@jwpeterson jwpeterson Changes in adjoints_ex2 for -Wshadow.
Issue #24.
e6f444c
@jwpeterson jwpeterson Changes in adjoints_ex3 for -Wshadow.
Issue #24.
cccdb62
@jwpeterson jwpeterson Changes in adjoints_ex4 for -Wshadow.
Issue #24.
2b9c717
@jwpeterson jwpeterson Don't include deprecated o_string_stream header. ba6afdd
@jwpeterson jwpeterson Fixes for unused variable warnings. 0dc8e2e
@jwpeterson jwpeterson Changes in adjoints_ex5 for -Wshadow.
Issue #24.
f957dea
@jwpeterson jwpeterson Changes in fem_system_ex1 for -Wshadow.
Issue #24.
6ccd84e
@jwpeterson jwpeterson Changes in fem_system_ex2 for -Wshadow.
Issue #24.
85a7e97
@jwpeterson jwpeterson Changes in miscellaneous_ex3 for -Wshadow.
Issue #24.
eb616e8
@jwpeterson jwpeterson Changes in type_vector.h for -Wshadow.
Issue #24.
fe3039d
@jwpeterson jwpeterson Changes in miscellaneous_ex4.C for -Wshadow.
Issue #24.
1b4c2a7
@jwpeterson jwpeterson Changes in miscellaneous_ex7.C for -Wshadow.
Issue #24.
2375c2c
@jwpeterson jwpeterson Changes in reduced_basis_ex1 for -Wshadow.
Issue #24.
0392b90
@jwpeterson jwpeterson Changes in reduced_basis_ex3 for -Wshadow.
Issue #24.
95d8003
@jwpeterson jwpeterson Changes in reduced_basis_ex4 for -Wshadow.
Issue #24.
1a5db52
@jwpeterson jwpeterson Changes in reduced_basis_ex5 for -Wshadow.
Issue #24.
3847f57
@jwpeterson jwpeterson Changes in transient_ex1 for -Wshadow.
Issue #24.
5bcca40
@jwpeterson jwpeterson Changes in vector_fe_ex2 for -Wshadow.
Issue #24.
5e0f961
@jwpeterson jwpeterson Changes in vector_fe_ex3 for -Wshadow.
Issue #24.
14f5c71
@jwpeterson jwpeterson Changes in reduced_basis_ex6 for -Wshadow.
Issue #24.
d99e3fc
Owner
benkirk commented Feb 5, 2013

I'm probably being paranoid, but would you mind changing the " out << " to " err << " ?

Otherwise I agree with @roystgnr, this is worth getting in 0.9.0.

Owner
friedmud commented Feb 5, 2013

Ok I'll fix that (and I saw that I wasn't checking the return of PCDestroy() so I'll fix that up as well) and then I'll push it in a bit later tonight.

Owner
friedmud commented Feb 5, 2013

Ok I pushed this manually... The hash is 213e204

BTW - if we fetch and rebase on master and push manually using

git push upstream HEAD:master

We won't have merge commits on Master. Just another friendly reminder......

@friedmud friedmud closed this Feb 5, 2013
Owner
roystgnr commented Feb 5, 2013

On Mon, 4 Feb 2013, Derek Gaston wrote:

BTW - if we fetch and rebase on master and push manually using
git push upstream HEAD:master
We won't have merge commits on Master. Just another friendly reminder......

I actually have moved on from "creating merge commits because I don't
know any better", but this isn't readily apparent because my current
attitude is "creating merge commits because I find I prefer them over
rebasing". If everyone else prefers the other way, though, I'll
switch to rebase.

Owner
benkirk commented Feb 5, 2013

On Feb 4, 2013, at 8:28 PM, roystgnr notifications@github.com wrote:

If everyone else prefers the other way, though, I'll
switch to rebase.

My understanding is you never rebase anything that's been pushed out to a 'public' site, which is how I consider even my own fork when working on multiple machines.
http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing

of course, my understanding may be limited...

-Ben

Owner
friedmud commented Feb 5, 2013

;-)

I still really hate merge commits.

At best they're confusing (they pull old changes forward... making it look like a change is happening again)

At worst they screw with bisections... and with backtracking and undoing changes in general.

Owner
roystgnr commented Feb 5, 2013

On Mon, 4 Feb 2013, Derek Gaston wrote:

I still really hate merge commits.

Your "really hate" trumps my "slightly prefer" for most changesets,
then. I'll try rebasing anything that's small enough not to have many
intermediate commits, to start. I'd like to keep merging anything
that was large enough to be worth branching for several commits,
though; both for the "no rewriting public history" reasons Ben
mentioned and for my own reason below:

At best they're confusing (they pull old changes forward... making
it look like a change is happening again)

John described that to me the other day; the command line tools seem
to make things clear enough (as clear you can get with a nonlinear
changeset), but his description of whatever GUI he was looking through
the logs with made it sound confusing, yeah.

At worst they screw with bisections... and with backtracking and
undoing changes in general.

I'd have expected the opposite to be true. That may just mean I don't
understand git yet.

Master begins in state A; I change it to state B, then C, testing as I
go. In the meantime someone has pushed state D to master.

In this case, the merged sequenced log looks like "A, then D, then B,
then C, then D+(C-A)", right? So that's confusing because the D->B
transition looks like a reversion, but it ought to be pretty nice for
regression testing, because B and C were exactly the same as the
states I tested.

And the alternative rebased log looks like "A, then D, then D+(B-A),
then D+(C-A)", right? And that's nice because it's more like what
we'd get from passing patches around, but in fact that intermediate
"D+(B-A)" state is one that never really existed and was never
actually tested.

Owner
benkirk commented Feb 5, 2013

I'm seeing this

  CXX    src/numerics/libmesh_opt_la-petsc_vector.lo
src/numerics/petsc_preconditioner.C: In member function 'virtual void libMesh::PetscPreconditioner<T>::init()':
src/numerics/petsc_preconditioner.C:74:32: error: cannot convert '_p_PC**' to 'PC {aka _p_PC*}' for argument '1' to 'PetscErrorCode PCDestroy(PC)'
make[1]: *** [src/numerics/libmesh_opt_la-petsc_preconditioner.lo] Error 1

on ubuntu-LTS with PETSc-3.1.

I loop over petsc 3.0, 3.1, 3.2, & 3.3 in a different test setup, but that will run tonight.

I'll see what else pops up.

@benkirk benkirk reopened this Feb 5, 2013
@benkirk benkirk merged commit 213e204 into libMesh:master Feb 5, 2013
Owner
friedmud commented Feb 5, 2013

Ben - I don't understand what you did here. Why did you open this and remerge it? I'm thoroughly confused.

As for the petsc issues... it might be an issue with 3.1 vs 3.3. I'll look into it in the morning

Owner
benkirk commented Feb 5, 2013

I'm confused too, just tried to reopen the comment thread. Noise.

-Ben

On Feb 4, 2013, at 10:38 PM, "Derek Gaston" <notifications@github.commailto:notifications@github.com> wrote:

Ben - I don't understand what you did here. Why did you open this and remerge it? I'm thoroughly confused.

As for the petsc issues... it might be an issue with 3.1 vs 3.3. I'll look into it in the morning


Reply to this email directly or view it on GitHubhttps://github.com/libMesh/libmesh/pull/38#issuecomment-13116614.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment