From: Roy S. <roy...@ic...> - 2010-08-27 16:30:31
|
On Fri, 27 Aug 2010, Johannes A Huber wrote: > I was wondering, is it might be possible petsc_matric.C on line 72 (and perhaps in other lines as well, like 139, 142, ...) > The matrix that is created in these lines is always quadratic (n_global*n_global). I guess, the second argument to MatCreateSeqAIJ should be > m_global instead of n_global. Let me run this by libmesh-devel (Ben Kirk is the one who wrote that code, and he surely understands it better than I do), but it looks to me like you're right. And since libMesh (and, I'd be willing to bet, all its primary developers) only creates square sparse matrices, we'd never have noticed a bug that breaks rectangular sparse matrix creation. > Furthermore I have a perhaps quite dumb question: Why can I only print from process 0 after initializing libmesh: > > i.e. Proc 1 does not print after I initialized libMesh, but only before. Basically there are a lot of conditions which get encountered at every processor but for which we only want one message, not n_processors() messages. Our default behavior is for libMesh::out and libMesh::err to proxy cout and cerr, then disable the former on all other processors. Try --keep-cout if you don't want to disable anything. Or try --separate-libmeshout if you want the libMesh::out disabled on other processors but cout retained. There's also --redirect-stdout to send the libMesh output to files instead of stdout. --- Roy |
From: John P. <pet...@cf...> - 2010-08-27 16:36:40
|
On Fri, Aug 27, 2010 at 11:30 AM, Roy Stogner <roy...@ic...> wrote: > > On Fri, 27 Aug 2010, Johannes A Huber wrote: > >> I was wondering, is it might be possible petsc_matric.C on line 72 (and perhaps in other lines as well, like 139, 142, ...) >> The matrix that is created in these lines is always quadratic (n_global*n_global). I guess, the second argument to MatCreateSeqAIJ should be >> m_global instead of n_global. > > Let me run this by libmesh-devel (Ben Kirk is the one who wrote that > code, and he surely understands it better than I do), but it looks to > me like you're right. And since libMesh (and, I'd be willing to bet, > all its primary developers) only creates square sparse matrices, we'd > never have noticed a bug that breaks rectangular sparse matrix > creation. I think you're right, especially considering the call to MatCreateMPIAIJ a few lines below which does use m_global. Nice catch! -- John |
From: John P. <pet...@cf...> - 2010-08-27 16:45:54
|
On Fri, Aug 27, 2010 at 11:36 AM, John Peterson <pet...@cf...> wrote: > On Fri, Aug 27, 2010 at 11:30 AM, Roy Stogner <roy...@ic...> wrote: >> >> On Fri, 27 Aug 2010, Johannes A Huber wrote: >> >>> I was wondering, is it might be possible petsc_matric.C on line 72 (and perhaps in other lines as well, like 139, 142, ...) >>> The matrix that is created in these lines is always quadratic (n_global*n_global). I guess, the second argument to MatCreateSeqAIJ should be >>> m_global instead of n_global. >> >> Let me run this by libmesh-devel (Ben Kirk is the one who wrote that >> code, and he surely understands it better than I do), but it looks to >> me like you're right. And since libMesh (and, I'd be willing to bet, >> all its primary developers) only creates square sparse matrices, we'd >> never have noticed a bug that breaks rectangular sparse matrix >> creation. > > I think you're right, especially considering the call to > MatCreateMPIAIJ a few lines below which does use m_global. > > Nice catch! And fix checked in. -- John |
From: Roy S. <roy...@ic...> - 2010-08-27 16:55:18
|
On Fri, 27 Aug 2010, John Peterson wrote: > On Fri, Aug 27, 2010 at 11:36 AM, John Peterson > <pet...@cf...> wrote: >> On Fri, Aug 27, 2010 at 11:30 AM, Roy Stogner <roy...@ic...> wrote: >>> >>> On Fri, 27 Aug 2010, Johannes A Huber wrote: >>> >>>> I was wondering, is it might be possible petsc_matric.C on line 72 (and perhaps in other lines as well, like 139, 142, ...) >>>> The matrix that is created in these lines is always quadratic (n_global*n_global). I guess, the second argument to MatCreateSeqAIJ should be >>>> m_global instead of n_global. >>> >>> Let me run this by libmesh-devel (Ben Kirk is the one who wrote that >>> code, and he surely understands it better than I do), but it looks to >>> me like you're right. And since libMesh (and, I'd be willing to bet, >>> all its primary developers) only creates square sparse matrices, we'd >>> never have noticed a bug that breaks rectangular sparse matrix >>> creation. >> >> I think you're right, especially considering the call to >> MatCreateMPIAIJ a few lines below which does use m_global. >> >> Nice catch! > > And fix checked in. The line 139 and 142 case isn't exactly a "bug", since in that constructor we really do always want a square matrix, but I changed them anyway to avoid confusing anyone in years to come. Speaking of years: this looks like the oldest bug I've ever seen in libMesh - it was in place in 2003 when the code first went into version control! --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-08-27 16:59:33
|
On 8/27/10 11:55 AM, "Roy Stogner" <roy...@ic...> wrote: > Speaking of years: this looks like the oldest bug I've ever seen in > libMesh - it was in place in 2003 when the code first went into > version control! nice catch indeed!! -Ben |