February 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Problem with MUMPS+metis
by Sean Farley 20 Feb '12

20 Feb '12

> > I can confirm that. The same problem happens to me, even though with mumps > and metis obtained from official site this doesn't happen. Hmmm, which versions are you referring to for mumps+metis from the official site? Last time I checked, mumps couldn't link to the newest metis.

1 0

Re: [petsc-dev] Problem with MUMPS+metis
by agrayver＠gfz-potsdam.de 20 Feb '12

20 Feb '12

I can confirm that. The same problem happens to me, even though with mumps and metis obtained from official site this doesn't happen. Regards, Alexander ----- Reply message ----- From: "John Fettig" <john.fettig(a)gmail.com> To: "For users of the development version of PETSc" <petsc-dev(a)mcs.anl.gov> Subject: [petsc-dev] Problem with MUMPS+metis Date: Mon, Feb 20, 2012 18:48 When I run MUMPS in parallel with parmetis ordering (icntl(28)=2, icntl(29)=2), everything seems to work fine. However, if I try to run it serially it reverts back to metis ordering and seems to get caught in some kind of infinite recursion. I've run it through valgrind and attached the output. Also I attached it to a debugger and the stack is enormous when it hangs, something like 10,000 frames deep. You can sort of see that from the valgrind output towards the end. My question is: who do you suspect to be at fault here? Is it a bug in MUMPS, metis, or PETSc? My suspicion is MUMPS. This is with the PETSc-automatically compiled MUMPS, metis, and parmetis, retrieved today. Thanks, John

1 0

Re: [petsc-dev] Problem with MUMPS+metis
by John Fettig 20 Feb '12

20 Feb '12

Bah, nevermind. That was evidently a bug in GDB (debugging intel-compiled executable). The argument is non-null in idbc. John On Mon, Feb 20, 2012 at 1:01 PM, John Fettig <john.fettig(a)gmail.com> wrote: > As a follow-up, if I break at the call to metis inside mumps > (metis_nodend_), the argument adjncy=0x0. I guess I'll be emailing the > mumps list about this. > > Thanks, > John > > > On Mon, Feb 20, 2012 at 12:48 PM, John Fettig <john.fettig(a)gmail.com>wrote: > >> When I run MUMPS in parallel with parmetis ordering (icntl(28)=2, >> icntl(29)=2), everything seems to work fine. However, if I try to run it >> serially it reverts back to metis ordering and seems to get caught in some >> kind of infinite recursion. I've run it through valgrind and attached the >> output. Also I attached it to a debugger and the stack is enormous when it >> hangs, something like 10,000 frames deep. You can sort of see that from >> the valgrind output towards the end. >> >> My question is: who do you suspect to be at fault here? Is it a bug in >> MUMPS, metis, or PETSc? My suspicion is MUMPS. This is with the >> PETSc-automatically compiled MUMPS, metis, and parmetis, retrieved today. >> >> Thanks, >> John >> >> >

1 0

Re: [petsc-dev] Problem with MUMPS+metis
by John Fettig 20 Feb '12

20 Feb '12

As a follow-up, if I break at the call to metis inside mumps (metis_nodend_), the argument adjncy=0x0. I guess I'll be emailing the mumps list about this. Thanks, John On Mon, Feb 20, 2012 at 12:48 PM, John Fettig <john.fettig(a)gmail.com> wrote: > When I run MUMPS in parallel with parmetis ordering (icntl(28)=2, > icntl(29)=2), everything seems to work fine. However, if I try to run it > serially it reverts back to metis ordering and seems to get caught in some > kind of infinite recursion. I've run it through valgrind and attached the > output. Also I attached it to a debugger and the stack is enormous when it > hangs, something like 10,000 frames deep. You can sort of see that from > the valgrind output towards the end. > > My question is: who do you suspect to be at fault here? Is it a bug in > MUMPS, metis, or PETSc? My suspicion is MUMPS. This is with the > PETSc-automatically compiled MUMPS, metis, and parmetis, retrieved today. > > Thanks, > John > >

1 0

Problem with MUMPS+metis
by John Fettig 20 Feb '12

20 Feb '12

When I run MUMPS in parallel with parmetis ordering (icntl(28)=2, icntl(29)=2), everything seems to work fine. However, if I try to run it serially it reverts back to metis ordering and seems to get caught in some kind of infinite recursion. I've run it through valgrind and attached the output. Also I attached it to a debugger and the stack is enormous when it hangs, something like 10,000 frames deep. You can sort of see that from the valgrind output towards the end. My question is: who do you suspect to be at fault here? Is it a bug in MUMPS, metis, or PETSc? My suspicion is MUMPS. This is with the PETSc-automatically compiled MUMPS, metis, and parmetis, retrieved today. Thanks, John

1 0

Re: [petsc-dev] Merge sets
by Jed Brown 19 Feb '12

19 Feb '12

This is racy, we talked about it before. On Feb 18, 2012 11:15 PM, "Sean Farley" <sean(a)mcs.anl.gov> wrote: > Ah, I don't see it because the Python build uses md5. Doesn't cmake? >> > > I don't think 'make' is the annoyance here, at least, not to me. If I > recall correctly, last time, Barry couldn't stand emac's insistence on > asking 'should I reload this buffer' even when nothing changed on disk > except for the timestamp. Following this thread: > > > http://stackoverflow.com/questions/665600/how-can-i-get-emacs-to-revert-all… > > you can either set (global-auto-revert-mode) or try using the revbufs > extension. >

1 0

