Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Close
From: Min Xu <minxu@sc...>  20051115 16:29:59

Dear developers and users of libmesh: I am solving a PDE with its coefficient defined on a mesh and I used MeshFunction to store the value of the coefficient. The relevant code are following where the coefficient is the variable alpha. In main(): // Map the solution data to MeshFunction MeshFunction alphaMeshFunc = MeshFunction(alpha_equation_systems, alpha_and_gradient, alpha_dof_map, 0 // var_id=0 for alpha ); // build the MeshFunction ready for use. alphaMeshFunc is valid even when // alpha is updated. alphaMeshFunc needs clear and init when the mesh changes. alphaMeshFunc.init(); // assign to the global variable alphaMeshFuncPtr = &alphaMeshFunc; In the assemble routine: for (unsigned int qp=0; qp<qrule.n_points(); qp++) { double alphav = (*alphaMeshFuncPtr)(q_points[qp]); .......(*) ... } The program works without any error in the serial mode. When I submit the program to a linux cluster, the following errors occurred: /home/m254/minxu/libmesh/include/numerics/petsc_vector.h:693: T PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion `((i >= this>first_local_index()) && (i < this>last_local_index()))' failed. The error traced back to the line marked (*) above when invoking alphaMeshFuncPtr. Any idea? I am stuck with this problem for while already. Any help will be greatly appreciated. Thanks! Min 
From: Min Xu <minxu@sc...>  20051115 19:45:16

Note: I found out that portion of my message does not show up in the mailinglist web interface. So I resent the message. Dear developers and users of libmesh: I am solving a PDE with its coefficient defined on a mesh and I used MeshFunction to store the value of the coefficient. The relevant code are following where the coefficient is the variable alpha. In main(): // Map the solution data to MeshFunction MeshFunction alphaMeshFunc = MeshFunction(alpha_equation_systems, alpha_and_gradient, alpha_dof_map, 0 // var_id=0 for alpha ); // build the MeshFunction ready for use. alphaMeshFunc is valid even when // alpha is updated. alphaMeshFunc needs clear and init when the mesh changes. alphaMeshFunc.init(); // assign to the global variable alphaMeshFuncPtr = &alphaMeshFunc; In the assemble routine: for (unsigned int qp=0; qp<qrule.n_points(); qp++) { double alphav = (*alphaMeshFuncPtr)(q_points[qp]); (1) ... } The program works without any error in the serial mode. When I submit the program to a linux cluster, the following errors occurred: /home/m254/minxu/libmesh/include/numerics/petsc_vector.h:693: T PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion `((i >= this>first_local_index()) && (i < this>last_local_index()))' failed. The error traced back to the line marked (1) above when invoking alphaMeshFuncPtr. Any idea? I am stuck with this problem for while already. Any help will be greatly appreciated. Thanks! Min 
From: Roy Stogner <roystgnr@ic...>  20051115 19:56:31

On Tue, 15 Nov 2005, Min Xu wrote: > PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion > `((i >= this>first_local_index()) && (i < this>last_local_index()))' > failed. > > The error traced back to the line marked (1) above when invoking > alphaMeshFuncPtr. > > Any idea? On first glance, it appears possible to me that the only data vectors being properly redistributed with the parallel mesh are the vectors registered with add_vector(), and the data vector used internally by MeshFunction is not one of these. However, MeshFunction does have access to the EquationSystems object in its constructor, so if we were to add the restriction that MeshFunctions had to be created at initialization time, we could make it use a registered vector without much trouble. > I am stuck with this problem for while already. Any help will be greatly > appreciated. I don't want to muck around with a fix for MeshFunction until I hear from Ben, who understands the PETSc issues much better than I do. If you don't want to wait for an official fix, it's possible (and in most cases more efficient, if you're just taking function values at the usual quadrature points) to duplicate the MeshFunctionality yourself, by doing an add_vector() manually and doing the sum of coefficients times shape functions in your own code.  Roy Stogner 
From: Min Xu <minxu@sc...>  20051116 01:41:40

Thanks Roy. I am afraid that the quick fix may not apply to my situation where the mesh the coefficient sits on is different from that of the solution. If I dig further, the line causing the error is line 227 of mesh_function.C 214 FEComputeData data (this>_eqn_systems, mapped_point); 215 216 FEInterface::compute_data (dim, fe_type, element, data); 217 218 // where the solution values for the varth variable are stored 219 std::vector<unsigned int> dof_indices; 220 this>_dof_map.dof_indices (element, dof_indices, var); 221 222 // interpolate the solution 223 { 224 Number value = 0.; 225 226 for (unsigned int i=0; i<dof_indices.size(); i++) 227 value += this>_vector(dof_indices[i]) * data.shape[i]; 228 229 output(index) = value; 230 } The reported error pointing to line 227 at dof_indices[i]. Anything wrong here in the code when it is executed in a parallel environment? It looks to me that MeshFunction should handle the parallel scenario well. The problem is that the way that _vector is distributed over the processors may be different from the solution vector. A quick fix, I think, is to use a serial version of the coefficient alpha. As the variable alpha points to the dummy solution vector of the AlphaEquationSystems. My question is then: Can one force an EquationSystem to use a serial vector for its solution in a parallel environment? Thanks again. Min believe that MeshFunction On Tuesday 15 November 2005 14:56, Roy Stogner wrote: > On Tue, 15 Nov 2005, Min Xu wrote: > > PetscVector<T>::operator()(unsigned int) const [with T = Real]: Assertion > > `((i >= this>first_local_index()) && (i < this>last_local_index()))' > > failed. > > > > The error traced back to the line marked (1) above when invoking > > alphaMeshFuncPtr. > > > > Any idea? > > On first glance, it appears possible to me that the only data vectors > being properly redistributed with the parallel mesh are the vectors > registered with add_vector(), and the data vector used internally by > MeshFunction is not one of these. > > However, MeshFunction does have access to the EquationSystems object > in its constructor, so if we were to add the restriction that > MeshFunctions had to be created at initialization time, we could make > it use a registered vector without much trouble. > > > I am stuck with this problem for while already. Any help will be greatly > > appreciated. > > I don't want to muck around with a fix for MeshFunction until I hear > from Ben, who understands the PETSc issues much better than I do. > > If you don't want to wait for an official fix, it's possible (and in > most cases more efficient, if you're just taking function values at > the usual quadrature points) to duplicate the MeshFunctionality > yourself, by doing an add_vector() manually and doing the sum of > coefficients times shape functions in your own code. >  > Roy Stogner > > >  > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 