From: Roy S. <roy...@ic...> - 2007-10-05 21:02:46
|
Since we'd eventually like to be able to use any subclass of MeshBase in our Systems, shouldn't we store "MeshBase& _mesh;" instead of "Mesh& _mesh;" in our System and EquationSystems classes? Unfortunately, this will break any user code that currently uses get_mesh() to get a Mesh reference instead of a MeshBase reference. The fix will usually be as simple as changing "Mesh" to "MeshBase", occasionally a user may need to cast up a reference that he knows is a particular subclass, but however we do it it'll be an incompatible API change. Any thoughts? --- Roy |
From: Benjamin K. <ben...@na...> - 2007-10-05 22:55:38
|
I don't mind breaking the external API for the common good... How much will this break the EquationSystem/System hierarchy, I wonder? I'm sure there are some unfortunate areas that expect to have a Mesh. (Not that there should be, I just don't know how much rework this will be.) On 10/5/07 4:02 PM, "Roy Stogner" <roy...@ic...> wrote: > > Since we'd eventually like to be able to use any subclass of MeshBase > in our Systems, shouldn't we store "MeshBase& _mesh;" instead of > "Mesh& _mesh;" in our System and EquationSystems classes? > Unfortunately, this will break any user code that currently uses > get_mesh() to get a Mesh reference instead of a MeshBase reference. > The fix will usually be as simple as changing "Mesh" to "MeshBase", > occasionally a user may need to cast up a reference that he knows is a > particular subclass, but however we do it it'll be an incompatible API > change. > > Any thoughts? > --- > Roy > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2007-10-06 01:15:34
|
On Fri, 5 Oct 2007, Benjamin Kirk wrote: > I don't mind breaking the external API for the common good... Okay, then. Should we put out a libMesh 6.1 (with the new PETSc compatibility, if we can work out whatever this latest petsc snoop failure was) before I commit the change? That way we'd give everyone compatibility which is as up to date as possible before breaking things. > How much will this break the EquationSystem/System hierarchy, I > wonder? I'm sure there are some unfortunate areas that expect to > have a Mesh. (Not that there should be, I just don't know how much > rework this will be.) There are definitely places which may break (or leak memory, or do nothing) on weird MeshBase subclasses, depending on how we implement them, but I'm about to commit the last change to code that wouldn't compile against a MeshBase& get_mesh(). The MeshRefinement stuff all expects an UnstructuredMesh, of course, but it uses what it was handed from its constructor, not anything from a System. --- Roy |
From: John P. <pet...@cf...> - 2007-10-06 04:22:47
|
This isn't any less of an API change, but what if the Mesh reference is just a public member of the class, instead of something we provide an accessor for? It seems that code written like es.mesh.elements_begin() .... would then not care if es.mesh is a Mesh& or a MeshBase&. -John Roy Stogner writes: > On Fri, 5 Oct 2007, Benjamin Kirk wrote: > > > I don't mind breaking the external API for the common good... > > Okay, then. > > Should we put out a libMesh 6.1 (with the new PETSc compatibility, if > we can work out whatever this latest petsc snoop failure was) before I > commit the change? That way we'd give everyone compatibility which > is as up to date as possible before breaking things. > > > How much will this break the EquationSystem/System hierarchy, I > > wonder? I'm sure there are some unfortunate areas that expect to > > have a Mesh. (Not that there should be, I just don't know how much > > rework this will be.) > > There are definitely places which may break (or leak memory, or do > nothing) on weird MeshBase subclasses, depending on how we implement > them, but I'm about to commit the last change to code that wouldn't > compile against a MeshBase& get_mesh(). The MeshRefinement stuff all > expects an UnstructuredMesh, of course, but it uses what it was handed > from its constructor, not anything from a System. > --- > Roy |
From: Benjamin K. <ben...@na...> - 2007-10-09 13:06:16
|
On 10/5/07 11:22 PM, "John Peterson" <pet...@cf...> wrote: > This isn't any less of an API change, but what if the Mesh reference > is just a public member of the class, instead of something we provide > an accessor for? It seems that code written like > > es.mesh.elements_begin() .... > > would then not care if es.mesh is a Mesh& or a MeshBase&. > > -John Perhaps it is time for my bi-monthly template pimping? template <class MeshType = MeshBase> class EquationSystems { public: MeshType mesh; }; seems to solve the problem nicely (if indeed there is a problem). Library code may never need anything more than a MeshBase in there, but a savy user could declare an EquationSystems object based on whatever kind of mesh they choose. It just seems a little safer than requiring the user to perform dynamic casts. -Ben |
From: Roy S. <roy...@ic...> - 2007-10-09 18:36:53
|
On Tue, 9 Oct 2007, Benjamin Kirk wrote: > template <class MeshType = MeshBase> > class EquationSystems > { > > public: > MeshType mesh; > }; > > seems to solve the problem nicely (if indeed there is a problem). Oh, no. If you want to do something like the templated get_system() method to take the dynamic_cast out of the users' hands, I could probably be talked into that. But adding a template argument to the whole EquationSystems class? No way! I'll fork libMesh; so help me I'll fork it! ;-) I don't think it's a real problem, design-wise. 99% of user code either only needs a MeshBase class or already has access to the leaf class object they constructed, and I don't think making the other 1% of users do a dynamic_cast themselves is outrageous. The only problem is that API-wise, I'll bet a lot of users assign get_mesh() results to a Mesh& reference even though they only need the MeshBase functions. It's a four-character fix, but anything that breaks existing code at all still isn't a nice thing to do. > Library code may never need anything more than a MeshBase in there, but a > savy user could declare an EquationSystems object based on whatever kind of > mesh they choose. > > It just seems a little safer than requiring the user to perform dynamic > casts. Are you sure? Even C programmers understand dynamic casts. Even C++ programmers don't fully understand templates. --- Roy |
From: Benjamin K. <ben...@na...> - 2007-10-09 13:28:29
|
> Should we put out a libMesh 6.1 (with the new PETSc compatibility, if > we can work out whatever this latest petsc snoop failure was) before I > commit the change? That way we'd give everyone compatibility which > is as up to date as possible before breaking things. > Absolutely. I'd like to test portability to some of the standard machines, but then we should roll out 0.6.1. Any of us can do it once we are happy with the codebase, but don't forget the contrib/bin/create_libmesh_release shell script for convenience. -Ben |
From: Roy S. <roy...@ic...> - 2007-10-09 18:41:26
|
On Tue, 9 Oct 2007, Benjamin Kirk wrote: >> Should we put out a libMesh 6.1 (with the new PETSc compatibility, if >> we can work out whatever this latest petsc snoop failure was) before I >> commit the change? That way we'd give everyone compatibility which >> is as up to date as possible before breaking things. >> > > Absolutely. I'd like to test portability to some of the standard machines, > but then we should roll out 0.6.1. Sounds good. Let me know when you're happy portability-wise; I'm really only set up on the cfdlab, lonestar, and (when I get around to updating it) a Cygwin install on my laptop. While we're at it, we probably ought to strip the "known to work" list in installation.php down to be those systems we're testing regularly. Who knows when we might have added some fancy code that's in the C++ standard but not in the compatibility range of older compilers. --- Roy |
From: Benjamin K. <ben...@na...> - 2007-10-09 19:37:02
|
> > Sounds good. Let me know when you're happy portability-wise; I'm > really only set up on the cfdlab, lonestar, and (when I get around to > updating it) a Cygwin install on my laptop. > Along these lines, we just got a shiny new opteron cluster and bought the latest PGI compilers (mostly for the F77/F90 support). > While we're at it, we probably ought to strip the "known to work" list > in installation.php down to be those systems we're testing regularly. > Who knows when we might have added some fancy code that's in the C++ > standard but not in the compatibility range of older compilers. So now I have a build of libMesh using PGI 7.0-7, but there is a catch... I had to strip out all the FEXYZ stuff. Sound familiar? I'm thinking of querying the user list -- perhaps that specialization is more of a liability than an asset at this point. If nothing else, I am seriously considering #ifdef'ing the whole thing. -Ben |
From: John P. <pet...@cf...> - 2007-10-09 19:42:13
|
Benjamin Kirk writes: > > So now I have a build of libMesh using PGI 7.0-7, but there is a catch... I > had to strip out all the FEXYZ stuff. Sound familiar? Trouble with FEXYZ sounds familiar (though I thought Roy found 'make distclean' fixed his issue with the intel compilers), but a successful compilation of Libmesh with PGI?! Never heard of that happening before! Their compilers must have improved a lot in the last few years, or maybe it's just because you are a paying customer now... -J |
From: Roy S. <roy...@ic...> - 2007-10-09 19:53:40
|
On Tue, 9 Oct 2007, John Peterson wrote: > Benjamin Kirk writes: > > > So now I have a build of libMesh using PGI 7.0-7, but there is a catch... I > > had to strip out all the FEXYZ stuff. Sound familiar? > > Trouble with FEXYZ sounds familiar (though I thought Roy found 'make distclean' > fixed his issue with the intel compilers), Correct, and correct. Ben, what specfically was the problem you came across? I'd like to keep FEXYZ in the library if possible; it could be taken out and the same output achieved with FE<XYZ>, but the FEXYZ class isn't just a backwards-compatibility wrapper like Mesh has become, it's actually got some implementations of shape_functions methods that have been overridden for efficiency. --- Roy |