Good to hear that the patch works so far. I remember seeing in either MeshBase or UnstructuredMesh some comment that implies usage of subdomain_id in a way that could/might mess up things with my implementation. I will check it again and see if the subdomain information is really used for such purposes, especially in the parallel case.
> If you're having to fork > the libMesh code, though, it's possible that one of us is doing > something counterproductive - either us for not being as easily > extensible as we should be or you for not writing extensions that are > modular enough to be independent of or acceptable back in the main > library. I have some extensions to add Legendre basis elements (for now only 1D tested), quite a few changes in MeshData and few in MeshBase, UnstructuredMesh, GMsh. Like you said, I've not had time to refine these changes and comment on the necessity for these yet in order to create a decent patch. Soon, I do want this to happen because I am tired of resolving conflicts every time I update the libmesh source ! But then again, it is a luxury I can live without for now and so it has to wait ... Do let me know once you've updated the repository with the patch. Thanks Vijay On Wed, Feb 11, 2009 at 3:46 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: > >> Do have a look at the patch and if everything looks good (conventions >> and definition placement), do commit this. > > Looks good so far; let me test a couple things and I'll commit it. > >> One more question though. It occurred to me that while doing this, in >> parallel, if you partition according to subdomain_id's it will lead to >> bad partitioning in my case. > > Do we base our partitioning on subdomain ids at all? I know most of > our built-in partitioners don't. Even with ParMETIS, I was under the > impression that we handed the element connectivity graph to them but > didn't give them any subdomain information. > >> PS: My original libmesh sources have quite a few changes that do not >> exist in libmesh code repository and I had to weed out changes that >> you will not be interested here. So if anything seems out of place, >> feel free to remove it. > > I didn't see anything in need of removal. If you're having to fork > the libMesh code, though, it's possible that one of us is doing > something counterproductive - either us for not being as easily > extensible as we should be or you for not writing extensions that are > modular enough to be independent of or acceptable back in the main > library. Neither of us may have time to fix those situations, but > it's still sad - if you're significantly modifying the library but > still keeping up with our changes, the svn conflicts must be a bear. > --- > Roy > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
