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
