getfem-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Getfem-users] Problems with sparse vectors in assembly routines


From: Yves Renard
Subject: Re: [Getfem-users] Problems with sparse vectors in assembly routines
Date: Fri, 13 Oct 2006 12:50:01 +0200
User-agent: KMail/1.7.2

Hi Roman,

You are right, assembly procedure only accept dense vectors for the data.
In fact, if it is a question of memory size, we estimated that the necessary 
memory needed to store a dense vector is always less than the memory needed 
to store a stiffness matrix for instance. Additionnaly, the vector can be 
destroyed after the call of the assembly procedure.
If it is a question of assembly time, you can restrict the assembly to only a 
few element giving the list of elements as an additional parameter.

However, I can imagine that in certain situations, the dense vector is a 
disadvantage.  Can you specify a little bit the application you are working 
on ?

Yves.


> Hi All,
>
> First of all my appologies if this is duplicated message
> (I messed with e-mail adresses).
>
> I would be very grateful for help with the following issue.
> I am using GetFEM++ 2.0 on a GNU/Linux box with gcc 3.3.5
>
> I have encountered a problem with using sparse vectors in assembly
> routines (for dense vectors everything works OK):
>
> In the following code I am trying to assembly Neumann boundary
> condition for 1D problem. I have created regions with identifiers
> 0 and 1 for each domain end, respectively. Neuman boundary conditions
> can be set on either end:
>
> //-----------------8<-----------------
>
>   typedef gmm::wsvector<bgeot::scalar_type> SparseVector;
>   getfem::mesh_fem mf_u;
>
>   // skip some code
>
>   SparseVector R;
>   gmm::resize(R,mf_u.nb_dof()); gmm::clear(R);
>
>   for (int i=0; i<2; i++) {
>     for (dal::bv_visitor d(mf_u.dof_on_set(i)); !d.finished(); ++d) {
>       R[d] = bc_value[i];
>     }
>   }
>   for (int i=0; i<2; i++) {
>     if (bc_type[i] == NEUMANN_BC) {
>       getfem::asm_source_term(F, im_u, mf_u, mf_u, R, i);
>     }
>   }
> //-----------------8<-----------------
>
> The problem is with routine asm_source_term. Somewhere under the hood
> calling this routine requires the usage of operator+= on the sparse
> vector iterator. The symptoms is the following error message:
>
> -------------------8<-------------------
> g++ -c  -g  -I/home/putanowr/include -I. rod7.cxx -o rod7.o
> /home/putanowr/include/getfem_assembling_tensors.h: In member function
> `void getfem::asm_data<VEC>::copy_with_mti(const
>    std::vector<bgeot::tensor_strides, std::allocator<bgeot::tensor_strides>
> >&, bgeot::multi_tensor_iterator&) const [with VEC =
> gmm::wsvector<scalar_type>] ':
> /usr/include/c++/3.3/bits/stl_map.h:120:   instantiated from here
> /home/putanowr/include/getfem_assembling_tensors.h:278: error: no match for
>    'operator+=' in 'it += (+(+str)->std::vector<_Tp, _Alloc>::operator[]
> [with _Tp = bgeot::tensor_strides, _Alloc =
>    std::allocator<bgeot::tensor_strides>](i))->std::vector<_Tp,
>    _Alloc>::operator[] [with _Tp = int, _Alloc =
>    std::allocator<int>]((+mti)->bgeot::multi_tensor_iterator::index(i))'
> make: *** [rod7.o] Error 1
> make: Leaving directory
> `/home/putanowr/programming/c++/getfem/tutorials/tut1'
> -------------------8<-------------------
>
> If I substitute dense vector for a sparse one then the whole code works OK.
> However I imagine that here is the place where sparse vector should be
> used as otherwise it is a waste of space. Am I right?
>
> I know that the error message shown above is caused by the fact that
> sparse wsvector is based on std::map container for which iterators
> does not provide operator+=, as in general case that would make no sense.
>
> Could you please advise me? I would like to avoid creation of dense vector
> for the situation where I use only two of its elements. I imagine I could
> write appropriate container myself but I wonder what is the right way of
> dealing with such situations in GetFEM++
>
> Thank you in advance for your help
>
> Regards
>
> Roman
> --
> Roman Putanowicz  < address@hidden  >
> Institute for Computational Civil Engng (L-5)
> Dept. of Civil Engng, Cracow Univ. of Technology
> www.l5.pk.edu.pl, tel. +48 12 628 2569, fax 2034

-- 
-------------------------------------------------------------------------
  Yves Renard (address@hidden)       tel : (33) 04.72.43.80.11
  Pole de Mathematiques, INSA de Lyon          fax : (33) 04.72.43.85.29
  Institut Camille Jordan - CNRS UMR 5208
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE
  http://math.univ-lyon1.fr/~renard
-------------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]