Boost logo

Ublas :

Subject: Re: [ublas] Boundary condition application on matrices
From: Karl Rupp (rupp_at_[hidden])
Date: 2011-05-01 06:35:19

Hi Umut,

if you cannot influence the matrix assembly, then I cannot think of any
other reasonable option apart from the one you just proposed. I hope
that this does not turn out to be a bottleneck for your application...

Best regards,

On 05/01/2011 12:26 PM, Umut Tabak wrote:
> On 04/29/2011 01:54 PM, Karl Rupp wrote:
>> Hi Umut,
>> the best approach typically is to not write boundary conditions to the
>> matrix at all. A little bit of extra logic during the assembly process
>> can write the values directly to the right hand side vector. This is
>> typically much faster than manipulating the matrix in a post-assembly
>> step.
>> Sorry if that's not the let-ublas-do-the-job-answer you may have been
>> looking for. ;-)
>> Best regards,
>> Karli
> Hi Karli,
> I am afraid that is not possible because I am getting the matrices in
> the assembled format from a commercial finite element code, and I have
> to extract the information related to structural and fluid degrees of
> freedom by myself. So that is the reason why I puzzled with this
> approach, matrix_indirect seems to be quite fast to extract the
> submatrix, however I could not find a way to efficiently assign or write
> the entries to a compressed_matrix.
> I guess, I will have to keep a map<int, vector<int> > for row -> col
> indices, then I will have to process the key information which is rather
> fast in a std::map and create the new matrix by iterating over this map
> structure both reading from the original matrix and writing to the new
> matrix at the same time.
> BTW, for a monophysical problem, there are some workarounds, however for
> a problem with more than two physics, this is the only option I see
> since there are going to be different types of dofs which have to be
> extracted from the matrix.
> Best,
> Umut
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> Sent to: rupp_at_[hidden]