[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
-------------------------------------------------------------------------