From: Arvind A. <arv...@gm...> - 2009-10-27 23:08:06
|
Dear Users and Developers I am trying to read in a simple mesh created using Gmsh, which has two Physical regions. I use the example programme ex1.cc to read the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 in.msh out.msh. I find that the output of ex1.cc mentions n_subdomains()=1, though there are two physical regions. Mesh Information: mesh_dimension()=2 spatial_dimension()=3 n_nodes()=45 n_local_nodes()=45 n_elem()=32 n_local_elem()=32 n_active_elem()=32 n_subdomains()=1 n_processors()=1 processor_id()=0 Also, when I look at the out.msh file, I notice that there is only one Physical region! I have tried with both the Gmsh v1 and v2 formats. My libmesh version corresponds to the svn trunk. I have searched extensively on the archives, but didnt find a solution to my problem. Can someone with experience with Gmsh import throw more light on this issue? Thanks. Regards Arvind Ajoy The Gmsh in.geo file is as under ........ ================================================================== a = 1; // 4 3 6 // + + + // // // // // + + + // 1 2 5 Point(1) = {0, 0, 0}; Point(2) = {a, 0, 0} ; Point(3) = {a, a, 0} ; Point(4) = {0, a, 0} ; Point(5) = {2*a,0, 0}; Point(6) = {2*a,a, 0}; Line(1) = {1,2} ; Line(2) = {3,2} ; Line(3) = {3,4} ; Line(4) = {4,1} ; Line(5) = {2,5} ; Line(6) = {5,6} ; Line(7) = {6,3} ; Line Loop(8) = {4,1,-2,3} ; Line Loop(9) = {5,6,7,2}; Ruled Surface(10) = {8} ; Ruled Surface(11) = {9} ; Transfinite Line{4} = 5 ; Transfinite Line{2} = 5 ; Transfinite Line{1} = 5 ; Transfinite Line{3} = 5 ; Transfinite Line{5} = 5 ; Transfinite Line{6} = 5 ; Transfinite Line{7} = 5 ; Transfinite Surface{10} = {1,2,3,4}; Transfinite Surface{11} = {2,5,6,3}; // (Note that the list on the right hand side refers to points, not // curves. // Recombine the triangles into quads Recombine Surface{10}; Recombine Surface{11}; Physical Surface (100) = {10}; Physical Surface (200) = {11}; Physical Line (300) = {1,5,6,7,3,4}; ================================================================ |
From: Vijay S. M. <vi...@gm...> - 2009-10-27 23:20:22
|
Arvind, The reason for this is that the attributes are ignored when they are read in from the .msh file. I sent in a patch for this a long time back but I'm not entirely sure whether it was updated. Of course, I have added more things to my version of Gmsh reader/writer in libMesh to suit my needs which includes updating the subdomain_id, and the surface_id/volume_id if you want it. Meanwhile you might want to look at GmshIO's read/write implementation where they parse the attributes. The physical region is usually the first attribute that is read after the element_id and num_attributes. I'm not on my work computer now but I can probably create a new patch against the working copy and send it over tomorrow. Vijay On Tue, Oct 27, 2009 at 6:07 PM, Arvind Ajoy <arv...@gm...> wrote: > Dear Users and Developers > > I am trying to read in a simple mesh created using Gmsh, which has two > Physical regions. > I use the example programme ex1.cc to read the .msh file, and write it out > as another > .msh file, i.e ./ex1 -d 2 in.msh out.msh. > > I find that the output of ex1.cc mentions n_subdomains()=1, though there are > two physical > regions. > > Mesh Information: > mesh_dimension()=2 > spatial_dimension()=3 > n_nodes()=45 > n_local_nodes()=45 > n_elem()=32 > n_local_elem()=32 > n_active_elem()=32 > n_subdomains()=1 > n_processors()=1 > processor_id()=0 > > Also, when I look at the out.msh file, I notice that there is only one > Physical region! > > I have tried with both the Gmsh v1 and v2 formats. My libmesh version > corresponds > to the svn trunk. > > I have searched extensively on the archives, but didnt find a solution to my > problem. > Can someone with experience with Gmsh import throw more light on this issue? > > Thanks. > Regards > > Arvind Ajoy > > > > The Gmsh in.geo file is as under ........ > > ================================================================== > a = 1; > > // 4 3 6 > // + + + > // > // > // > // > // + + + > // 1 2 5 > > Point(1) = {0, 0, 0}; > Point(2) = {a, 0, 0} ; > Point(3) = {a, a, 0} ; > Point(4) = {0, a, 0} ; > Point(5) = {2*a,0, 0}; > Point(6) = {2*a,a, 0}; > > Line(1) = {1,2} ; > Line(2) = {3,2} ; > Line(3) = {3,4} ; > Line(4) = {4,1} ; > Line(5) = {2,5} ; > Line(6) = {5,6} ; > Line(7) = {6,3} ; > > Line Loop(8) = {4,1,-2,3} ; > Line Loop(9) = {5,6,7,2}; > Ruled Surface(10) = {8} ; > Ruled Surface(11) = {9} ; > > Transfinite Line{4} = 5 ; > Transfinite Line{2} = 5 ; > Transfinite Line{1} = 5 ; > Transfinite Line{3} = 5 ; > Transfinite Line{5} = 5 ; > Transfinite Line{6} = 5 ; > Transfinite Line{7} = 5 ; > > Transfinite Surface{10} = {1,2,3,4}; > Transfinite Surface{11} = {2,5,6,3}; > // (Note that the list on the right hand side refers to points, not > // curves. > > // Recombine the triangles into quads > Recombine Surface{10}; > Recombine Surface{11}; > > Physical Surface (100) = {10}; > Physical Surface (200) = {11}; > Physical Line (300) = {1,5,6,7,3,4}; > ================================================================ > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Roy S. <roy...@ic...> - 2009-10-27 23:26:29
|
On Wed, 28 Oct 2009, Arvind Ajoy wrote: > I am trying to read in a simple mesh created using Gmsh, which has > two Physical regions. I use the example programme ex1.cc to read > the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 > in.msh out.msh. > > I find that the output of ex1.cc mentions n_subdomains()=1, though > there are two physical regions. Interesting... MeshBase::n_subdomains() has been around since 2005, when Ben added it (presumably to Mesh, back then?). MeshBase::set_n_subdomains() appears to be an easy accessor that Derek added earlier this year... but other than a little overloading in the BoundaryInfo::sync() method, I can't find anywhere that subdomain counts are actually getting *set* rather than just copied around! I suppose a typical use case is for the user code to set subdomain ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... yet none of that code seems to update the total mesh id count. Ben, Derek, anyone else know what I'm missing? It seems as if updating MeshBase::_n_sbd ought to be a standard part of prepare_for_use(), but isn't... --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 00:04:41
|
Roy, I do update the n_subdomains as part of my code. In fact after all elems has been updated with the right subdomain ids, I have a call that looks like unsigned int& nsubdms = mesh.set_n_subdomains() ; nsubdms = sbd_ids.size() ; in GmshIO. Is this what you were looking for ? I optionally can add the information about subdomain_id and other attributes in .msh file to a mesh_data object. I have not used this feature in a while but never went back and removed this support either. Do you want this support in the patch too or do you still want to keep Gmsh to not use mesh_data as it originally was implemented. Do let me know about this before I create a patch tomorrow. Vijay On Tue, Oct 27, 2009 at 6:26 PM, Roy Stogner <roy...@ic...> wrote: > > On Wed, 28 Oct 2009, Arvind Ajoy wrote: > >> I am trying to read in a simple mesh created using Gmsh, which has >> two Physical regions. I use the example programme ex1.cc to read >> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >> in.msh out.msh. >> >> I find that the output of ex1.cc mentions n_subdomains()=1, though >> there are two physical regions. > > Interesting... > > MeshBase::n_subdomains() has been around since 2005, when Ben added > it (presumably to Mesh, back then?). > MeshBase::set_n_subdomains() appears to be an easy accessor that Derek > added earlier this year... but other than a little overloading in the > BoundaryInfo::sync() method, I can't find anywhere that subdomain > counts are actually getting *set* rather than just copied around! > > I suppose a typical use case is for the user code to set subdomain > ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > yet none of that code seems to update the total mesh id count. > > Ben, Derek, anyone else know what I'm missing? It seems as if > updating MeshBase::_n_sbd ought to be a standard part of > prepare_for_use(), but isn't... > --- > Roy > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2009-10-28 00:32:47
|
On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote: > Roy, I do update the n_subdomains as part of my code. In fact after > all elems has been updated with the right subdomain ids, I have a call > that looks like > > unsigned int& nsubdms = mesh.set_n_subdomains() ; > nsubdms = sbd_ids.size() ; > > in GmshIO. Is this what you were looking for ? Not quite. I'd rather fix this once and for all, not just fix it in Gmsh now, then in XDR after that, then in Exodus after that, etc. We ought to have something that gets called by MeshBase itself, probably in prepare_for_use, to keep the id count consistent after a file is loaded. > I optionally can add the information about subdomain_id and other > attributes in .msh file to a mesh_data object. I have not used this > feature in a while but never went back and removed this support > either. Do you want this support in the patch too or do you still want > to keep Gmsh to not use mesh_data as it originally was implemented. Do > let me know about this before I create a patch tomorrow. If you want to take charge of MeshData, which currently doesn't have any active developers, and which we go so far as to disable in parallel in ex12, I'd appreciate it. But until MeshData is actively maintained and up to date I'd rather avoid making anything else depend on it. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 01:26:29
|
> Not quite. I'd rather fix this once and for all, not just fix it in > Gmsh now, then in XDR after that, then in Exodus after that, etc. We > ought to have something that gets called by MeshBase itself, probably > in prepare_for_use, to keep the id count consistent after a file is > loaded. > That should work if you want to go over all elements again and then create a simple list of the subdomain id's to update the n_subdomains variable. If you just want to abstract this out, it looks like you would be wasting time doing an extra loop over the mesh when you can update this information as and when you read the mesh. Eventhough it sounds bad, it still might be the right way to go since the mesh reader already knows this information. Just my 2 cents. > If you want to take charge of MeshData, which currently doesn't have > any active developers, and which we go so far as to disable in > parallel in ex12, I'd appreciate it. But until MeshData is actively > maintained and up to date I'd rather avoid making anything else depend > on it. I remember from previous emails that no one uses mesh_data anymore. That's one of the reasons I moved away from the usage of this object. Unless more people are interested, I'll keep it this way since there is no point in just dragging around an object with limited support just so that one user benefits from it. I'll send you something regarding this tomorrow. We can go over the patch before you update it to the trunk. On Tue, Oct 27, 2009 at 7:31 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote: > >> Roy, I do update the n_subdomains as part of my code. In fact after >> all elems has been updated with the right subdomain ids, I have a call >> that looks like >> >> unsigned int& nsubdms = mesh.set_n_subdomains() ; >> nsubdms = sbd_ids.size() ; >> >> in GmshIO. Is this what you were looking for ? > > Not quite. I'd rather fix this once and for all, not just fix it in > Gmsh now, then in XDR after that, then in Exodus after that, etc. We > ought to have something that gets called by MeshBase itself, probably > in prepare_for_use, to keep the id count consistent after a file is > loaded. > >> I optionally can add the information about subdomain_id and other >> attributes in .msh file to a mesh_data object. I have not used this >> feature in a while but never went back and removed this support >> either. Do you want this support in the patch too or do you still want >> to keep Gmsh to not use mesh_data as it originally was implemented. Do >> let me know about this before I create a patch tomorrow. > > If you want to take charge of MeshData, which currently doesn't have > any active developers, and which we go so far as to disable in > parallel in ex12, I'd appreciate it. But until MeshData is actively > maintained and up to date I'd rather avoid making anything else depend > on it. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2009-10-28 02:16:33
|
On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote: >> Not quite. I'd rather fix this once and for all, not just fix it in >> Gmsh now, then in XDR after that, then in Exodus after that, etc. We >> ought to have something that gets called by MeshBase itself, probably >> in prepare_for_use, to keep the id count consistent after a file is >> loaded. > > That should work if you want to go over all elements again and then > create a simple list of the subdomain id's to update the n_subdomains > variable. If you just want to abstract this out, it looks like you > would be wasting time doing an extra loop over the mesh when you can > update this information as and when you read the mesh. Eventhough it > sounds bad, it still might be the right way to go since the mesh > reader already knows this information. Just my 2 cents. I'm tempted to ignore the cost of an extra loop when it's in the context of file I/O. Why worry about the cost of redundantly accessing RAM when we've just spent much more time accessing disk? But I suppose we can avoid that cost without killing the abstraction, if we're smart about it... If add_elem() inserted subdomain ids into a std::set, for example, then we'd just have to do a parallel union of that set during prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of O(N_elem). It would be cheap to keep the set around afterward, too, enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries. Anyone doing element destruction would be in charge of un-screwing-up the subdomain count afterwards, but all our current delete_elem uses are in contexts like coarsening, all_tri, delete_remote_elems, and other such methods that won't change the subdomain count. I'd be tempted to use a vector<bool> instead of a set, but that could backfire nastily if someone decided that their two subdomains should be numbered "1" and "1000000000". Thoughts? --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 02:52:16
|
> If add_elem() inserted subdomain ids into a std::set, for example, > then we'd just have to do a parallel union of that set during > prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of > O(N_elem). It would be cheap to keep the set around afterward, too, > enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries. If meshbase owns this set and if you have this updating call in the non-const member subdomain_id() in Elem, this should work. I would go against using a BitVector or vector<bool> instead because subdomain_id's are not necessarily consecutive and depends on how the mesh was created. From my understanding, since libMesh does not support coarsening beyond the initial mesh supplied, all AMR operations just need to propagate this information around and never have to update the n_subdomains and hence, MeshBase can provide methods to manipulate the subdomain_ids as necessary. On a side note, I also have a Parameter pointer for each element in order to accommodate arbitrary properties for the physics. Deal.II allows something like this and I remember having this discussion here before. This might be necessary to propagate the surface_ids that is read from Gmsh attributes and was wondering if you guys would like this for Elem structure. It is by default a NULL pointer and hence all the existing code would take no extra memory but if someone wants to use it, this would completely eliminate the use of MeshData and all the data can be propagated solely based on this. I have not tested this feature on AMR codes yet but it is on my TODO list... I have quite a few changes in my version of libMesh, depending on my requirements and I'm just trying to see if anyone else finds them useful too. If not, that's fine and I can send you a patch with what is required. On Tue, Oct 27, 2009 at 9:16 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote: > >>> Not quite. I'd rather fix this once and for all, not just fix it in >>> Gmsh now, then in XDR after that, then in Exodus after that, etc. We >>> ought to have something that gets called by MeshBase itself, probably >>> in prepare_for_use, to keep the id count consistent after a file is >>> loaded. >> >> That should work if you want to go over all elements again and then >> create a simple list of the subdomain id's to update the n_subdomains >> variable. If you just want to abstract this out, it looks like you >> would be wasting time doing an extra loop over the mesh when you can >> update this information as and when you read the mesh. Eventhough it >> sounds bad, it still might be the right way to go since the mesh >> reader already knows this information. Just my 2 cents. > > I'm tempted to ignore the cost of an extra loop when it's in the > context of file I/O. Why worry about the cost of redundantly > accessing RAM when we've just spent much more time accessing disk? > > But I suppose we can avoid that cost without killing the abstraction, > if we're smart about it... > > If add_elem() inserted subdomain ids into a std::set, for example, > then we'd just have to do a parallel union of that set during > prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of > O(N_elem). It would be cheap to keep the set around afterward, too, > enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries. > > Anyone doing element destruction would be in charge of un-screwing-up > the subdomain count afterwards, but all our current delete_elem uses > are in contexts like coarsening, all_tri, delete_remote_elems, and > other such methods that won't change the subdomain count. > > I'd be tempted to use a vector<bool> instead of a set, but that could > backfire nastily if someone decided that their two subdomains should > be numbered "1" and "1000000000". > > Thoughts? > --- > Roy > |
From: David K. <dknez@MIT.EDU> - 2009-10-28 12:22:52
|
> But I suppose we can avoid that cost without killing the abstraction, > if we're smart about it... > > If add_elem() inserted subdomain ids into a std::set, for example, > then we'd just have to do a parallel union of that set during > prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of > O(N_elem). It would be cheap to keep the set around afterward, too, > enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries. > > Anyone doing element destruction would be in charge of un-screwing-up > the subdomain count afterwards, but all our current delete_elem uses > are in contexts like coarsening, all_tri, delete_remote_elems, and > other such methods that won't change the subdomain count. > > I'd be tempted to use a vector<bool> instead of a set, but that could > backfire nastily if someone decided that their two subdomains should > be numbered "1" and "1000000000". > > Thoughts? > This seems like a good idea. But also an element's subdomain ID can be changed at any time so we'd have to update the set any time elem->subdomain_id() is called... But more to the point, why does MeshBase need a n_subdomains or have_subdomain_id function? It seems to me that it's unnecessary (users must have a priori knowledge of the subdomains since the user must've set the IDs), and keeping the MeshBase subdomain data in sync with the actual element subdomain IDs appears to be non-trivial. - Dave |
From: Arvind A. <arv...@gm...> - 2009-10-28 00:26:42
|
Thanks for the immediate replies. @Vijay : I look forward to the functionality in your patch! My work involves setting bound charges between dielectrics. I was in fact thinking about how I could handle these interfaces ... I guess having surface_ids in a 3D mesh will allow me to solve the problem. @Dave : I am using r3510. Could the problem arise from the fact that ex1.C uses the function mesh.read( ) .... is there something special that needs to be done for Gmsh meshes? Regards Arvind On Wed, Oct 28, 2009 at 4:56 AM, Roy Stogner <roy...@ic...>wrote: > > On Wed, 28 Oct 2009, Arvind Ajoy wrote: > > I am trying to read in a simple mesh created using Gmsh, which has >> two Physical regions. I use the example programme ex1.cc to read >> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >> in.msh out.msh. >> >> I find that the output of ex1.cc mentions n_subdomains()=1, though >> there are two physical regions. >> > > Interesting... > > MeshBase::n_subdomains() has been around since 2005, when Ben added > it (presumably to Mesh, back then?). MeshBase::set_n_subdomains() appears > to be an easy accessor that Derek > added earlier this year... but other than a little overloading in the > BoundaryInfo::sync() method, I can't find anywhere that subdomain > counts are actually getting *set* rather than just copied around! > > I suppose a typical use case is for the user code to set subdomain > ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > yet none of that code seems to update the total mesh id count. > > Ben, Derek, anyone else know what I'm missing? It seems as if > updating MeshBase::_n_sbd ought to be a standard part of > prepare_for_use(), but isn't... > --- > Roy > |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 16:38:42
Attachments:
gmsh-changes.patch
|
Arvind, If you are interested in storing the surface/volume ids for each element, you need to create additional data in Elem class. This would be very similar to the subdomain_id() method. And you could also set the partition while reading the mesh but I do not know how this would affect the mesh topology or partitioning that internally goes on through ParMetis interface. Hence, I've commented these out but it should be easy to add/change this in read_mesh(). For others who are not interested in using this extra memory, may be we can make this as a configurable option ? If not, whoever needs this functionality can add it themselves as and when a need occurs. Roy, I've attached the patch for the GmshIO.C file. I removed all references to mesh_data and so this should not intervene if you decide to pull this class out of the library later. If any of the additional changes do not follow libmesh coding patterns, feel free to change them. And do test the code with a ".msh" file using example 1. Let me know if you have any questions. Vijay On Tue, Oct 27, 2009 at 7:16 PM, Arvind Ajoy <arv...@gm...> wrote: > Thanks for the immediate replies. > > @Vijay : I look forward to the functionality in your patch! My work involves > setting > bound charges between dielectrics. I was in fact thinking about how I could > handle these interfaces ... I guess having surface_ids in a 3D mesh will > allow me to solve the problem. > > @Dave : I am using r3510. Could the problem arise from the fact that ex1.C > uses the function mesh.read( ) .... is there something special that needs to > be done for Gmsh > meshes? > > Regards > Arvind > > On Wed, Oct 28, 2009 at 4:56 AM, Roy Stogner <roy...@ic...> > wrote: >> >> On Wed, 28 Oct 2009, Arvind Ajoy wrote: >> >>> I am trying to read in a simple mesh created using Gmsh, which has >>> two Physical regions. I use the example programme ex1.cc to read >>> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >>> in.msh out.msh. >>> >>> I find that the output of ex1.cc mentions n_subdomains()=1, though >>> there are two physical regions. >> >> Interesting... >> >> MeshBase::n_subdomains() has been around since 2005, when Ben added >> it (presumably to Mesh, back then?). MeshBase::set_n_subdomains() appears >> to be an easy accessor that Derek >> added earlier this year... but other than a little overloading in the >> BoundaryInfo::sync() method, I can't find anywhere that subdomain >> counts are actually getting *set* rather than just copied around! >> >> I suppose a typical use case is for the user code to set subdomain >> ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... >> yet none of that code seems to update the total mesh id count. >> >> Ben, Derek, anyone else know what I'm missing? It seems as if >> updating MeshBase::_n_sbd ought to be a standard part of >> prepare_for_use(), but isn't... >> --- >> Roy > > |
From: Arvind A. <arv...@gm...> - 2009-10-30 14:34:04
|
Thanks a lot everyone! I am happy and relieved that I can use Gmsh meshes with libmesh. Regards Arvind On Wed, Oct 28, 2009 at 10:08 PM, Vijay S. Mahadevan <vi...@gm...>wrote: > Arvind, If you are interested in storing the surface/volume ids for > each element, you need to create additional data in Elem class. This > would be very similar to the subdomain_id() method. And you could also > set the partition while reading the mesh but I do not know how this > would affect the mesh topology or partitioning that internally goes on > through ParMetis interface. Hence, I've commented these out but it > should be easy to add/change this in read_mesh(). > > For others who are not interested in using this extra memory, may be > we can make this as a configurable option ? If not, whoever needs this > functionality can add it themselves as and when a need occurs. > > Roy, I've attached the patch for the GmshIO.C file. I removed all > references to mesh_data and so this should not intervene if you decide > to pull this class out of the library later. If any of the additional > changes do not follow libmesh coding patterns, feel free to change > them. > > And do test the code with a ".msh" file using example 1. Let me know > if you have any questions. > > Vijay > > On Tue, Oct 27, 2009 at 7:16 PM, Arvind Ajoy <arv...@gm...> wrote: > > Thanks for the immediate replies. > > > > @Vijay : I look forward to the functionality in your patch! My work > involves > > setting > > bound charges between dielectrics. I was in fact thinking about how I > could > > handle these interfaces ... I guess having surface_ids in a 3D mesh will > > allow me to solve the problem. > > > > @Dave : I am using r3510. Could the problem arise from the fact that > ex1.C > > uses the function mesh.read( ) .... is there something special that needs > to > > be done for Gmsh > > meshes? > > > > Regards > > Arvind > > > > On Wed, Oct 28, 2009 at 4:56 AM, Roy Stogner <roy...@ic...> > > wrote: > >> > >> On Wed, 28 Oct 2009, Arvind Ajoy wrote: > >> > >>> I am trying to read in a simple mesh created using Gmsh, which has > >>> two Physical regions. I use the example programme ex1.cc to read > >>> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 > >>> in.msh out.msh. > >>> > >>> I find that the output of ex1.cc mentions n_subdomains()=1, though > >>> there are two physical regions. > >> > >> Interesting... > >> > >> MeshBase::n_subdomains() has been around since 2005, when Ben added > >> it (presumably to Mesh, back then?). MeshBase::set_n_subdomains() > appears > >> to be an easy accessor that Derek > >> added earlier this year... but other than a little overloading in the > >> BoundaryInfo::sync() method, I can't find anywhere that subdomain > >> counts are actually getting *set* rather than just copied around! > >> > >> I suppose a typical use case is for the user code to set subdomain > >> ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > >> yet none of that code seems to update the total mesh id count. > >> > >> Ben, Derek, anyone else know what I'm missing? It seems as if > >> updating MeshBase::_n_sbd ought to be a standard part of > >> prepare_for_use(), but isn't... > >> --- > >> Roy > > > > > |
From: Derek G. <fri...@gm...> - 2009-10-28 16:41:24
|
A few things about this whole thread: 1. n_subdomains is useless. I did have code to set it to the correct value when reading an Exodus mesh... but it looks like it never got checked in. The reason? As you guys have been talking about there is just no good way to keep it up to date. I actually vote to have it removed. We even do things like 2. The GMSH reader and writer just needs to read and set subdomain_id's on the elements when it reads the mesh and write them back out when you write a mesh using that format. Exodus already does this... and it should be difficult to do (sounds like Vijay or Dave might already have that code hanging around somewhere). 3. Arbitrary data (like a Parameters pointer) associated with elements is BAD. Anytime you head down this path you get yourself into trouble with refinement and coarsening. The crux of the problem is understanding how to project the data down to the refined elements or up to a coarsened one. This is the path to the darkside. Instead... associate groups of elements with subdomain_ids and key off of those to associate things like material properties etc. If you think you need arbitrary data _per element_ then I implore you to think harder about the problem. Every time someone claims that they need that kind of thing I've always been able to find a more suitable solution (for instance using an extra ExplicitSystem with a constant monomial variable defined in it to get a single constant scalar per element. The difference? There is a set way to project constant monomials up and down for refinement / coarsening....). 4. There were statements to the effect of "subdomains don't change through refinement"... that might not actually be true. If you have an imbedded material with a complex boundary (that's described through some other means... probably analytically) then you might actually modify the subdomain_id of children such that they don't match their parent's subdomain_id in cases where the parent element was lying across a material boundary... Derek On Oct 27, 2009, at 5:26 PM, Roy Stogner wrote: > > On Wed, 28 Oct 2009, Arvind Ajoy wrote: > >> I am trying to read in a simple mesh created using Gmsh, which has >> two Physical regions. I use the example programme ex1.cc to read >> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >> in.msh out.msh. >> >> I find that the output of ex1.cc mentions n_subdomains()=1, though >> there are two physical regions. > > Interesting... > > MeshBase::n_subdomains() has been around since 2005, when Ben added > it (presumably to Mesh, back then?). > MeshBase::set_n_subdomains() appears to be an easy accessor that Derek > added earlier this year... but other than a little overloading in the > BoundaryInfo::sync() method, I can't find anywhere that subdomain > counts are actually getting *set* rather than just copied around! > > I suppose a typical use case is for the user code to set subdomain > ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > yet none of that code seems to update the total mesh id count. > > Ben, Derek, anyone else know what I'm missing? It seems as if > updating MeshBase::_n_sbd ought to be a standard part of > prepare_for_use(), but isn't... > --- > Roy > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Derek G. <fri...@gm...> - 2009-10-28 16:45:13
|
Just to clarify my statement on arbitrary data per element. If you understand the implications and think it makes sense for your particular application... it might not be bad (although I still think there is probably a better way). But it's not something we should put into the library itself. My experience with a certain other LARGE framework that had this capability has lead me to the belief that libMesh's _lack_ of this capability is actually one of it's most powerful assets.... Derek On Oct 27, 2009, at 5:26 PM, Roy Stogner wrote: > > On Wed, 28 Oct 2009, Arvind Ajoy wrote: > >> I am trying to read in a simple mesh created using Gmsh, which has >> two Physical regions. I use the example programme ex1.cc to read >> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >> in.msh out.msh. >> >> I find that the output of ex1.cc mentions n_subdomains()=1, though >> there are two physical regions. > > Interesting... > > MeshBase::n_subdomains() has been around since 2005, when Ben added > it (presumably to Mesh, back then?). > MeshBase::set_n_subdomains() appears to be an easy accessor that Derek > added earlier this year... but other than a little overloading in the > BoundaryInfo::sync() method, I can't find anywhere that subdomain > counts are actually getting *set* rather than just copied around! > > I suppose a typical use case is for the user code to set subdomain > ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > yet none of that code seems to update the total mesh id count. > > Ben, Derek, anyone else know what I'm missing? It seems as if > updating MeshBase::_n_sbd ought to be a standard part of > prepare_for_use(), but isn't... > --- > Roy > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 17:14:25
|
Derek, I agree that there are better ways to implement this and I can definitely see that it should not be burdened in the library itself. I have very limited usage of AMR currently in my work and so in an effort to make my code verification easy, I decided to use the existing data structures to propagate the information that is needed for the physics objects. I'll probably change this in the future but it is a low priority for me now. The topic came up again since I do store the surface id's and related data for each elem as I read the mesh file and was not sure if anyone else would be interested in this. Anyway, thanks for the suggestion ! On Wed, Oct 28, 2009 at 11:45 AM, Derek Gaston <fri...@gm...> wrote: > Just to clarify my statement on arbitrary data per element. If you > understand the implications and think it makes sense for your > particular application... it might not be bad (although I still think > there is probably a better way). But it's not something we should put > into the library itself. My experience with a certain other LARGE > framework that had this capability has lead me to the belief that > libMesh's _lack_ of this capability is actually one of it's most > powerful assets.... > > Derek > > > On Oct 27, 2009, at 5:26 PM, Roy Stogner wrote: > >> >> On Wed, 28 Oct 2009, Arvind Ajoy wrote: >> >>> I am trying to read in a simple mesh created using Gmsh, which has >>> two Physical regions. I use the example programme ex1.cc to read >>> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >>> in.msh out.msh. >>> >>> I find that the output of ex1.cc mentions n_subdomains()=1, though >>> there are two physical regions. >> >> Interesting... >> >> MeshBase::n_subdomains() has been around since 2005, when Ben added >> it (presumably to Mesh, back then?). >> MeshBase::set_n_subdomains() appears to be an easy accessor that Derek >> added earlier this year... but other than a little overloading in the >> BoundaryInfo::sync() method, I can't find anywhere that subdomain >> counts are actually getting *set* rather than just copied around! >> >> I suppose a typical use case is for the user code to set subdomain >> ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... >> yet none of that code seems to update the total mesh id count. >> >> Ben, Derek, anyone else know what I'm missing? It seems as if >> updating MeshBase::_n_sbd ought to be a standard part of >> prepare_for_use(), but isn't... >> --- >> Roy >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Derek G. <fri...@gm...> - 2009-10-28 16:53:12
|
On Oct 28, 2009, at 10:38 AM, Vijay S. Mahadevan wrote: > Arvind, If you are interested in storing the surface/volume ids for > each element, you need to create additional data in Elem class. This > would be very similar to the subdomain_id() method. Elems already have ids... elem->id(). If you are careful when adding your elems from your mesh file you can make them match what's in the mesh file. As for surfaces.... those are probably used for boundary conditions. In that case you should add those surface ids to the BoundaryInfo class associated with the Mesh. You can look in the Exodus reader / writer for an idea of how this can work. This will allow you to get lists of sides back from the BoundaryInfo object when you want to apply a boundary condition. Derek |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 17:01:43
|
> Elems already have ids... elem->id(). If you are careful when adding your > elems from your mesh file you can make them match what's in the mesh file. Yes, this is true. But I wasn't sure how the elements get renumbered eventually and I didnt want to mess with that. Moreover, my application does not rely on element id's for anything and so it did not make sense to me to rely on this. > As for surfaces.... those are probably used for boundary conditions. In > that case you should add those surface ids to the BoundaryInfo class > associated with the Mesh. You can look in the Exodus reader / writer for an > idea of how this can work. This will allow you to get lists of sides back > from the BoundaryInfo object when you want to apply a boundary condition. The surface/volume id's are specifically to group different elements, of the same physical material (same subdomain_id) that are in a certain region of the domain. For example, you could have a 3x4 lattice with patches of same material as 1 2 3 1 2 3 1 2 1 3 2 2 This is very useful in transients I've come across and makes the process of code verification so much easier rather than relying on physical coordinate points themselves. I've not used this for any kind of boundary conditions yet but I'll look in to Exodus IO to see how you've used it there. On Wed, Oct 28, 2009 at 11:52 AM, Derek Gaston <fri...@gm...> wrote: > On Oct 28, 2009, at 10:38 AM, Vijay S. Mahadevan wrote: > >> Arvind, If you are interested in storing the surface/volume ids for >> each element, you need to create additional data in Elem class. This >> would be very similar to the subdomain_id() method. > > Elems already have ids... elem->id(). If you are careful when adding your > elems from your mesh file you can make them match what's in the mesh file. > > As for surfaces.... those are probably used for boundary conditions. In > that case you should add those surface ids to the BoundaryInfo class > associated with the Mesh. You can look in the Exodus reader / writer for an > idea of how this can work. This will allow you to get lists of sides back > from the BoundaryInfo object when you want to apply a boundary condition. > > Derek > |
From: Roy S. <roy...@ic...> - 2009-10-28 17:17:00
|
On Wed, 28 Oct 2009, Derek Gaston wrote: > 1. n_subdomains is useless. I did have code to set it to the correct value > when reading an Exodus mesh... but it looks like it never got checked in. > The reason? As you guys have been talking about there is just no good way to > keep it up to date. I actually vote to have it removed. If only for backwards compatibility's sake, I'd rather not remove it. But since that seems to be a popular option, why not avoid caching it and just make it an O(N) operation? Instead of looping over elements and counting unique subdomains during prepare_for_use(), we could do so during MeshBase::n_subdomains(). Then if nobody really uses that function they don't incur any cost, but if someone does need it it's there. > 3. Arbitrary data (like a Parameters pointer) associated with elements is > BAD. I hate "pointer-to-void" data, since the whole point of C++ is supposed to be escaping that kind of low level stuff. But perhaps one day we might have a configure-time option associating a "pointer-to-ElemData" with each Elem and/or a "pointer-to-NodeData" on each Node. Then we make ElemData and NodeData both Abstract Base classes, where we could add as many pure virtual methods as is necessary to let the library handle them, e.g.: > Anytime you head down this path you get yourself into trouble with > refinement and coarsening. The crux of the problem is understanding how to > project the data down to the refined elements or up to a coarsened one. Creating pure virtual methods like ElemData::coarsen() (takes a vector of Elem*, is responsible for fixing up their parent's data pointer) and refine() (takes a parent Elem*, is responsible for fixing up the childrens' data pointers) would solve this - the user literally wouldn't be able to get their code to compile without having to make a decision about how it should handle AMR/C. I'd add serialize()/unserialize() methods too, to handle parallel communication and I/O. But there's two reasons why I'm not planning on writing user data support myself: You're absolutely right that users typically think they need this functionality when they really don't. Subdomain ids are a better solution for piecewise homogenous materials, and ExplicitSystem variables are a better solution for spatially varying fields. I haven't figured out the best way to let multiple codes with user data work together cleanly. User one writes an app or framework where their ElemData subclass encapsulates pointers to overlapping elements in a separate overset grid. User two writes an ElemData subclass which encapsulates multiscale geometry data. User three wants to use both at once. How? My ideas involve various combinations of templates and multiple inheritance, and I usually behave warily about the former and completely avoid the latter. > 4. There were statements to the effect of "subdomains don't change through > refinement"... that might not actually be true. I think I said that the total number of subdomains isn't changed by refinement... but I guess in the degnerate case your counterexample applies to that too. --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-10-28 18:35:12
Attachments:
GmshIO.patch
|
Vijay S. Mahadevan wrote: > Arvind, If you are interested in storing the surface/volume ids for > each element, you need to create additional data in Elem class. This > would be very similar to the subdomain_id() method. And you could also > set the partition while reading the mesh but I do not know how this > would affect the mesh topology or partitioning that internally goes on > through ParMetis interface. Hence, I've commented these out but it > should be easy to add/change this in read_mesh(). > > For others who are not interested in using this extra memory, may be > we can make this as a configurable option ? If not, whoever needs this > functionality can add it themselves as and when a need occurs. > > Roy, I've attached the patch for the GmshIO.C file. I removed all > references to mesh_data and so this should not intervene if you decide > to pull this class out of the library later. If any of the additional > changes do not follow libmesh coding patterns, feel free to change > them. > > And do test the code with a ".msh" file using example 1. Let me know > if you have any questions. > > Vijay Arvind, Vijay: I've checked in the attached patch for GmshIO.C --- now libMesh element subdomain IDs are written out to .msh files. In light of the discussions on the n_subdomains functionality, I didn't check in any of the subdomain vector stuff in your patch, Vijay. Sound OK? - Dave |
From: Vijay S. M. <vi...@gm...> - 2009-10-28 19:49:12
|
David, Yes that looks short and crisp. It should be enough to serialize the physical data to a .msh file. I initially thought that there was more to the n_subdomains functionality than just to let the user know the count, when you print the EquationSystems. But apparently not and so I don't think it matters ! On Wed, Oct 28, 2009 at 1:34 PM, David Knezevic <dk...@mi...> wrote: > Vijay S. Mahadevan wrote: >> >> Arvind, If you are interested in storing the surface/volume ids for >> each element, you need to create additional data in Elem class. This >> would be very similar to the subdomain_id() method. And you could also >> set the partition while reading the mesh but I do not know how this >> would affect the mesh topology or partitioning that internally goes on >> through ParMetis interface. Hence, I've commented these out but it >> should be easy to add/change this in read_mesh(). >> >> For others who are not interested in using this extra memory, may be >> we can make this as a configurable option ? If not, whoever needs this >> functionality can add it themselves as and when a need occurs. >> >> Roy, I've attached the patch for the GmshIO.C file. I removed all >> references to mesh_data and so this should not intervene if you decide >> to pull this class out of the library later. If any of the additional >> changes do not follow libmesh coding patterns, feel free to change >> them. >> >> And do test the code with a ".msh" file using example 1. Let me know >> if you have any questions. >> >> Vijay > > Arvind, Vijay: I've checked in the attached patch for GmshIO.C --- now > libMesh element subdomain IDs are written out to .msh files. In light of the > discussions on the n_subdomains functionality, I didn't check in any of the > subdomain vector stuff in your patch, Vijay. Sound OK? > > - Dave > |
From: Roy S. <roy...@ic...> - 2009-10-28 19:58:36
|
On Wed, 28 Oct 2009, Vijay S. Mahadevan wrote: > David, Yes that looks short and crisp. It should be enough to > serialize the physical data to a .msh file. I initially thought that > there was more to the n_subdomains functionality than just to let the > user know the count, when you print the EquationSystems. But > apparently not and so I don't think it matters ! Okay, I'll take that as another vote for "Who cares about n_subdomains?", I haven't seen any votes for "I need an O(1) n_subdomains() call", and even if there are any current users of that call I suspect they'll prefer an O(N) correct value to an O(1) incorrect value. I'll get rid of the cached value, and make it an O(N_elem) operation. Some of the other stuff in MeshBase::get_info() is O(N_elem) too anyway. --- Roy |
From: Derek G. <fri...@gm...> - 2009-10-28 21:10:59
|
On Oct 28, 2009, at 11:16 AM, Roy Stogner wrote: > If only for backwards compatibility's sake, I'd rather not remove it. > But since that seems to be a popular option, why not avoid caching it > and just make it an O(N) operation? Instead of looping over elements > and counting unique subdomains during prepare_for_use(), we could do > so during MeshBase::n_subdomains(). Then if nobody really uses that > function they don't incur any cost, but if someone does need it it's > there. The one time I know that everyone's code calls n_subdomains() is in mesh->print_info().... so we would incur an O(N) hit for that function. I'm personally not worried by that (our current codes call that about once per timestep depending on adaptivitiy)... just thought I would point it out. >> 3. Arbitrary data (like a Parameters pointer) associated with >> elements is BAD. > > I hate "pointer-to-void" data, since the whole point of C++ is > supposed to be escaping that kind of low level stuff. > > But perhaps one day we might have a configure-time option associating > a "pointer-to-ElemData" with each Elem and/or a "pointer-to-NodeData" > on each Node. Then we make ElemData and NodeData both Abstract Base > classes, where we could add as many pure virtual methods as is > necessary to let the library handle them, e.g.: > >> Anytime you head down this path you get yourself into trouble with >> refinement and coarsening. The crux of the problem is >> understanding how to project the data down to the refined elements >> or up to a coarsened one. > > Creating pure virtual methods like ElemData::coarsen() (takes a vector > of Elem*, is responsible for fixing up their parent's data pointer) > and refine() (takes a parent Elem*, is responsible for fixing up the > childrens' data pointers) would solve this - the user literally > wouldn't be able to get their code to compile without having to make a > decision about how it should handle AMR/C. I'd add > serialize()/unserialize() methods too, to handle parallel > communication and I/O. This is where the problem starts. As soon as you start asking users to do the refinement / coarsening projections.... all hell breaks loose. 99% of the problems with adaptivity in that other "LARGE Framework" were in the _user_ defined arbitrary data projection schemes. A lot people (typically from a time when AMR/C didn't exist) wouldn't think about how to do those projections properly (or would just throw junk into the element data structure willy nilly) and adaptivity would give just blatantly wrong answers. And then on top of that you have the problems with repartitioning and serialization (which, requiring users to write that kind of code is fraught with problems as well....). I know it feels somewhat draconian to just disallow this capability all together... but I truly believe that doing so provides a saner environment for all. > But there's two reasons why I'm not planning on writing user data > support myself: > > You're absolutely right that users typically think they need this > functionality when they really don't. Subdomain ids are a better > solution for piecewise homogenous materials, and ExplicitSystem > variables are a better solution for spatially varying fields. > > I haven't figured out the best way to let multiple codes with user > data work together cleanly. User one writes an app or framework where > their ElemData subclass encapsulates pointers to overlapping elements > in a separate overset grid. User two writes an ElemData subclass > which encapsulates multiscale geometry data. User three wants to use > both at once. How? My ideas involve various combinations of > templates and multiple inheritance, and I usually behave warily about > the former and completely avoid the latter. This was also a problem in that other framework. libMesh is elegant in this regard. Since every piece of data is supported by a discretization space.... it gives us a LOT of power and flexibility when doing things like mesh to mesh projections and the aforementioned adaptivity projections... >> 4. There were statements to the effect of "subdomains don't change >> through refinement"... that might not actually be true. > > I think I said that the total number of subdomains isn't changed by > refinement... but I guess in the degnerate case your counterexample > applies to that too. It is possible... like with a thin layer that isn't represented by the original mesh at all... but comes into view once you do some adaptivity.... Derek |
From: Roy S. <roy...@ic...> - 2009-10-30 16:30:40
|
On Wed, 28 Oct 2009, Derek Gaston wrote: > On Oct 28, 2009, at 11:16 AM, Roy Stogner wrote: > >> If only for backwards compatibility's sake, I'd rather not remove it. >> But since that seems to be a popular option, why not avoid caching it >> and just make it an O(N) operation? Instead of looping over elements >> and counting unique subdomains during prepare_for_use(), we could do >> so during MeshBase::n_subdomains(). Then if nobody really uses that >> function they don't incur any cost, but if someone does need it it's >> there. > > The one time I know that everyone's code calls n_subdomains() is in > mesh->print_info().... so we would incur an O(N) hit for that function. I'm > personally not worried by that (our current codes call that about once per > timestep depending on adaptivitiy)... just thought I would point it out. Like I mentioned in a previous message, print_info() is already O(N_elem). But now I'm worried: I don't want to inadvertently make n_subdomains() into anything *worse* than O(N_elem). I don't write any new mesh code without making sure it's ParallelMesh compatible, but the communication issue here has me wary. Does MPI have any good way to do global set unions? If not, how do I write Parallel::union(std::set<T>&)? My best idea so far: Processor 2*N+1 sends its set to Processor 2*N, which unions it with its own set. Processor 4*N+2 sends its set to Processor 4*N, which unions it with its own set. (repeat until you run out of processors) Processor 0 broadcasts its (now complete) set to everyone else. For this particular application, we'd instead use Parallel::union(std::set<T>&, unsigned int root_id=0), which applies an offset to get the complete set on root_id, but then skips the broadcast (since for n_subdomains() we only need to broadcast the set size, not its contents). --- Roy |
From: Roy S. <roy...@ic...> - 2009-10-30 18:09:13
|
On Fri, 30 Oct 2009, Roy Stogner wrote: > My best idea so far: > > Processor 2*N+1 sends its set to Processor 2*N, which unions it with > its own set. > Processor 4*N+2 sends its set to Processor 4*N, which unions it with > its own set. > (repeat until you run out of processors) Ben pointed out that if we directly gather everything to processor 0 at once, although it would require more communication in total, it wouldn't insert those log_2(N_procs) barriers to that communication, and thus it might be faster. I then realized that, faster or not, writing one line of code to call an already-tested function is definitely lazier, so I'm going with that. --- Roy |