OK, I squashed, fixed the push line (and also did --global pull.ff only),
and pushed.
On Fri, May 27, 2016 at 9:07 AM, Jed Brown wrote:
> Mark Adams writes:
>
> >>
> >> Satish, please don't use this syntax for force pushes. Prefer
> >>
> >> git push origin +mark/snes-ex65c
> >>
> >
> > 08:13
Mark Adams writes:
>>
>> Satish, please don't use this syntax for force pushes. Prefer
>>
>> git push origin +mark/snes-ex65c
>>
>
> 08:13 mark/snes-ex56c<> ~/Codes/petsc$ git push origin +mark/snes-ex65c
> error: src refspec mark/snes-ex65c does not match any.
> error: failed to push some refs
On Fri, 27 May 2016, Satish Balay wrote:
> On Fri, 27 May 2016, Mark Adams wrote:
>
> > >
> > > Satish, please don't use this syntax for force pushes. Prefer
> > >
> > > git push origin +mark/snes-ex65c
> > >
> >
> > 08:13 mark/snes-ex56c<> ~/Codes/petsc$ git push origin +mark/snes-ex65c
> > e
On Fri, 27 May 2016, Mark Adams wrote:
> >
> > Satish, please don't use this syntax for force pushes. Prefer
> >
> > git push origin +mark/snes-ex65c
> >
>
> 08:13 mark/snes-ex56c<> ~/Codes/petsc$ git push origin +mark/snes-ex65c
> error: src refspec mark/snes-ex65c does not match any.
> error:
>
> Satish, please don't use this syntax for force pushes. Prefer
>
> git push origin +mark/snes-ex65c
>
08:13 mark/snes-ex56c<> ~/Codes/petsc$ git push origin +mark/snes-ex65c
error: src refspec mark/snes-ex65c does not match any.
error: failed to push some refs to 'g...@bitbucket.org:petsc/pet
>
>
> Mark,
>
> I ran 'alltest' for master - and 'mark/snes-ex56c' reverted some
> output file changes that shouldn't have been made [and some makefile
> changes] - and added one additional one that shows diffs.
>
>
thanks.
> ./configure --download-metis --download-parmetis --download-ml
> --down
Satish Balay writes:
> You should have done 'git push -f' You can repeat again..
Satish, please don't use this syntax for force pushes. Prefer
git push origin +mark/snes-ex65c
This is to avoid people with old versions of Git or a weird push.default
settings from obliterating other branches.
On Wed, 25 May 2016, Mark Adams wrote:
> >
> >
> > BTW: Its suspicious that you have to modify so many output files
> > [other than ones corresponding to ex56]
> >
>
> [and other cheby tests, GAMG sets cheby by default]
>
>
> >
> > for ex:
> > src/ksp/ksp/examples/tests/output/ex19_2.out
On Wed, May 25, 2016 at 1:01 PM, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> > I'm doing an all test right now, what should I do after that?
>
> You have a PR on this branch. It gets automatically updated with all
> the changes on it.
>
> You can add in a comment saying - "it
>
>
> BTW: Its suspicious that you have to modify so many output files
> [other than ones corresponding to ex56]
>
[and other cheby tests, GAMG sets cheby by default]
>
> for ex:
> src/ksp/ksp/examples/tests/output/ex19_2.out | 20 +-
>
This example does not use 'cheby' - but still you ha
On Wed, 25 May 2016, Satish Balay wrote:
> On Wed, 25 May 2016, Satish Balay wrote:
>
> > On Wed, 25 May 2016, Mark Adams wrote:
> >
> > > I'm doing an all test right now, what should I do after that?
> >
> > You have a PR on this branch. It gets automatically updated with all
> > the changes o
On Wed, 25 May 2016, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> > I'm doing an all test right now, what should I do after that?
>
> You have a PR on this branch. It gets automatically updated with all
> the changes on it.
>
> You can add in a comment saying - "its again re
On Wed, 25 May 2016, Mark Adams wrote:
> I'm doing an all test right now, what should I do after that?
You have a PR on this branch. It gets automatically updated with all
the changes on it.
You can add in a comment saying - "its again ready for review".
Someone [usually Barry or Jed or Matt] w
I'm doing an all test right now, what should I do after that?
On Wednesday, May 25, 2016, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> > On Wed, May 25, 2016 at 12:14 PM, Satish Balay > wrote:
> >
> > > Yeah - Sorry - bad copy/paste gave the wrong commit-id.
> > >
> > > Here
On Wed, 25 May 2016, Mark Adams wrote:
> On Wed, May 25, 2016 at 12:14 PM, Satish Balay wrote:
>
> > Yeah - Sorry - bad copy/paste gave the wrong commit-id.
> >
> > Here this the process you would normally follow [without gitk]
> >
> gitk works but it opens Wish. Can I squash in Wish?
I use gi
On Wed, May 25, 2016 at 12:14 PM, Satish Balay wrote:
> Yeah - Sorry - bad copy/paste gave the wrong commit-id.
>
> Here this the process you would normally follow [without gitk]
>
gitk works but it opens Wish. Can I squash in Wish?
Anyway, your rebase below worked, I got the list, squashed al
On Wed, May 25, 2016 at 12:08 PM, Satish Balay wrote:
> On Wed, 25 May 2016, Satish Balay wrote:
>
> > sorry - copy/paste error.
> >
> > git rebase -i f303cd651cc9f18b5b8505d3b571425f3b3e5c1a
> >
> > [f303cd651cc9f18b5b8505d3b571425f3b3e5c1a is commit in master - from
> where mark/snes-ex56c bran
Yeah - Sorry - bad copy/paste gave the wrong commit-id.
Here this the process you would normally follow [without gitk]
>From the 'git log master..branch' list below - you have to find the
starting commit - from where you want to rebase -i'.
So you would perhaps want the following to be the start
On Wed, 25 May 2016, Satish Balay wrote:
> sorry - copy/paste error.
>
> git rebase -i f303cd651cc9f18b5b8505d3b571425f3b3e5c1a
>
> [f303cd651cc9f18b5b8505d3b571425f3b3e5c1a is commit in master - from where
> mark/snes-ex56c branched off]
>
> I use 'master..mark/snes-ex56c' to determine this.
sorry - copy/paste error.
git rebase -i f303cd651cc9f18b5b8505d3b571425f3b3e5c1a
[f303cd651cc9f18b5b8505d3b571425f3b3e5c1a is commit in master - from where
mark/snes-ex56c branched off]
I use 'master..mark/snes-ex56c' to determine this.
Satish
On Wed, 25 May 2016, Mark Adams wrote:
> >
> >
>
Satish, this seems to have these intermediate commits that I want to
squash. But
git rebase -i 7216b81e99debbb3a0e1c5dd0b26b0d24a8a5ac0
does not show them to me?
12:01 mark/snes-ex56c= ~/Codes/petsc$ git log master..mark/snes-ex56c
commit 7216b81e99debbb3a0e1c5dd0b26b0d24a8a5ac0
Author: Mark Ad
>
>
> Ok - I've done a 'rebase master' and 'push -f' on mark/snes-ex56c
>
> You might want to do:
>
> git checkout mark/snes-ex56c
> git rebase -i 7216b81e99debbb3a0e1c5dd0b26b0d24a8a5ac0
>
>
done, but there was nothing in the rebase ("noop"). This is what I see:
noop
# Rebase 7216b81..7216b81 o
On Wed, 25 May 2016, Mark Adams wrote:
> On Wed, May 25, 2016 at 11:31 AM, Satish Balay wrote:
>
> > Mark,
> >
> > To simplify - lets start over..
> >
> > - you delete your copy of mark/snes-ex56c, jed/mark/snes-ex56c
> >
> > i.e:
> > git rebase --abort
> > git reset --hard
> > git checkout mast
On Wed, 25 May 2016, Mark Adams wrote:
> >
> >
> > If thats the case - when you have a merge conflict during 'merge' or
> > 'rebase' - then you should be able to do 'git mergetool' and easily
> > resolve the conflict using kdiff3
> >
> >
> OK, well this looks promising (kdiff3 seems to work, I thi
On Wed, May 25, 2016 at 11:31 AM, Satish Balay wrote:
> Mark,
>
> To simplify - lets start over..
>
> - you delete your copy of mark/snes-ex56c, jed/mark/snes-ex56c
>
> i.e:
> git rebase --abort
> git reset --hard
> git checkout master
> git branch -D mark/snes-ex56c jed/mark/snes-ex56c
>
done
>
>
> If thats the case - when you have a merge conflict during 'merge' or
> 'rebase' - then you should be able to do 'git mergetool' and easily
> resolve the conflict using kdiff3
>
>
OK, well this looks promising (kdiff3 seems to work, I think we set this up
long ago):
...
nothing added to commi
Mark,
To simplify - lets start over..
- you delete your copy of mark/snes-ex56c, jed/mark/snes-ex56c
i.e:
git rebase --abort
git reset --hard
git checkout master
git branch -D mark/snes-ex56c jed/mark/snes-ex56c
- Then I'll push to 'mark/snes-ex56c' [delete jed/mark/snes-ex56c on server]
- Af
On Wed, 25 May 2016, Mark Adams wrote:
> >
> >
> >
> > I have no idea how Mac users use git effectively without a working
> > 'gitk' [to verify commit diffs] or 'git gui' [to selectively commit
> > some changes] or 'kdiff3' which I use via 'git mergetool' [for 3-way
> > merges]..
> >
>
> Yes, I h
On Wed, May 25, 2016 at 11:14 AM, Satish Balay wrote:
> This is hopeless..
>
> Did you reset your 'mark/snes-ex56c' again to the old stuff?
>
> I don't get any merge conflicts - If I start from Jed's rebased/branch
> commit f2cb8422898d35ef96e146caa3a95b2f879b25f1
>
I did this from the non-jed v
>
>
>
> I have no idea how Mac users use git effectively without a working
> 'gitk' [to verify commit diffs] or 'git gui' [to selectively commit
> some changes] or 'kdiff3' which I use via 'git mergetool' [for 3-way
> merges]..
>
Yes, I have a lot of things that I would like to be able to do, like
This is hopeless..
Did you reset your 'mark/snes-ex56c' again to the old stuff?
I don't get any merge conflicts - If I start from Jed's rebased/branch commit
f2cb8422898d35ef96e146caa3a95b2f879b25f1
balay@asterix /home/balay/petsc (master=)
$ git co -b test f2cb8422898d35ef96e146caa3a95b2f879b2
On Wed, 25 May 2016, Mark Adams wrote:
> On Wed, May 25, 2016 at 10:18 AM, Satish Balay wrote:
>
> > On Wed, 25 May 2016, Mark Adams wrote:
> >
> > >
> > > 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
> > reset
> > > --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> > >
I do git rebase -i master, and I get a lot of these:
10:53 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
rebase -i master
error: could not apply 121daff... I am sick of finding examples that have
no test cases!
When you have resolved this problem, run "git rebase --continue".
If
On Wed, May 25, 2016 at 10:18 AM, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> >
> > 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
> reset
> > --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> > HEAD is now at f2cb842 fixed bug in makefile
> >
> > OK, n
On Wed, May 25, 2016 at 10:18 AM, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> >
> > 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
> reset
> > --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> > HEAD is now at f2cb842 fixed bug in makefile
> >
> > OK, n
On Wed, 25 May 2016, Mark Adams wrote:
> >
> >
> >> 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
> > reset --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> > HEAD is now at f2cb842 fixed bug in makefile
> >
> > OK, now what?
> >
> >
>
> I guess there is not much choice.
On Wed, 25 May 2016, Mark Adams wrote:
>
> 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git reset
> --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> HEAD is now at f2cb842 fixed bug in makefile
>
> OK, now what?
1. Verify that its feature complete as you expect [and not mi
>
>
>> 10:09 mark/snes-ex56c= ~/Codes/petsc/src/snes/examples/tutorials$ git
> reset --hard f2cb8422898d35ef96e146caa3a95b2f879b25f1
> HEAD is now at f2cb842 fixed bug in makefile
>
> OK, now what?
>
>
I guess there is not much choice. Pushed.
10:16 1 mark/snes-ex56c<> ~/Codes/petsc/src/snes/exa
On Wed, May 25, 2016 at 9:44 AM, Satish Balay wrote:
> On Wed, 25 May 2016, Mark Adams wrote:
>
> > I did 'git rebase -i master', in jed's branch and need to fix about 1/2
> > dozen failures to apply patch. I fixed them, but this does not seem like
> > what I should be doing. I also had many co
On Wed, 25 May 2016, Mark Adams wrote:
> I did 'git rebase -i master', in jed's branch and need to fix about 1/2
> dozen failures to apply patch. I fixed them, but this does not seem like
> what I should be doing. I also had many commits that were not mine, I
> guess because I pulled from master
I did 'git rebase -i master', in jed's branch and need to fix about 1/2
dozen failures to apply patch. I fixed them, but this does not seem like
what I should be doing. I also had many commits that were not mine, I
guess because I pulled from master. I squashed about 8 of mine and kept 2
of them
On Wed, 25 May 2016, Mark Adams wrote:
> Is rebase -i going to work? I read:
>
> git rebase -i master
>
> Note that rebasing to the master does not work if you merged the master
> into your feature branch while you were working on the new feature. If you
> did this you will need to find the ori
Mark Adams writes:
> Is rebase -i going to work?
Yes.
> I read:
>
> git rebase -i master
>
> Note that rebasing to the master does not work if you merged the master
> into your feature branch while you were working on the new feature. If you
> did this you will need to find the original branc
Is rebase -i going to work? I read:
git rebase -i master
Note that rebasing to the master does not work if you merged the master
into your feature branch while you were working on the new feature. If you
did this you will need to find the original branch point and call git
rebase with
a SHA1 rev
On Wed, May 25, 2016 at 8:00 AM, Jed Brown wrote:
> Mark Adams writes:
> > FYI, I get this error from rebasing. I will look into what they suggest.
>
> What command did you use to rebase?
>
git rebase master
>
> I ran "git rebase master" and fixed one trivial conflict in a makefile.
> The res
Mark Adams writes:
> FYI, I get this error from rebasing. I will look into what they suggest.
What command did you use to rebase?
I ran "git rebase master" and fixed one trivial conflict in a makefile.
The result is in 'jed/mark/snes-ex56c' if you want to check it out.
> warning: squelched 32 w
Mark Adams writes:
>>
>>
>> Firstly - we should not be cherry-picking commits to next. Its an
>> 'integration branch' i.e any required fixes go into the feature branch
>> that might have triggered the issue.
>>
>
> So I should just (re)merge my branch with my local next, as I fix it, pull
> from
On Tue, May 24, 2016 at 9:39 PM, Satish Balay wrote:
> On Tue, 24 May 2016, Satish Balay wrote:
>
> > On Tue, 24 May 2016, Jed Brown wrote:
>
> > > I would be in favor of either rewinding 'next' or reverting all of
> > > Mark's stuff (if you can identify well enough), then rebasing his
> branch
>
>
>
> Firstly - we should not be cherry-picking commits to next. Its an
> 'integration branch' i.e any required fixes go into the feature branch
> that might have triggered the issue.
>
So I should just (re)merge my branch with my local next, as I fix it, pull
from next, push to next.
I am thinki
On Tue, 24 May 2016, Satish Balay wrote:
> On Tue, 24 May 2016, Jed Brown wrote:
> > I would be in favor of either rewinding 'next' or reverting all of
> > Mark's stuff (if you can identify well enough), then rebasing his branch
> > so it's not such a mess.
>
> Its easy enough for me to rewind n
On Tue, 24 May 2016, Jed Brown wrote:
> Satish Balay writes:
> >> I checked Barry's commits and saw the mark/snes-ex56b and picked it in
> >> mark/snes-ex56c.
> >
> > Ok - this suggests I should revert 'mark/snes-ex56b' merge from next.
> > But there are other things in next that shouldn't be the
Satish Balay writes:
>> I checked Barry's commits and saw the mark/snes-ex56b and picked it in
>> mark/snes-ex56c.
>
> Ok - this suggests I should revert 'mark/snes-ex56b' merge from next.
> But there are other things in next that shouldn't be there [and that
> makes it difficult to track where th
On Tue, 24 May 2016, Mark Adams wrote:
> There are a lot of diffs like this. What make you think it is mine? The
> cheby changes should not create such a large diff.
Your pull request
https://bitbucket.org/petsc/petsc/pull-requests/479/mark-snes-ex56c/diff#chg-src/ksp/ksp/examples/tests/output/
On Tue, 24 May 2016, Mark Adams wrote:
> > Mark,
> >
> > Currently there is a bit of mess in regards to your branches.
> >
>
> Yes. This got messy because I was building on Matt's work. mark/snes-ex56c
> super seeds everything else.
>
> I used cherry-pick to duplicate commits in next. This may
There are a lot of diffs like this. What make you think it is mine? The
cheby changes should not create such a large diff.
On Tue, May 24, 2016 at 3:23 PM, Satish Balay wrote:
> Another issue:
>
>
> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/05/24/examples_next_arch-cuda-double_e
On Tue, May 24, 2016 at 2:53 PM, Satish Balay wrote:
> On Tue, 24 May 2016, Mark Adams wrote:
>
> > Do I now wait for my pull request to be approved?
>
> Mark,
>
> Currently there is a bit of mess in regards to your branches.
>
Yes. This got messy because I was building on Matt's work. mark/sne
thanks,
On Tue, May 24, 2016 at 2:56 PM, Satish Balay wrote:
> On Tue, 24 May 2016, Barry Smith wrote:
>
> >
> > After you put something in next you need go to
> ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/index.html follow the next
> link and click on the all button in the upper right hand si
Another issue:
http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2016/05/24/examples_next_arch-cuda-double_es.log
/scratch/petsc/petsc.clone/src/ksp/ksp/examples/tests
Possible problem with ex26_1, diffs above
balay@asterix /home/balay/petsc (next=)
$ git diff master..next -- src/ksp/ksp/exa
On Tue, 24 May 2016, Barry Smith wrote:
>
> After you put something in next you need go to
> ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/index.html follow the next link
> and click on the all button in the upper right hand side to make sure the
> examples/tests work on all machines.
I'll su
> On May 24, 2016, at 4:25 PM, Mark Adams wrote:
>
>
>
> On Tue, May 24, 2016 at 2:20 PM, Satish Balay wrote:
> Well 'git merge master' on this branch doesn't help with this concern.
>
> The process is
> - don't merge to next until feature complete
> [in this stage - you can rebase against m
On Tue, 24 May 2016, Mark Adams wrote:
> Do I now wait for my pull request to be approved?
Mark,
Currently there is a bit of mess in regards to your branches.
$ git branch -r |grep mark |grep ex56
origin/mark/ksp-ex56
origin/mark/ksp-newex56
origin/mark/snes-ex56b
origin/mark/snes-ex56c
On Tue, May 24, 2016 at 2:20 PM, Satish Balay wrote:
> Well 'git merge master' on this branch doesn't help with this concern.
>
> The process is
> - don't merge to next until feature complete
> [in this stage - you can rebase against master as many times as necessary]
>
> - on feature completion
Well 'git merge master' on this branch doesn't help with this concern.
The process is
- don't merge to next until feature complete
[in this stage - you can rebase against master as many times as necessary]
- on feature completion - merge to next
- and monitor 'next' tests dashboard - until all r
OK, so you just trust that working in next is proof that it will work in
master and just 'git merge branch' in master without ever doing a 'git
merge master' in branch.
Do I now wait for my pull request to be approved?
On Tue, May 24, 2016 at 12:12 AM, Jed Brown wrote:
> Mark Adams writes:
>
Mark Adams writes:
> I am merging master more than I need to, just to be up to date. I guess it
> pollutes the history with all these merges. And I should squash them...
You shouldn't merge from 'master' unless you need something specific,
and in that case, write a commit message explaining wha
>
>
>
> Firstly - if you need Matt's stuff (requiring a merge) - that implies
> the feature is not yet complete. So it should not be merged to next
> [until the feature is complete]
>
It was in next, but not in master. It is all in master now.
>
> But if 'Matt does and it is not in master' - th
On Fri, 20 May 2016, Mark Adams wrote:
> On Fri, May 20, 2016 at 1:17 PM, Satish Balay wrote:
>
> > Mark,
> >
> > $ git log --merges origin/mark/snes-ex56c --oneline |grep mark/snes-ex56c
> > 27d400f Merge branch 'master' of bitbucket.org:petsc/petsc into
> > mark/snes-ex56c
> > f3dabe8 Merge br
On Fri, May 20, 2016 at 1:17 PM, Satish Balay wrote:
> Mark,
>
> $ git log --merges origin/mark/snes-ex56c --oneline |grep mark/snes-ex56c
> 27d400f Merge branch 'master' of bitbucket.org:petsc/petsc into
> mark/snes-ex56c
> f3dabe8 Merge branch 'master' of bitbucket.org:petsc/petsc into
> mark/s
Mark,
$ git log --merges origin/mark/snes-ex56c --oneline |grep mark/snes-ex56c
27d400f Merge branch 'master' of bitbucket.org:petsc/petsc into mark/snes-ex56c
f3dabe8 Merge branch 'master' of bitbucket.org:petsc/petsc into mark/snes-ex56c
1df2bc2 Merge branch 'master' of bitbucket.org:petsc/petsc
On Thu, 19 May 2016, Satish Balay wrote:
> I was going to push the following fix to mark/snes-ex56c.
>
> diff --git a/src/ksp/ksp/impls/cheby/cheby.c b/src/ksp/ksp/impls/cheby/cheby.c
> index f2a26bf..722d32d 100644
> --- a/src/ksp/ksp/impls/cheby/cheby.c
> +++ b/src/ksp/ksp/impls/cheby/cheby.c
>
Mark,
petsc 'next' doesn't build for complex due to error in cheby.c
$ git branch -r --contains d5742a2a619a688a61daaaef5bdde3042d32f41a
origin/next
$ git branch -r --contains eb041292
origin/mark/snes-ex56c
origin/next
Perhaps you have merged mark/snes-ex56c to next pushed next - but not
> On May 19, 2016, at 10:03 AM, Mark Adams wrote:
>
>
>
> On Tue, May 17, 2016 at 10:55 PM, Barry Smith wrote:
>
> Mark,
>
>So it sounds like the right fix is to change the "random" option name to
> "noisy" and replace the use of the random number generator with Jed's hash
> and mak
On Tue, May 17, 2016 at 10:55 PM, Barry Smith wrote:
>
> Mark,
>
>So it sounds like the right fix is to change the "random" option name
> to "noisy" and replace the use of the random number generator with Jed's
> hash and make it the default. (Where if you turn off the noisy it uses the
> r
Mark,
So it sounds like the right fix is to change the "random" option name to
"noisy" and replace the use of the random number generator with Jed's hash and
make it the default. (Where if you turn off the noisy it uses the right hand
side which is useful for debugging the solvers) If you
Barry Smith writes:
> So are you proposing we have three options
> KSPChebyshevEstEigSetRHSType() with (1) "use give rhs", (2) "use
> random rhs", (3) "use hash scheme to produce same right hand side
> independent of number of processes so long as the ordering stays the
> same" or are yo
> On May 17, 2016, at 9:25 PM, Jed Brown wrote:
>
> The relevance is when someone writes their problem matrix to disk and we read
> it back. Or, for those that use space filling curves to order their dofs
> (many use them to order elements).
Jed,
So are you proposing we have three option
> On May 17, 2016, at 7:29 PM, Jed Brown wrote:
>
> That is my suggestion and I think you should use it so it's easier to debug.
>
As Jed already noted this approach only works if the ordering remains the
same when you change the number of processes which I submit is almost never
true in
That is my suggestion and I think you should use it so it's easier to debug.
On May 17, 2016 5:11:42 PM PDT, Mark Adams wrote:
>OK, I thought you were suggesting that:
>
>unsigned int hash(unsigned int x) {
>x = ((x >> 16) ^ x) * 0x45d9f3b;
>x = ((x >> 16) ^ x) * 0x45d9f3b;
>x = ((x >
OK, I thought you were suggesting that:
unsigned int hash(unsigned int x) {
x = ((x >> 16) ^ x) * 0x45d9f3b;
x = ((x >> 16) ^ x) * 0x45d9f3b;
x = ((x >> 16) ^ x);
return x;}
But, Barry is vetoing this.
On Tue, May 17, 2016 at 4:18 PM, Jed Brown wrote:
> Mark Adams writes:
>
>
> On May 17, 2016, at 2:27 PM, Mark Adams wrote:
>
> Other than set userandom = PETSC_TRUE, should I do anything else?
Nothing else. Update the changes/dev.html document and state in the manual page
that it uses random by default
>
> I see:
>
> ierr = VecSetRandom(B,cheb->random);CHKERRQ(ie
Mark Adams writes:
> Why not just set each index with hash(i) = (i >> 32)^i and forget
> VecSetRandom in here?
Because if your vertices are numbered lexicographically on a Cartesian
grid, this gives you a plane. But just put in the legit hash (the one I
linked is pretty good) and then you don'
Why not just set each index with hash(i) = (i >> 32)^i and forget
VecSetRandom in here? This does not have to be perfectly decorrelated. Just
not perfectly correlated.
{
PetscErrorCode ierr;
PetscInt n = xin->map->n,i;
PetscScalar*xx;
PetscFunctionBegin;
ierr = VecGetArray(xin
Matthew Knepley writes:
> It seems like we should do double dispatch for VecSetRandom().
Unnecessarily complicated.
signature.asc
Description: PGP signature
Matthew Knepley writes:
> On Tue, May 17, 2016 at 2:27 PM, Mark Adams wrote:
>
>> Other than set userandom = PETSC_TRUE, should I do anything else?
>>
>> I see:
>>
>> ierr = VecSetRandom(B,cheb->random);CHKERRQ(ierr);
>>
>> Should I use a special one or change this default to the special one?
>>
Matthew Knepley writes:
> Should we just make this another Random implementation which is only for
> testing?
The problem is that we want to produce the same numbers on one process
and on many processes. The interface doesn't really afford that because
it provides a stream of numbers. If we kno
On Tue, May 17, 2016 at 2:34 PM, Jed Brown wrote:
> Matthew Knepley writes:
> > Should we just make this another Random implementation which is only for
> > testing?
>
> The problem is that we want to produce the same numbers on one process
> and on many processes. The interface doesn't really
On Tue, May 17, 2016 at 2:27 PM, Mark Adams wrote:
> Other than set userandom = PETSC_TRUE, should I do anything else?
>
> I see:
>
> ierr = VecSetRandom(B,cheb->random);CHKERRQ(ierr);
>
> Should I use a special one or change this default to the special one?
>
I think Jed means this:
Make a s
Other than set userandom = PETSC_TRUE, should I do anything else?
I see:
ierr = VecSetRandom(B,cheb->random);CHKERRQ(ierr);
Should I use a special one or change this default to the special one?
On Tue, May 17, 2016 at 3:19 PM, Matthew Knepley wrote:
> On Tue, May 17, 2016 at 2:11 PM, Jed Brow
On Tue, May 17, 2016 at 2:11 PM, Jed Brown wrote:
> Barry Smith writes:
> > Sounds like Jed is saying he is ok with making the default use the
> > random number generator. Do this in a branch and be aware that you
> > have to update a bunch of the test output files to match the new
> > c
Barry Smith writes:
> Sounds like Jed is saying he is ok with making the default use the
> random number generator. Do this in a branch and be aware that you
> have to update a bunch of the test output files to match the new
> convergence histories introduced by the change.
Sure, but if i
> On May 17, 2016, at 1:18 PM, Jed Brown wrote:
>
> Barry Smith writes:
>> Of course, as always, with different number of processes one will
>> get different results, even with Jacobi + Chebyshev because the
>> random numbers generated will be different with different number of
>> processes
Barry Smith writes:
> Of course, as always, with different number of processes one will
> get different results, even with Jacobi + Chebyshev because the
> random numbers generated will be different with different number of
> processes, is this important?
I can't think of a way to get a "
Since Matt wrote a portable random number generator as the default random
number generator there should be no difference on any machine based on using
using a random right hand side.
Of course, as always, with different number of processes one will get
different results, even with Jacob
On Sat, Aug 22, 2015 at 10:39 PM, Barry Smith wrote:
>
> > On Aug 22, 2015, at 9:26 PM, Mark Adams wrote:
> >
> > I would vote for (1).
> >
> > Also, I hope cheb->random is the default.
>
>Well then different machines will produce different convergence
> histories which is annoying for any
Mark Adams writes:
> The point is that it is possible to have a process invariant test, as
> opposed to impossible. PETSc's MIS is not invariant now anyway.
If we want something invariant that is algorithmically defensible, we
have to use a quality hash function. It's entirely feasible, we jus
>
>
>What "global idea"? Even with something simple like DMDA the "global
> idea" of a variable depends on the number of processes, similarly if one is
> doing any kind of partitioner on the unknowns the ordering changes with the
> number of processors.
>
>
The point is that it is possible to
Mark Adams writes:
> Is there a good way to get a deterministic rand wrt number of processors?
> Seeding rand for each entry, with its global ID would work I assume.
No, no, no. That's basically the same nonsense as your pseudo "hash"
function. PRNGs are designed so the stream of random number
> On Aug 28, 2015, at 6:52 AM, Matthew Knepley wrote:
>
> On Fri, Aug 28, 2015 at 6:02 AM, Mark Adams wrote:
> Is there a good way to get a deterministic rand wrt number of processors?
> Seeding rand for each entry, with its global ID would work I assume.
What "global idea"? Even with so
On Fri, Aug 28, 2015 at 6:02 AM, Mark Adams wrote:
> Is there a good way to get a deterministic rand wrt number of processors?
> Seeding rand for each entry, with its global ID would work I assume.
>
> If drand48 is just one line then why not just copy it tweak it as desired?
>
I did. Its in nex
What should I do if the DIVERGE_ITS test fails? I assume abort.
And I assume I can put these two items (Cheby solve test and put petsc rand
vectors back in GAMG and Cheby) in one branch.
On Thu, Aug 27, 2015 at 5:50 PM, Jed Brown wrote:
> Mark Adams writes:
>
> > OK, I can put PetscRandom bac
1 - 100 of 135 matches
Mail list logo
