Dear Wolfgang,
thanks for your detailed explanation and also for the proposed solution. I
will think about this possibility.
Best,
Dustin
Am Montag, 27. August 2018 22:41:09 UTC+2 schrieb Wolfgang Bangerth:
>
> On 08/27/2018 02:06 AM, Dustin Kumor wrote:
> >
> > I like
Dear all,
I like to create a three dimensional Lagrange finite element that uses
ansatz functions of the following form: N_i (x,y,z) = q_i(x,y) p_i (z),
where q_i (x,y) are the basis functions of a two dimensional Lagrange
finite element of arbitrary degree, basically FE_Q<2> (degree) and p_i a
Daniel,
thanks for the hint. I will have a look at this on the weekend.
Best,
Dustin
Am Donnerstag, 23. August 2018 13:45:41 UTC+2 schrieb Daniel Arndt:
>
> Dustin,
>
> I can put that into a pull request but I've never done this before so I'm
>> going to need someone guiding me through the whol
at (and with writing a test).
>
> (For reference, post-9.0, the class is now called AffineConstraints.)
>
> Best and thanks for pointing this out!
> Wolfgang
>
>
> On 08/22/2018 08:30 AM, Dustin Kumor wrote:
> > Dear all,
> >
> > in my opinion there
Dear all,
in my opinion there is a small bug in the implementation of the
ConstraintMatrix member function add_entries in file constraint_matrix.cc
(release Version 9.0, lines 224-261). The current piece of code is:
224 void
225 ConstraintMatrix::add_entries
226 (const size_type
Dear Martin, dear Bruno,
I'm sorry for giving a feedback to your answers that late, but I have been
really busy with another project and had no time to deal with this problem.
@Martin: After applying the patch I get the same run time results as you
did. So thank you for figuring out and fixing
Dear all,
some additional information. Out of interest I switched back to the last
release version of the deal.ii library 8.4.1 and made a run with this
version. The problem is still there and even worse. I attached again the
two log files for debug and release mode respectively.
Best
Dustin
Dear Martin,
unfortunately I have to revise all my statements. Updating the deal.II
library to the most recent developement version did not solve the problem.
I made a stupid mistake while creating the file for the test case. The
function make_offdiagonal_sparsity_pattern () has been commented
Dear Martin,
the update to the most recent development version solved the problem. Now
time needed to finish the copy operation is in the expected range. Thanks a
lot for your support.
Best,
Dustin
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
Dear Martin,
I'm using 8.5.0-pre. But I haven't updated the code for a long time. I will
do this first, then compile the library again and let you know about the
results.
Best,
Dustin
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://grou
Dear Martin,
after one week on a conference and two additional weeks on holidays I am
finally back in office and realised the test case. I attached the file to
the post and also log files for runs for both in Debug and Release mode.
You can call DynamicSparsityPattern::n_nonzero_elements() to g
Dear Martin,
thank you for answering that quickly.
How is your computational setup, i.e., how many nonzero entries do you have
> in your matrix?
>
I'm not sure if I understand what you mean. Do you mean the number of
nonzero entries in *SparseMatrix* or in the *BlockSparsityPattern* or in
th
Dear all,
I have got a question about the time it takes to copy a
*BlockDynamicSparsityPattern
*into a* BlockSparsityPattern* using the *copy_from()*-function.
In my special case I have a vector-valued 3D problem with trilinear finite
elements. The system matrix is 3x3 block matrix with non-zer
13 matches
Mail list logo
