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 