Re: [petsc-dev] Fwd: Undelivered Mail Returned to Sender
by Jed Brown 19 Feb '12

19 Feb '12

Rebase changes mtime on files that are changed in "my" copy, but not in the upstream version. Matt, you are just reading the wrong (i.e. unhelpful) side of the diff. On Feb 18, 2012 9:45 PM, "Matthew Knepley" <knepley(a)gmail.com> wrote: > Fix the mail headers for this thing. My message is below. > > Matt > > ---------- Forwarded message ---------- > From: Mail Delivery System <MAILER-DAEMON(a)mailrelay.anl.gov> > Date: Sat, Feb 18, 2012 at 9:44 PM > Subject: Undelivered Mail Returned to Sender > To: knepley(a)gmail.com > > > This is the mail system at host mailrelay.anl.gov. > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to postmaster. > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The mail system > > <petsc-dev(a)zimbra.anl.gov>: host zimbra.anl.gov[130.202.101.12] said: 550 > 5.1.1 > <petsc-dev(a)zimbra.anl.gov>: Recipient address rejected: zimbra.anl.gov(in > reply to RCPT TO command) > > Final-Recipient: rfc822; petsc-dev(a)zimbra.anl.gov > Original-Recipient: rfc822;petsc-dev(a)zimbra.anl.gov > Action: failed > Status: 5.1.1 > Remote-MTA: dns; zimbra.anl.gov > Diagnostic-Code: smtp; 550 5.1.1 <petsc-dev(a)zimbra.anl.gov>: Recipient > address > rejected: zimbra.anl.gov > > > ---------- Forwarded message ---------- > From: Matthew Knepley <knepley(a)gmail.com> > To: petsc-dev(a)zimbra.anl.gov, For users of the development version of > PETSc <petsc-dev(a)mcs.anl.gov> > Cc: > Date: Sat, 18 Feb 2012 21:44:32 -0600 > Subject: Re: [petsc-dev] Merge sets > On Sat, Feb 18, 2012 at 9:28 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> On Feb 18, 2012, at 3:18 PM, Matthew Knepley wrote: >> >> > I have lost the BB battle, however can we at least start using >> > >> > hg pull --rebase >> > >> > so that we avoid this >> > >> > https://bitbucket.org/petsc/petsc-dev/changeset/ad9064ecab66 >> >> >> 1) I don't like the idea of a pull doing anything locally on my machine. >> I want it to only get the stuff from the remote repository and bring it to >> my machine. This reeks of svn >> > > I see it as a replacement for multiple repositories and carefully > orchestrated pulling, like Linus used to do, in order > to keep change sets clean. It is not giving up on the concept of change > sets like svn. > > >> 2) If the rebase implementation has been fixed from the hacky versions >> that fucked unnecessarily with my file system I'll be happy to start using >> rebase. Is it fixed? >> > > I cannot identify the behavior from that description. However, I have been > using it for almost a year now, and the > nice thing is that if anything goes wrong (merges with MacHg can screw up > badly), I just do > > hg rollback > hg revert --all > > You might be talking about the need to revert. > > Matt > > >> Barry >> >> > >> > Matt >> > >> > -- >> > 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 > > > > > -- > 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 >

1 0

Re: [petsc-dev] Merge sets
by Sean Farley 18 Feb '12

18 Feb '12

> > Ah, I don't see it because the Python build uses md5. Doesn't cmake? > I don't think 'make' is the annoyance here, at least, not to me. If I recall correctly, last time, Barry couldn't stand emac's insistence on asking 'should I reload this buffer' even when nothing changed on disk except for the timestamp. Following this thread: http://stackoverflow.com/questions/665600/how-can-i-get-emacs-to-revert-all… you can either set (global-auto-revert-mode) or try using the revbufs extension.

1 0

Re: [petsc-dev] Merge sets
by Matthew Knepley 18 Feb '12

18 Feb '12

On Sat, Feb 18, 2012 at 10:18 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Sat, 18 Feb 2012, Barry Smith wrote: > > > 2) If the rebase implementation has been fixed from the hacky > > versions that fucked unnecessarily with my file system I'll be happy > > to start using rebase. Is it fixed? > > The issue is: > > >> > When file 'a.c' is locally commited, and a pull potentially has > changes to 'b.c', 'pull --rebase' also changes the timestamp on a.c > [whereas 'pull; merge; commit' does not change timestamp on a.c] > << > > Latest hg [version 2.1] still updates the timestamp of a.c on rebase. > > Rebase is doing state changes [wrt commit states] - in this process I > think removes local changesets and recommits them - so the locally > changed files get new timestamps in this process. > > The fact that 'make' relies on timestamps messes things up [causing > unnecessary recompiles]. Reseting timestamps on unchanged files would > be a good optimziation - which is what Barry wants.. Ah, I don't see it because the Python build uses md5. Doesn't cmake? Matt > > Satish > > -- 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

1 0

Re: [petsc-dev] Merge sets
by Satish Balay 18 Feb '12

18 Feb '12

On Sat, 18 Feb 2012, Matthew Knepley wrote: > I cannot identify the behavior from that description. However, I > have been using it for almost a year now, and the nice thing is that > if anything goes wrong (merges with MacHg can screw up badly), I > just do > > hg rollback > hg revert --all Just like merge, rebase also pops up the merge tool [if needed] - like kdiff3 reducing the need for rollback/revert. However in a rebase, there are as many merge operations as local commits - so an equal number manual merges [with kdiff3] are potentially possible. Satish

1 0