From: Jens L. E. <jle...@gm...> - 2012-12-12 20:51:56
|
Hi all, I have an EquationSystems which holds two systems: EquationSystems es(mesh); es.read(filename), READ, EquationSystems::READ_HEADER | EquationSystems::READ_DATA | EquationSystems::READ_ADDITIONAL_DATA); System & sys = es.add_system<System>("sys"); sys.add_variable("u"); es.init(); The system that is read from file has three variables. Now, when I iterate of the nodes of mesh, and do index_0 = node->dof_number(0, i, 0); index_1 = node->dof_number(0,0,0); I alwas get index_0==index_1 also when i = 1,2. Any idea what I might be missing here? Bot n_vars() and n_dofs() on the two systems returns what they're supposed to ... Best, Jens |
From: Roy S. <roy...@ic...> - 2012-12-12 21:07:47
|
On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: > The system that is read from file has three variables. Now, when I > iterate of the nodes of mesh, and do > > index_0 = node->dof_number(0, i, 0); > index_1 = node->dof_number(0,0,0); > > I alwas get index_0==index_1 also when i = 1,2. I assume you're running with the latest svn trunk or git master? If so, would you try with svn revision 6517? It's possible that Ben's subsequent VariableGroup optimizations to the dof numbering regressed something. Thanks, --- Roy |
From: John P. <jwp...@gm...> - 2012-12-12 21:16:44
|
On Wed, Dec 12, 2012 at 2:07 PM, Roy Stogner <roy...@ic...> wrote: > > On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: > >> The system that is read from file has three variables. Now, when I >> iterate of the nodes of mesh, and do >> >> index_0 = node->dof_number(0, i, 0); >> index_1 = node->dof_number(0,0,0); >> >> I alwas get index_0==index_1 also when i = 1,2. > > I assume you're running with the latest svn trunk or git master? > > If so, would you try with svn revision 6517? It's possible that Ben's I think that's fe6281b4e in git. The one immediately preceding is 134a6bef0d So if you're using git, you can git co 134a6bef0d to go back to the version immediately prior to Ben's commit. If I was a betting man, I'd bet there's nothing wrong with his patch ;-) -- John |
From: Jens L. E. <jle...@gm...> - 2012-12-12 21:23:57
|
On 12/12/2012 04:07 PM, Roy Stogner wrote: > On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: > >> The system that is read from file has three variables. Now, when I >> iterate of the nodes of mesh, and do >> >> index_0 = node->dof_number(0, i, 0); >> index_1 = node->dof_number(0,0,0); >> >> I alwas get index_0==index_1 also when i = 1,2. > > I assume you're running with the latest svn trunk or git master? > > If so, would you try with svn revision 6517? It's possible that Ben's > subsequent VariableGroup optimizations to the dof numbering regressed > something. Yep, I was using svn revision 6524. Rolling back to 6517 did not change anything. Also note that there's a typo in my code above the first argument to the last call to dof_number should be 1 and not 0. Thanks, Jens |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 21:11:17
|
On Dec 12, 2012, at 3:07 PM, Roy Stogner <roy...@ic...> wrote: > On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: > >> The system that is read from file has three variables. Now, when I >> iterate of the nodes of mesh, and do >> >> index_0 = node->dof_number(0, i, 0); >> index_1 = node->dof_number(0,0,0); >> >> I alwas get index_0==index_1 also when i = 1,2. > > I assume you're running with the latest svn trunk or git master? > > If so, would you try with svn revision 6517? It's possible that Ben's > subsequent VariableGroup optimizations to the dof numbering regressed > something. Definite possibility. And I assume this is something that worked previously? If you are running master, could you add node->debug_buffer(); after the erroneous call you've identified and post the results? Thanks, -Ben |
From: Andrs, D. <dav...@in...> - 2012-12-12 21:19:26
|
On Wed, Dec 12, 2012 at 1:52 PM, Jens Lohne Eftang <jle...@gm...>wrote: > Hi all, > > I have an EquationSystems which holds two systems: > > EquationSystems es(mesh); > es.read(filename), > READ, > EquationSystems::READ_HEADER | > EquationSystems::READ_DATA | > EquationSystems::READ_ADDITIONAL_DATA); > > System & sys = es.add_system<System>("sys"); > sys.add_variable("u"); > es.init(); > > The system that is read from file has three variables. Now, when I > iterate of the nodes of mesh, and do > > index_0 = node->dof_number(0, i, 0); > index_1 = node->dof_number(0,0,0); > Maybe it is a typo here, but the first argument to dof_number is system index: so they should be something like 0 and 1? The second one is variable number, so it should be 0 (as long as you have just one variable in each system)? -- David > I alwas get index_0==index_1 also when i = 1,2. > > Any idea what I might be missing here? Bot n_vars() and n_dofs() on the > two systems returns what they're supposed to ... > > Best, > Jens > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
From: Jens L. E. <jle...@gm...> - 2012-12-12 21:24:53
|
On 12/12/2012 04:19 PM, Andrs, David wrote: > On Wed, Dec 12, 2012 at 1:52 PM, Jens Lohne Eftang <jle...@gm...>wrote: > >> Hi all, >> >> I have an EquationSystems which holds two systems: >> >> EquationSystems es(mesh); >> es.read(filename), >> READ, >> EquationSystems::READ_HEADER | >> EquationSystems::READ_DATA | >> EquationSystems::READ_ADDITIONAL_DATA); >> >> System & sys = es.add_system<System>("sys"); >> sys.add_variable("u"); >> es.init(); >> >> The system that is read from file has three variables. Now, when I >> iterate of the nodes of mesh, and do >> >> index_0 = node->dof_number(0, i, 0); >> index_1 = node->dof_number(0,0,0); >> > Maybe it is a typo here, but the first argument to dof_number is system > index: so they should be something like 0 and 1? The second one is variable > number, so it should be 0 (as long as you have just one variable in each > system)? Yep, that's just a typo in my email. Thanks though. Best, Jens > > -- > David > > >> I alwas get index_0==index_1 also when i = 1,2. >> >> Any idea what I might be missing here? Bot n_vars() and n_dofs() on the >> two systems returns what they're supposed to ... >> >> Best, >> Jens >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Jens L. E. <jle...@gm...> - 2012-12-12 21:25:54
|
On 12/12/2012 04:11 PM, Kirk, Benjamin (JSC-EG311) wrote: > On Dec 12, 2012, at 3:07 PM, Roy Stogner <roy...@ic...> wrote: > >> On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: >> >>> The system that is read from file has three variables. Now, when I >>> iterate of the nodes of mesh, and do >>> >>> index_0 = node->dof_number(0, i, 0); >>> index_1 = node->dof_number(0,0,0); >>> >>> I alwas get index_0==index_1 also when i = 1,2. >> I assume you're running with the latest svn trunk or git master? >> >> If so, would you try with svn revision 6517? It's possible that Ben's >> subsequent VariableGroup optimizations to the dof numbering regressed >> something. > Definite possibility. And I assume this is something that worked previously? > > If you are running master, could you add > > node->debug_buffer(); > > after the erroneous call you've identified and post the results? I was using 6524, rolled back to 6517 but it didn't change anything. node->debug_buffer() caused a compilation error ... Best, Jens > Thanks, > > -Ben > > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 21:31:49
|
Sorry, the debug_buffer() is a new feature - from when I thought it was my patch. ;-) Have you run this on debug mode? Reading the system from disk initialized the equation systems, and then you add another system? Conceptually this should work, but... That's what the asserts are there for! -Ben On Dec 12, 2012, at 3:25 PM, "Jens Lohne Eftang" <jle...@gm...> wrote: > On 12/12/2012 04:11 PM, Kirk, Benjamin (JSC-EG311) wrote: >> On Dec 12, 2012, at 3:07 PM, Roy Stogner <roy...@ic...> wrote: >> >>> On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: >>> >>>> The system that is read from file has three variables. Now, when I >>>> iterate of the nodes of mesh, and do >>>> >>>> index_0 = node->dof_number(0, i, 0); >>>> index_1 = node->dof_number(0,0,0); >>>> >>>> I alwas get index_0==index_1 also when i = 1,2. >>> I assume you're running with the latest svn trunk or git master? >>> >>> If so, would you try with svn revision 6517? It's possible that Ben's >>> subsequent VariableGroup optimizations to the dof numbering regressed >>> something. >> Definite possibility. And I assume this is something that worked previously? >> >> If you are running master, could you add >> >> node->debug_buffer(); >> >> after the erroneous call you've identified and post the results? > I was using 6524, rolled back to 6517 but it didn't change anything. > node->debug_buffer() caused a compilation error ... > > Best, > Jens > >> Thanks, >> >> -Ben > |
From: Andrs, D. <dav...@in...> - 2012-12-12 21:37:26
|
On Wed, Dec 12, 2012 at 2:25 PM, Jens Lohne Eftang <jle...@gm...>wrote: > On 12/12/2012 04:19 PM, Andrs, David wrote: > > On Wed, Dec 12, 2012 at 1:52 PM, Jens Lohne Eftang <jle...@gm... > >wrote: > > > >> Hi all, > >> > >> I have an EquationSystems which holds two systems: > >> > >> EquationSystems es(mesh); > >> es.read(filename), > >> READ, > >> EquationSystems::READ_HEADER | > >> EquationSystems::READ_DATA | > >> EquationSystems::READ_ADDITIONAL_DATA); > >> > >> System & sys = es.add_system<System>("sys"); > >> sys.add_variable("u"); > >> es.init(); > >> > >> The system that is read from file has three variables. Now, when I > >> iterate of the nodes of mesh, and do > >> > >> index_0 = node->dof_number(0, i, 0); > >> index_1 = node->dof_number(0,0,0); > >> > > Maybe it is a typo here, but the first argument to dof_number is system > > index: so they should be something like 0 and 1? The second one is > variable > > number, so it should be 0 (as long as you have just one variable in each > > system)? > > Yep, that's just a typo in my email. Thanks though. > So, with 1 equation_system class with 2 systems where each system has 1 variable, there are going to be two solution vectors. Now, if DOFs are associated in a deterministic manner (and I believe they are), it is very likely that the same node is gonna have the same global index in both systems, because that number is a global within the solution vector. However, I am not an libMesh expert, so I might be wrong... -- David > Best, > Jens > > > > -- > > David > > > > > >> I alwas get index_0==index_1 also when i = 1,2. > >> > >> Any idea what I might be missing here? Bot n_vars() and n_dofs() on the > >> two systems returns what they're supposed to ... > >> > >> Best, > >> Jens > >> > >> > >> > ------------------------------------------------------------------------------ > >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >> Remotely access PCs and mobile devices and provide instant support > >> Improve your efficiency, and focus on delivering more value-add services > >> Discover what IT Professionals Know. Rescue delivers > >> http://p.sf.net/sfu/logmein_12329d2d > >> _______________________________________________ > >> Libmesh-users mailing list > >> Lib...@li... > >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > >> > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________ > > Libmesh-users mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > -- David Andrs |
From: Jens L. E. <jle...@gm...> - 2012-12-12 21:39:25
|
On 12/12/2012 04:37 PM, Andrs, David wrote: > On Wed, Dec 12, 2012 at 2:25 PM, Jens Lohne Eftang <jle...@gm... > <mailto:jle...@gm...>> wrote: > > On 12/12/2012 04:19 PM, Andrs, David wrote: > > On Wed, Dec 12, 2012 at 1:52 PM, Jens Lohne Eftang > <jle...@gm... <mailto:jle...@gm...>>wrote: > > > >> Hi all, > >> > >> I have an EquationSystems which holds two systems: > >> > >> EquationSystems es(mesh); > >> es.read(filename), > >> READ, > >> EquationSystems::READ_HEADER | > >> EquationSystems::READ_DATA | > >> EquationSystems::READ_ADDITIONAL_DATA); > >> > >> System & sys = es.add_system<System>("sys"); > >> sys.add_variable("u"); > >> es.init(); > >> > >> The system that is read from file has three variables. Now, when I > >> iterate of the nodes of mesh, and do > >> > >> index_0 = node->dof_number(0, i, 0); > >> index_1 = node->dof_number(0,0,0); > >> > > Maybe it is a typo here, but the first argument to dof_number is > system > > index: so they should be something like 0 and 1? The second one > is variable > > number, so it should be 0 (as long as you have just one variable > in each > > system)? > > Yep, that's just a typo in my email. Thanks though. > > > So, with 1 equation_system class with 2 systems where each system has > 1 variable, there are going to be two solution vectors. Now, if DOFs > are associated in a deterministic manner (and I believe they are), it > is very likely that the same node is gonna have the same global index > in both systems, because that number is a global within the solution > vector. > Not for the same variable number. System 0 has three variables (so i = 0,1,2 in my code), and System 1 has one variable. Nevertheless the global returned indices are the same whatever i is ... Jens > However, I am not an libMesh expert, so I might be wrong... > -- > David > > Best, > Jens > > > > -- > > David > > > > > >> I alwas get index_0==index_1 also when i = 1,2. > >> > >> Any idea what I might be missing here? Bot n_vars() and > n_dofs() on the > >> two systems returns what they're supposed to ... > >> > >> Best, > >> Jens > >> > >> > >> > ------------------------------------------------------------------------------ > >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >> Remotely access PCs and mobile devices and provide instant support > >> Improve your efficiency, and focus on delivering more value-add > services > >> Discover what IT Professionals Know. Rescue delivers > >> http://p.sf.net/sfu/logmein_12329d2d > >> _______________________________________________ > >> Libmesh-users mailing list > >> Lib...@li... > <mailto:Lib...@li...> > >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > >> > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add > services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________ > > Libmesh-users mailing list > > Lib...@li... > <mailto:Lib...@li...> > > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add > services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > <mailto:Lib...@li...> > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > > > -- > David Andrs |
From: Jens L. E. <jle...@gm...> - 2012-12-12 21:52:56
|
On 12/12/2012 04:31 PM, Kirk, Benjamin (JSC-EG311) wrote: > Sorry, the debug_buffer() is a new feature - from when I thought it was my patch. ;-) > > Have you run this on debug mode? Hmm, I must have messed something up when I rolled back to 6524 earlier. Now I did get debug_buffer() to work and the output for the first three nodes is [ 2 8 257 0 257 96 257 192 257 0 ] [ 2 8 257 1 257 97 257 193 257 1 ] [ 2 8 257 2 257 98 257 194 257 2 ] (System 0 has 288 dofs and System 1 has 96 dofs) I have quite a bit of data to read in, so I did not take the time to run in debug mode yet. However devel mode doesn't trigger any asserts. Jens > > Reading the system from disk initialized the equation systems, and then you add another system? > > Conceptually this should work, but... That's what the asserts are there for! > > -Ben > > On Dec 12, 2012, at 3:25 PM, "Jens Lohne Eftang" <jle...@gm...> wrote: > >> On 12/12/2012 04:11 PM, Kirk, Benjamin (JSC-EG311) wrote: >>> On Dec 12, 2012, at 3:07 PM, Roy Stogner <roy...@ic...> wrote: >>> >>>> On Wed, 12 Dec 2012, Jens Lohne Eftang wrote: >>>> >>>>> The system that is read from file has three variables. Now, when I >>>>> iterate of the nodes of mesh, and do >>>>> >>>>> index_0 = node->dof_number(0, i, 0); >>>>> index_1 = node->dof_number(0,0,0); >>>>> >>>>> I alwas get index_0==index_1 also when i = 1,2. >>>> I assume you're running with the latest svn trunk or git master? >>>> >>>> If so, would you try with svn revision 6517? It's possible that Ben's >>>> subsequent VariableGroup optimizations to the dof numbering regressed >>>> something. >>> Definite possibility. And I assume this is something that worked previously? >>> >>> If you are running master, could you add >>> >>> node->debug_buffer(); >>> >>> after the erroneous call you've identified and post the results? >> I was using 6524, rolled back to 6517 but it didn't change anything. >> node->debug_buffer() caused a compilation error ... >> >> Best, >> Jens >> >>> Thanks, >>> >>> -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 22:09:27
|
On Dec 12, 2012, at 3:52 PM, "Jens Lohne Eftang" <jle...@gm...> wrote: > On 12/12/2012 04:31 PM, Kirk, Benjamin (JSC-EG311) wrote: >> Sorry, the debug_buffer() is a new feature - from when I thought it was my patch. ;-) >> >> Have you run this on debug mode? > Hmm, I must have messed something up when I rolled back to 6524 earlier. > Now I did get debug_buffer() to work and the output for the first three > nodes Can you confirm, is it broken when you successfully roll back? That buffer should report three different values - ill check later tonight. Also, we need to be sure my latest changes that exist in git are also on svn, if that is where you are pulling from. -Ben |
From: Jens L. E. <jle...@gm...> - 2012-12-12 22:10:58
|
On 12/12/2012 05:09 PM, Kirk, Benjamin (JSC-EG311) wrote: > On Dec 12, 2012, at 3:52 PM, "Jens Lohne Eftang" <jle...@gm...> wrote: > >> On 12/12/2012 04:31 PM, Kirk, Benjamin (JSC-EG311) wrote: >>> Sorry, the debug_buffer() is a new feature - from when I thought it was my patch. ;-) >>> >>> Have you run this on debug mode? >> Hmm, I must have messed something up when I rolled back to 6524 earlier. >> Now I did get debug_buffer() to work and the output for the first three >> nodes > Can you confirm, is it broken when you successfully roll back? > > That buffer should report three different values - ill check later tonight. > > Also, we need to be sure my latest changes that exist in git are also on svn, if that is where you are pulling from. > > -Ben With revision 6524 it's still broken. Yep, I'm pulling from svn. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 23:17:50
|
On Dec 12, 2012, at 4:11 PM, Jens Lohne Eftang <jle...@gm...> wrote: > With revision 6524 it's still broken. Yep, I'm pulling from svn. With r6524, will you please uncomment the section // std::cout << "base_idx, var, vg, vig, ncg, comp=" // << base_idx << " " // << var << " " // << vg << " " // << vig << " " // << ncg << " " // << comp << '\n'; inside include/base/dof_object.h, function DofObject::dof_number() and repeat your experiment, replying with the results again for the first three nodes, also with the node->debug_buffer() as before? I'd expect system 0, vars 0,1,2 to have ids 0, 96, and 192, respectively, from this buffer: [ 2 8 257 0 257 96 257 192 257 0 ] -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 23:31:41
|
One more thing - you may want to put node->debug_buffer(); libmesh_error(); So you can force an abort to track down the output - uncommenting those lines will create a lot of noise on the console! -Ben On Dec 12, 2012, at 5:17 PM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > On Dec 12, 2012, at 4:11 PM, Jens Lohne Eftang <jle...@gm...> wrote: > >> With revision 6524 it's still broken. Yep, I'm pulling from svn. > > With r6524, will you please uncomment the section > > // std::cout << "base_idx, var, vg, vig, ncg, comp=" > // << base_idx << " " > // << var << " " > // << vg << " " > // << vig << " " > // << ncg << " " > // << comp << '\n'; > > > inside include/base/dof_object.h, function > DofObject::dof_number() > > and repeat your experiment, replying with the results again for the first three nodes, also with the > node->debug_buffer() as before? > > I'd expect system 0, vars 0,1,2 to have ids 0, 96, and 192, respectively, from this buffer: > > [ 2 8 257 0 257 96 257 192 257 0 ] > > -Ben > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Jens L. E. <jle...@gm...> - 2012-12-13 00:35:08
|
On 12/12/2012 06:17 PM, Kirk, Benjamin (JSC-EG311) wrote: > On Dec 12, 2012, at 4:11 PM, Jens Lohne Eftang <jle...@gm...> wrote: > >> With revision 6524 it's still broken. Yep, I'm pulling from svn. > With r6524, will you please uncomment the section > > // std::cout << "base_idx, var, vg, vig, ncg, comp=" > // << base_idx << " " > // << var << " " > // << vg << " " > // << vig << " " > // << ncg << " " > // << comp << '\n'; > > > inside include/base/dof_object.h, function > DofObject::dof_number() > > and repeat your experiment, replying with the results again for the first three nodes, also with the > node->debug_buffer() as before? > > I'd expect system 0, vars 0,1,2 to have ids 0, 96, and 192, respectively, from this buffer: > > [ 2 8 257 0 257 96 257 192 257 0 ] Thanks. Here's the output from the first node in the iteration: base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 [ 2 8 257 0 257 96 257 192 257 0 ] ... I suspect an indication that's something's not quite right... Jens > > -Ben > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-13 03:04:38
|
On Dec 12, 2012, at 6:35 PM, Jens Lohne Eftang <jle...@gm...> wrote: >> >> and repeat your experiment, replying with the results again for the first three nodes, also with the >> node->debug_buffer() as before? >> >> I'd expect system 0, vars 0,1,2 to have ids 0, 96, and 192, respectively, from this buffer: >> >> [ 2 8 257 0 257 96 257 192 257 0 ] > Thanks. Here's the output from the first node in the iteration: > > base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 > base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 > [ 2 8 257 0 257 96 257 192 257 0 ] > > ... I suspect an indication that's something's not quite right... I'm going to create a unit test to set this exact buffer and make things are as they should be. It'll be tomorrow before I'm able to finish it up though. I am running problems with multiple systems and multiple variables per system with no issue... I'm still confused if this bug is a result of my recent patch or not? If you $ svn up -r 6520 . in your top-level directory and try that build - what happens? -Ben |
From: Jens L. E. <jle...@gm...> - 2012-12-13 03:15:26
|
On 12/12/2012 10:04 PM, Kirk, Benjamin (JSC-EG311) wrote: > On Dec 12, 2012, at 6:35 PM, Jens Lohne Eftang <jle...@gm...> wrote: > >>> and repeat your experiment, replying with the results again for the first three nodes, also with the >>> node->debug_buffer() as before? >>> >>> I'd expect system 0, vars 0,1,2 to have ids 0, 96, and 192, respectively, from this buffer: >>> >>> [ 2 8 257 0 257 96 257 192 257 0 ] >> Thanks. Here's the output from the first node in the iteration: >> >> base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 >> base_idx, var, vg, vig, ncg, comp=0 0 0 0 1 0 >> [ 2 8 257 0 257 96 257 192 257 0 ] >> >> ... I suspect an indication that's something's not quite right... > I'm going to create a unit test to set this exact buffer and make things are as they should be. It'll be tomorrow before I'm able to finish it up though. I am running problems with multiple systems and multiple variables per system with no issue... > > I'm still confused if this bug is a result of my recent patch or not? > > If you > > $ svn up -r 6520 . > > in your top-level directory and try that build - what happens? I get the same behavior as with 6525. Thanks, Jens > > -Ben > > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-13 17:12:07
|
On Dec 12, 2012, at 9:15 PM, Jens Lohne Eftang <jle...@gm...> wrote: >> >> in your top-level directory and try that build - what happens? > I get the same behavior as with 6525. > > Thanks, > Jens Jens, I created a unit test in the latest libMesh source tree, and for the buffers you provide the code is behaving as expected. https://github.com/libMesh/libmesh/pull/9 So the issue is not the new VariableGroups patch, which is consistent with you saying the issue persists even with the older versions. (1) Could you review the link above and make sure that the calling arguments are consistent with what you are doing, (2) add a call to EquationSystems::print_info() after you add your second system and initialize it. Reply with the output (3) run in DEBUG mode DEBUG mode does more than just enable the asserts - in this case it adds additional sanity checking code into the DofObject class. -Ben |
From: Jens L. E. <jle...@gm...> - 2012-12-13 19:23:17
|
On 12/13/2012 12:11 PM, Kirk, Benjamin (JSC-EG311) wrote: > I created a unit test in the latest libMesh source tree, and for the buffers you provide the code is behaving as expected. > https://github.com/libMesh/libmesh/pull/9 > > So the issue is not the new VariableGroups patch, which is consistent with you saying the issue persists even with the older versions. > > (1) Could you review the link above and make sure that the calling arguments are consistent with what you are doing, > (2) add a call to EquationSystems::print_info() after you add your second system and initialize it. Reply with the output > (3) run in DEBUG mode > > DEBUG mode does more than just enable the asserts - in this case it adds additional sanity checking code into the DofObject class. 1) I'm completely unfamiliar with git so I am not sure I understood this one ... I had a look in the function testJensEftangBug(); all I was able to conclude was that your asserts makes sense to me, but I probably misunderstand something. 2) The output of EquationSystems::print_info() after initialization (after adding the second system) is listed below. It looks sound to me. 3) DEBUG mode does not reveal anything new; it still just exits on the libmesh_error(). (2) and (3) was with the git head EquationSystems n_systems()=2 System #0, "io_system" Type "Basic" Variables="u_0" "u_1" "u_2" Finite Element Types="LAGRANGE", "JACOBI_20_00" "LAGRANGE", "JACOBI_20_00" "LAGRANGE", "JACOBI_20_00" Infinite Element Mapping="CARTESIAN" "CARTESIAN" "CARTESIAN" Approximation Orders="SECOND", "THIRD" "SECOND", "THIRD" "SECOND", "THIRD" n_dofs()=288 n_local_dofs()=288 n_constrained_dofs()=0 n_local_constrained_dofs()=0 n_vectors()=288 n_matrices()=0 DofMap Sparsity Average On-Processor Bandwidth <= 0 Average Off-Processor Bandwidth <= 0 Maximum On-Processor Bandwidth <= 0 Maximum Off-Processor Bandwidth <= 0 DofMap Constraints Number of DoF Constraints = 0 Number of Node Constraints = 0 System #1, "pod_sys" Type "Implicit" Variables="u_pod" Finite Element Types="LAGRANGE", "JACOBI_20_00" Infinite Element Mapping="CARTESIAN" Approximation Orders="SECOND", "THIRD" n_dofs()=96 n_local_dofs()=96 n_constrained_dofs()=0 n_local_constrained_dofs()=0 n_vectors()=1 n_matrices()=1 DofMap Sparsity Average On-Processor Bandwidth <= 13.0833 Average Off-Processor Bandwidth <= 0 Maximum On-Processor Bandwidth <= 21 Maximum Off-Processor Bandwidth <= 0 DofMap Constraints Number of DoF Constraints = 0 Number of Node Constraints = 0 Thanks, Jens > -Ben > |
From: Roy S. <roy...@ic...> - 2012-12-13 19:41:06
|
On Thu, 13 Dec 2012, Jens Lohne Eftang wrote: > 2) The output of EquationSystems::print_info() after initialization > (after adding the second system) is listed below. It looks sound to me. Wait one second: > EquationSystems > n_systems()=2 > System #0, "io_system" ... > n_vectors()=288 Is this correct? --- Roy |
From: Jens L. E. <jle...@gm...> - 2012-12-13 19:43:20
|
On 12/13/2012 02:40 PM, Roy Stogner wrote: > > On Thu, 13 Dec 2012, Jens Lohne Eftang wrote: > >> 2) The output of EquationSystems::print_info() after initialization >> (after adding the second system) is listed below. It looks sound to me. > > Wait one second: > >> EquationSystems >> n_systems()=2 >> System #0, "io_system" > ... >> n_vectors()=288 > > Is this correct? Yes, it's supposed to have 288 vectors associated with it (I use the "io_system" to hold a bunch of vectors, in fact one vector for each dof). > --- > Roy |
From: John P. <jwp...@gm...> - 2012-12-13 19:43:39
|
On Thu, Dec 13, 2012 at 12:40 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 13 Dec 2012, Jens Lohne Eftang wrote: > >> 2) The output of EquationSystems::print_info() after initialization >> (after adding the second system) is listed below. It looks sound to me. > > Wait one second: > >> EquationSystems >> n_systems()=2 >> System #0, "io_system" > ... >> n_vectors()=288 > > Is this correct? Might be for reduced basis apps... -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-13 21:13:30
|
On Dec 13, 2012, at 1:43 PM, John Peterson <jwp...@gm...> wrote: > On Thu, Dec 13, 2012 at 12:40 PM, Roy Stogner <roy...@ic...> wrote: >> >> On Thu, 13 Dec 2012, Jens Lohne Eftang wrote: >> >>> 2) The output of EquationSystems::print_info() after initialization >>> (after adding the second system) is listed below. It looks sound to me. >> >> Wait one second: >> >>> EquationSystems >>> n_systems()=2 >>> System #0, "io_system" >> ... >>> n_vectors()=288 >> >> Is this correct? > > Might be for reduced basis apps... Suffice to say I don't think this is a problem with the VariableGroups code changes, and I don't see anything my related applications. What would it take to get your mesh, restart file, and code so I can try to recreate this exactly? As it stands now I don't see any bug to fix! -Ben |