## Re: [Libmesh-users] Writing mesh in parallel

 Re: [Libmesh-users] Writing mesh in parallel From: robert - 2011-08-30 10:49:39 ```Am Freitag, den 26.08.2011, 09:09 -0500 schrieb Roy Stogner: > > On Fri, 26 Aug 2011, robert wrote: > > > probably not - it's the first time that I am working in parallel so I > > don't know how to do it yet. > > Instead of this: > > > MeshBase::const_element_iterator el = > > mesh.active_local_elements_begin(); > > const MeshBase::const_element_iterator end_el = > > mesh.active_local_elements_end(); > > You want to iterate from elements_begin() to elements_end() ok, thanks. Did I get it right that looping through the elements is not done in parallel then? I am also asking because when I use the results of the old calculation to set up the starting conditions for the new one I do something like: ///MeshBase::const_node_iterator nd = new_mesh.local_nodes_begin(); ///const MeshBase::const_node_iterator end_nd = new_mesh.local_nodes_end(); MeshBase::const_node_iterator nd = new_mesh.nodes_begin(); const MeshBase::const_node_iterator end_nd = new_mesh.nodes_end(); for ( ; nd != end_nd ; ++nd ){ Node *nod = *nd; Real x,y,z; x = nod->operator()(0); y = nod->operator()(1); z = nod->operator()(2); unsigned int nod_dof = nod->dof_number(0,0,0); double shift = 0.; Point point; // shiftx, shifty, shiftz are parameters due to geologic event // Is maybe not the most elegant way but it works point = Point( x + shiftx , y + shifty , z+shiftz ); Number u_p = old_system.point_value (0, point); // old_mesh.clear_point_locator(); // do I need the point locator? seems to make it slower if (nod_dof < T_system.n_dofs()) T_system.solution->set(nod_dof,u_p); } I know, the point_value is quite slow and using it within the nodes loop is maybe not the best thing to do. Short explanation: due to a volcanic event some points in the earth's crust are moving. Since the event happens fastly these points should keep their temperature ... blablabla Do you have any suggestions to improve the above code?? thank you very much, Robert > --- > Roy ```

