From: Tim K. <tim...@ce...> - 2008-04-02 09:24:54
|
Dear libMesh team, where has the Elem::key(void) function gone? It used to exist in earlier times. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 tim...@me..., tim...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |
From: John P. <jwp...@gm...> - 2008-04-02 15:01:35
|
Hadn't you heard? That version is now obsolete ;-) ------------------------------------------------------------------------ r2374 | roystgnr | 2007-11-08 17:07:26 -0600 (Thu, 08 Nov 2007) | 4 lines Remove obsolete Elem::key() and Node::key(), use hashed Point locations as keys for MeshRefinement instead. In all honesty I'm not quite sure why that happened. I'll search back through my libmesh-users email to see if there was some discussion of the change... -J On Wed, Apr 2, 2008 at 4:24 AM, Tim Kroeger <tim...@ce...> wrote: > Dear libMesh team, > > where has the Elem::key(void) function gone? It used to exist in > earlier times. > > Best Regards, > > Tim > > -- > Dr. Tim Kroeger Phone +49-421-218-7710 > tim...@me..., tim...@ce... Fax +49-421-218-4236 > > MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany > > Amtsgericht Bremen HRB 16222 > Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
From: Tim K. <tim...@ce...> - 2008-04-03 11:58:19
|
Dear John, On Wed, 2 Apr 2008, John Peterson wrote: > Hadn't you heard? That version is now obsolete ;-) > > ------------------------------------------------------------------------ > r2374 | roystgnr | 2007-11-08 17:07:26 -0600 (Thu, 08 Nov 2007) | 4 lines > > Remove obsolete Elem::key() and Node::key(), use hashed Point > locations as keys for MeshRefinement instead. > > > In all honesty I'm not quite sure why that happened. I'll search back > through my libmesh-users email to see if there was some discussion of > the change... Did you find something? Actually, it would suffice for me if you let me know what alternative there is for getting an (almost) unique elem ID. My usage is *not* for MeshRefinement. A sponaneous idea would be to use Elem::key(0) instead (since each elem will have at least one side), but I'm afraid that this method might vanish, too. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 tim...@me..., tim...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |
From: Tim K. <tim...@ce...> - 2008-04-03 13:03:41
|
Dear John, On Thu, 3 Apr 2008, John Peterson wrote: > Roy could give you more details I think, but I'm fairly certain it had > to do with the parallelization of the mesh. Is elem->id() not > suitable for your purposes? Good question. Maybe, when I looked for a function that serves my purpose, I didn't find that for whatever reason -- or let's say I found Elem::key() first. If Elem::id() returns a unique value, it is certainly the right thing for me. Thank you very much. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 tim...@me..., tim...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |
From: Roy S. <ro...@st...> - 2008-04-03 14:08:34
|
On Thu, 3 Apr 2008, Tim Kroeger wrote: > Dear John, > > On Thu, 3 Apr 2008, John Peterson wrote: > >> Roy could give you more details I think, but I'm fairly certain it had >> to do with the parallelization of the mesh. Actually, Ben was the one to make those changes, but yes, it was part of the ParallelMesh I/O development. You'll have to ask him for the details. ;-) >> Is elem->id() not suitable for your purposes? > > Good question. Maybe, when I looked for a function that serves my > purpose, I didn't find that for whatever reason -- or let's say I > found Elem::key() first. If Elem::id() returns a unique value, it is > certainly the right thing for me. One potential problem is that elem->id() is unique, but not fixed. Mesh refinement, repartitioning, basically anything requiring an EquationSystems::reinit() will cause those ids to be renumbered. On the other hand, I think this was the case with Elem::key() as well. --- Roy |
From: Tim K. <tim...@ce...> - 2008-04-03 14:12:38
|
Dear Roy, On Thu, 3 Apr 2008, Roy Stogner wrote: >> Good question. Maybe, when I looked for a function that serves my >> purpose, I didn't find that for whatever reason -- or let's say I >> found Elem::key() first. If Elem::id() returns a unique value, it is >> certainly the right thing for me. > > One potential problem is that elem->id() is unique, but not fixed. > Mesh refinement, repartitioning, basically anything requiring an > EquationSystems::reinit() will cause those ids to be renumbered. On > the other hand, I think this was the case with Elem::key() as well. That doesn't matter for my purpose. I think it's exactly the thing I need. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 tim...@me..., tim...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |