Dear Roy,
On Fri, 24 Apr 2009, Roy Stogner wrote:
>>> There isn't an easy way that I know of - the easiest way is to loop
>>> over all nodes and then all elements, getting the indices for the
>>> desired variable and then calling NumericVector::set() for each.
>>
>> First all nodes, then all elements? I guess you mean first all elements,
>> then all nodes of the respective element. At least, that's what I did in
>> the meantime. It compiles, but I haven't tested yet whether it works.
>
> Sadly no, I meant all nodes, then all elements - Elem is a DofObject
> too, and that's where we store degrees of freedom for finite elements
> (e.g. discontinuous monomials) that need some connectivity-less DoFs
> but can otherwise get away working on with low order geometric
> elements.
I'm not sure whether I understood this. I'm doing this now:
const unsigned int minIndex = system.solution->first_local_index();
const unsigned int maxIndex = system.solution->last_local_index();
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)
{
const Elem* elem = *el;
dof_map.dof_indices (elem, dof_indicesPsi, psiVar);
const unsigned int n_dofsPsi = dof_indicesPsi.size();
for (unsigned int l=0; l<n_dofsPsi; l++)
{
const unsigned int index = dof_indicesPsi[l];
if((index>=minIndex) && (index<maxIndex))
{
v.set(index,0.0);
}
}
}
I understand that it will do some multiple work. In this, it will not
be suitable for things like scaling of a vector, because some
components might be scaled several times. When looping over the nodes
first, how do I get the dofs the live on a node and correspond to a
given variable?
>> Let's start with a thought:
>>
>> System::clear_variable (NumericVector<Number>& v, unsigned int var_num);
>>
>> System::scale_variable (NumericVector<Number>& v, unsigned int var_num,
>> Number factor);
>
> Hmm... it occurs to me that we've already got a perfectly good API
> (which includes zero(), scale(), add(), set(), operator=() for the
> above four tasks, plus a bunch of other potentially useful stuff) in
> numeric_vector.h. Maybe the most intuitive thing to do is add *one*
> method:
>
> AutoPtr<NumericVector<Number> > System::build_variable_vector(unsigned
> int var_num, NumericVector<Number> *full_vec=NULL)
>
> This would return some derived type ("SliceVector"?) that didn't store
> its own data, but rather just an index map, so it could act as a proxy
> to the appropriate components of full_vec (or to System::solution by
> default).
Yes, very good idea. But I'm unsure how the index map would work:
from where to where does it map? Also, I wonder what such a
SliceVector does when grid refinement takes place during its lifetime.
It seems to me that, although introducing a nice API, this approach
will require a lot of work.
> Not sure how efficient this idea (or our NumericVector indirection in
> general) is, but it would certainly be versatile.
Yes, the efficiency is another point that is questionable.
Anyway: If I should some day write a patch that does *not* use your
"SliceVector" approach: Would you accept that patch or not?
Best Regards,
Tim
--
Dr. Tim Kroeger
tim.kroe...@mevis.fraunhofer.de Phone +49-421-218-7710
tim.kroe...@cevis.uni-bremen.de Fax +49-421-218-4236
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