### Thread view

 [Libmesh-users] Writing mesh in parallel From: robert - 2011-08-26 10:49:44 ```Hello, My calculation consists of several parts. For each part the geometry changes and I create a new mesh. I want to save the old mesh in a file by: new_equation_systems.write("../bgscratch/old_equation_systems.xdr"); new_mesh.write("../bgscratch/old_mesh.xdr"); If I run this code in serial there is no problem at all. However, if I run it in parallel on a BlueGeneP using mpirun and a partition with 32 processors then, writing the equation system works fine but, writing the mesh doesn't seem to work. For 'new_mesh.write("../bgscratch/old_mesh.xdr");' the program gets stuck. There is no error and it doesn't abort, it just seems to take quite a long time. In contrast, the new_equation_systems.write("../bgscratch/old_equation_systems.xdr"); takes some miliseconds. What am I doing wrong? Thanks, Robert ```
 Re: [Libmesh-users] Writing mesh in parallel From: robert - 2011-08-26 13:18:41 ```Hi, is it possible that the boundary_ids have something to do with my problem? During the calculation I manually set the boundary ids by: mesh.boundary_info->add_node (nod, idval); mesh.boundary_info->add_side (elem,s, idval); If I write the mesh before everything works fine. In contrast, if I do it after setting the boundary ids, I can't write it any more (except with gmv). Robert Am Freitag, den 26.08.2011, 12:49 +0200 schrieb robert: > Hello, > > My calculation consists of several parts. For each part the geometry > changes and I create a new mesh. I want to save the old mesh in a file > by: > new_equation_systems.write("../bgscratch/old_equation_systems.xdr"); > new_mesh.write("../bgscratch/old_mesh.xdr"); > > If I run this code in serial there is no problem at all. However, if I > run it in parallel on a BlueGeneP using mpirun and a partition with 32 > processors then, writing the equation system works fine but, writing the > mesh doesn't seem to work. For > > 'new_mesh.write("../bgscratch/old_mesh.xdr");' > > the program gets stuck. There is no error and it doesn't abort, it just > seems to take quite a long time. In contrast, the > > new_equation_systems.write("../bgscratch/old_equation_systems.xdr"); > > takes some miliseconds. > What am I doing wrong? > > Thanks, > Robert > > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under \$10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users ```
 Re: [Libmesh-users] Writing mesh in parallel From: Roy Stogner - 2011-08-26 13:29:10 ```On Fri, 26 Aug 2011, robert wrote: > is it possible that the boundary_ids have something to do with my > problem? > During the calculation I manually set the boundary ids by: > > mesh.boundary_info->add_node (nod, idval); > mesh.boundary_info->add_side (elem,s, idval); Are you doing this consistently on every processor? --- Roy ```
 Re: [Libmesh-users] Writing mesh in parallel From: robert - 2011-08-26 13:36:22 ```Roy, probably not - it's the first time that I am working in parallel so I don't know how to do it yet. Would be great if you could give me a hint. Thanks in advance, Robert Here function I am using: std::cout << "set boundary_id's ..."; MeshBase& MB (mesh); MB.find_neighbors(); // otherwise the function elem->neighbor(s) would always return NULL std::vector max = find_max_xyz(mesh); std::vector min = find_min_xyz(mesh); MeshBase::const_element_iterator el = mesh.active_local_elements_begin(); const MeshBase::const_element_iterator end_el = mesh.active_local_elements_end(); for ( ; el != end_el; ++el) { Elem* elem = *el; for (unsigned int s=0; sn_sides(); s++){ if (elem->neighbor(s) == NULL){ AutoPtr side = elem->side(s); int _links = 0; int _rechts = 0; int _unten = 0; //int _oben = 0; int _vorne = 0; int _hinten = 0; for (unsigned int i=0; in_nodes(); i++){ Node* nod = side->get_node(i); Real x,y,z; x = nod->operator()(0); y = nod->operator()(1); z = nod->operator()(2); if (x <= min.at(0)+1e-8) { _links++; mesh.boundary_info->add_node (nod, 3); } if (x >= max.at(0)-1e-8) { _rechts++; mesh.boundary_info->add_node (nod, 1); } if (y <= min.at(1)+1e-8) { _vorne++; mesh.boundary_info->add_node (nod, 4); } if (y >= max.at(1)-1e-8) { _hinten++; mesh.boundary_info->add_node (nod, 5); } if (z <= min.at(2)+1e-8) { _unten++; mesh.boundary_info->add_node (nod, 0); } if (z >= max.at(2)-1e-8) { mesh.boundary_info->add_node (nod, 2); } } if ( _links == side->n_nodes()) mesh.boundary_info->add_side (elem,s, 3); else if (_rechts == side->n_nodes() ) mesh.boundary_info->add_side (elem,s, 1); else if (_unten == side->n_nodes() ) mesh.boundary_info->add_side (elem,s, 0); else if (_vorne == side->n_nodes() ) mesh.boundary_info->add_side (elem,s, 4); else if (_hinten == side->n_nodes() ) mesh.boundary_info->add_side (elem,s, 5); else mesh.boundary_info->add_side (elem,s, 2); // std::cout << mesh.boundary_info->boundary_id (elem,s) << std::endl;//= 0; } } } ^std::cout << "\t\t\t\t\tdone"< On Fri, 26 Aug 2011, robert wrote: > > > is it possible that the boundary_ids have something to do with my > > problem? > > During the calculation I manually set the boundary ids by: > > > > mesh.boundary_info->add_node (nod, idval); > > mesh.boundary_info->add_side (elem,s, idval); > > Are you doing this consistently on every processor? > --- > Roy ```
 Re: [Libmesh-users] Writing mesh in parallel From: Roy Stogner - 2011-08-26 14:09:38 ``` On Fri, 26 Aug 2011, robert wrote: > probably not - it's the first time that I am working in parallel so I > don't know how to do it yet. Instead of this: > MeshBase::const_element_iterator el = > mesh.active_local_elements_begin(); > const MeshBase::const_element_iterator end_el = > mesh.active_local_elements_end(); You want to iterate from elements_begin() to elements_end() --- Roy ```
 Re: [Libmesh-users] Writing mesh in parallel From: robert - 2011-08-30 10:49:39 ```Am Freitag, den 26.08.2011, 09:09 -0500 schrieb Roy Stogner: > > On Fri, 26 Aug 2011, robert wrote: > > > probably not - it's the first time that I am working in parallel so I > > don't know how to do it yet. > > Instead of this: > > > MeshBase::const_element_iterator el = > > mesh.active_local_elements_begin(); > > const MeshBase::const_element_iterator end_el = > > mesh.active_local_elements_end(); > > You want to iterate from elements_begin() to elements_end() ok, thanks. Did I get it right that looping through the elements is not done in parallel then? I am also asking because when I use the results of the old calculation to set up the starting conditions for the new one I do something like: ///MeshBase::const_node_iterator nd = new_mesh.local_nodes_begin(); ///const MeshBase::const_node_iterator end_nd = new_mesh.local_nodes_end(); MeshBase::const_node_iterator nd = new_mesh.nodes_begin(); const MeshBase::const_node_iterator end_nd = new_mesh.nodes_end(); for ( ; nd != end_nd ; ++nd ){ Node *nod = *nd; Real x,y,z; x = nod->operator()(0); y = nod->operator()(1); z = nod->operator()(2); unsigned int nod_dof = nod->dof_number(0,0,0); double shift = 0.; Point point; // shiftx, shifty, shiftz are parameters due to geologic event // Is maybe not the most elegant way but it works point = Point( x + shiftx , y + shifty , z+shiftz ); Number u_p = old_system.point_value (0, point); // old_mesh.clear_point_locator(); // do I need the point locator? seems to make it slower if (nod_dof < T_system.n_dofs()) T_system.solution->set(nod_dof,u_p); } I know, the point_value is quite slow and using it within the nodes loop is maybe not the best thing to do. Short explanation: due to a volcanic event some points in the earth's crust are moving. Since the event happens fastly these points should keep their temperature ... blablabla Do you have any suggestions to improve the above code?? thank you very much, Robert > --- > Roy ```