Re: [deal.II] Create some kind of anisotropic FE_Q element
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 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 > > are the basis functions of a linear Lagrange finite element FE<1> (1). > > This does not work in deal.II. One of the fundamental assumptions made > many many years ago and very deep down in the code is that the number of > degrees of freedom per vertex/line/face is the same for all > vertices/lines/faces of a cell. But, if you wanted an element that has, > for example, linear shape functions in x-direction and quadratic shape > functions in y-directions, you would have to use one degree of freedom > for the two horizontal lines in 2d, but none for the vertical lines. > > The only way you can achieve what you want to do is to define the > element as discontinuous because, then, there are no degrees of freedom > on vertices/lines/faces. Of course, if you want the space to be > continuous, you will have to enforce that in some other way. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Create some kind of anisotropic FE_Q element
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 are
the basis functions of a linear Lagrange finite element FE<1> (1).
The class AnisotropicPolynomials provides the functionality to exactly
create the desired ansatz functions. However, I'm not sure how to use this
class to create a respective Finite Element class.
Therefore, I checked the code in fe_q.cc and the constructor is implemented
as follows.
52 template
53 FE_Q::FE_Q (const unsigned int degree)
54 :
55 FE_Q_Base, dim, spacedim>
56 (TensorProductPolynomials(Polynomials::
generate_complete_Lagrange_basis(internal::FE_Q::get_QGaussLobatto_points(
degree))),
57FiniteElementData(this->get_dpo_vector(degree),
58 1, degree,
59 FiniteElementData::H1),
60std::vector (1, false))
61 {
62 this->initialize(internal::FE_Q::get_QGaussLobatto_points(degree));
63 }
Would it be possible to replace the TensorProductPolynomial class by the
AnisotropicPolynomials class?
Best regards,
Dustin
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Small bug in ConstraintMatrix::add_entries () ?!
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 whole process. >> Same for the test writing issue. >> > Have a look at https://github.com/dealii/dealii/wiki/Contributing and > don't hesitate to ask if you have questions. > > Best, > Daniel > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Small bug in ConstraintMatrix::add_entries () ?!
Dear Wolfgang
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 whole process.
Same for the test writing issue.
Best regards
Dustin
Am Mittwoch, 22. August 2018 23:25:11 UTC+2 schrieb Wolfgang Bangerth:
>
>
> Dustin,
> good observation. I think you have found a bug indeed. I've put this
> here for now:
>https://github.com/dealii/dealii/issues/7101
> Your fix seems reasonable to me. Do you want to put that into a pull
> request? Let us know if you need help with that (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 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:
> >
> > |
> > 224void
> > 225ConstraintMatrix::add_entries
> > 226(constsize_type line,
> > 227conststd::vector>_val_pairs)
> > 228{
> > 229Assert(sorted==false,ExcMatrixIsClosed());
> > 230Assert(is_constrained(line),ExcLineInexistant(line));
> > 231
> > 232ConstraintLine*line_ptr
> =[lines_cache[calculate_line_index(line)]];
> > 233Assert(line_ptr->index ==line,ExcInternalError());
> > 234
> > 235// if in debug mode, check whether an entry for this column already
> > 236// exists and if its the same as the one entered at present
> > 237//
> > 238// in any case: skip this entry if an entry for this column already
> > 239// exists, since we don't want to enter it twice
> > 240for(std::vector>::const_iterator
> > 241 col_val_pair =col_val_pairs.begin();
> > 242 col_val_pair!=col_val_pairs.end();++col_val_pair)
> > 243{
> > 244Assert(line !=col_val_pair->first,
> > 245ExcMessage("Can't constrain a degree of freedom to itself"));
> > 246
> > 247for(ConstraintLine::Entries::const_iterator
> > 248 p=line_ptr->entries.begin();
> > 249 p !=line_ptr->entries.end();++p)
> > 250if(p->first ==col_val_pair->first)
> > 251{
> > 252// entry exists, break innermost loop
> > 253Assert(p->second ==col_val_pair->second,
> > 254ExcEntryAlreadyExists(line,col_val_pair->first,
> > 255
> > p->second,col_val_pair->second));
> > 256break;
> > 257}
> > 258
> > 259 line_ptr->entries.push_back (*col_val_pair);
> > 260}
> > 261}
> > |
> >
> > Although, it is stated in the comments (lines 235-239) there is no skip
> > of the entry col_val_pairin the case this entry already exist. The
> > breakcommand terminates the innermost loop but the push_backoperation is
> > performed nevertheless, i.e. for every element of col_val_pairs. This
> > leads to duplicates in the constraint matrix.
> > I solved the problem by just addind the three lines 246a, 255a, 258a.
> >
> > |
> > 224void
> > 225ConstraintMatrix::add_entries
> > 226(constsize_type line,
> > 227conststd::vector>_val_pairs)
> > 228{
> > 229Assert(sorted==false,ExcMatrixIsClosed());
> > 230Assert(is_constrained(line),ExcLineInexistant(line));
> > 231
> > 232ConstraintLine*line_ptr
> =[lines_cache[calculate_line_index(line)]];
> > 233Assert(line_ptr->index==line,ExcInternalError());
> > 234
> > 235// if in debug mode, check whether an entry for this column already
> > 236// exists and if its the same as the one entered at present
> > 237//
> > 238// in any case: skip this entry if an entry for this column already
> > 239// exists, since we don't want to enter it twice
> > 240for(std::vector >::const_iterator
> > 241 col_val_pair = col_val_pairs.begin();
> > 242 col_val_pair!=col_val_pairs.end(); ++col_val_pair)
> > 243{
> > 244Assert(line != col_val_pair->first,
> > 245ExcMessage("Can't constrain a degree of freedom to itself"));
> > 246
> > 246aboolentry_exists =false;
> > 247for(ConstraintLine::Entries::const_iterator
> > 248 p=line_ptr->entries.begin();
> > 249 p !=line_ptr->entries.end();++p)
> > 250if(p->first ==col_val_pair->first)
> > 251{
> &g
[deal.II] Small bug in ConstraintMatrix::add_entries () ?!
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 line,
227 const std::vector > _val_pairs)
228 {
229 Assert (sorted==false, ExcMatrixIsClosed());
230 Assert (is_constrained(line), ExcLineInexistant(line));
231
232 ConstraintLine *line_ptr = [lines_cache[calculate_line_index(
line)]];
233 Assert (line_ptr->index == line, ExcInternalError());
234
235 // if in debug mode, check whether an entry for this column already
236 // exists and if its the same as the one entered at present
237 //
238 // in any case: skip this entry if an entry for this column already
239 // exists, since we don't want to enter it twice
240 for (std::vector >::const_iterator
241col_val_pair = col_val_pairs.begin();
242col_val_pair!=col_val_pairs.end(); ++col_val_pair)
243 {
244 Assert (line != col_val_pair->first,
245 ExcMessage ("Can't constrain a degree of freedom to
itself"));
246
247 for (ConstraintLine::Entries::const_iterator
248p=line_ptr->entries.begin();
249p != line_ptr->entries.end(); ++p)
250 if (p->first == col_val_pair->first)
251 {
252 // entry exists, break innermost loop
253 Assert (p->second == col_val_pair->second,
254 ExcEntryAlreadyExists(line, col_val_pair->first,
255 p->second, col_val_pair->
second));
256 break;
257 }
258
259 line_ptr->entries.push_back (*col_val_pair);
260 }
261 }
Although, it is stated in the comments (lines 235-239) there is no skip of
the entry col_val_pair in the case this entry already exist. The break
command terminates the innermost loop but the push_back operation is
performed nevertheless, i.e. for every element of col_val_pairs. This leads
to duplicates in the constraint matrix.
I solved the problem by just addind the three lines 246a, 255a, 258a.
224 void
225 ConstraintMatrix::add_entries
226 (const size_type line,
227 const std::vector > _val_pairs)
228 {
229 Assert (sorted==false, ExcMatrixIsClosed());
230 Assert (is_constrained(line), ExcLineInexistant(line));
231
232 ConstraintLine *line_ptr = [lines_cache[calculate_line_index(
line)]];
233 Assert (line_ptr->index == line, ExcInternalError());
234
235 // if in debug mode, check whether an entry for this column already
236 // exists and if its the same as the one entered at present
237 //
238 // in any case: skip this entry if an entry for this column already
239 // exists, since we don't want to enter it twice
240 for (std::vector >::const_iterator
241col_val_pair = col_val_pairs.begin();
242col_val_pair!=col_val_pairs.end(); ++col_val_pair)
243 {
244 Assert (line != col_val_pair->first,
245 ExcMessage ("Can't constrain a degree of freedom to
itself"));
246
246a bool entry_exists = false;
247 for (ConstraintLine::Entries::const_iterator
248p=line_ptr->entries.begin();
249p != line_ptr->entries.end(); ++p)
250 if (p->first == col_val_pair->first)
251 {
252 // entry exists, break innermost loop
253 Assert (p->second == col_val_pair->second,
254 ExcEntryAlreadyExists(line, col_val_pair->first,
255 p->second,
col_val_pair->second));
255aentry_exists = true;
256 break;
257 }
258
258a if (entry_exists == fase)
259 line_ptr->entries.push_back (*col_val_pair);
260 }
261 }
May be there is a more elegant way to do this.
Best regards
Dustin
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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 the problem. @ Bruno: Of course you are right. The correct name of the functions is indeed "make_biorthogonal_sparsity_pattern" and not "make_offdiagonal_sparsity_pattern". Sorry for confusing you, but I talked to so many people about this problem and it always arised when filling the offdiagonal blocks of my block matrix that I just mixed up the terms. Concerning your first hint, I'm not quite sure if I understand it correctly. I'm using the function "add_entries" only in combination with the DynamicSparsityPattern and not with the SparsityPattern class. Moreover, it seems that the DynamicSparsityPattern class doesn't even have a "copy_form" function. So I do not really get the point. Best, Dustin -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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 -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. JobId thinkpad-lsx.site Wed Aug 31 11:14:21 2016 setup_intial_fe_distribution, wall time: 0.596235s. DEAL:: DEAL::Memory used by block (0, 0) = 50144 DEAL::Memory used by block (0, 1) = 5904 DEAL::Memory used by block (0, 2) = 180504 DEAL::Memory used by block (1, 0) = 20909304 DEAL::Memory used by block (1, 1) = 344734528 DEAL::Memory used by block (1, 2) = 21246732 DEAL::Memory used by block (2, 0) = 261504 DEAL::Memory used by block (2, 1) = 424332 DEAL::Memory used by block (2, 2) = 86904 DEAL:: DEAL::Nonzero entries: 53353179 DEAL:: copy_sparsity_pattern, wall time: 3772.89s. DEAL:: n_dofs dofhandler_m: 240 n_dofs dofhandler_s: 871215 n_dofs biorthogonal basis: 3615 n_dofs all:875070 setup_system, wall time: 3801.87s. Setup, wall time: 3802.46s. +-+++ | Total wallclock time elapsed since start| 3.81e+03s || | ||| | Section | no. calls | wall time | % of total | +-+---+++ | Setup | 1 | 3.80e+03s |1.e+02% | | copy_sparsity_pattern | 1 | 3.77e+03s | 99.% | | setup_intial_fe_distribution| 1 | 0.596s | 0.016% | | setup_system| 1 | 3.80e+03s |1.e+02% | +-+---+++ JobId thinkpad-lsx.site Wed Aug 31 12:27:00 2016 setup_intial_fe_distribution, wall time: 0.19369s. DEAL:: DEAL::Memory used by block (0, 0) = 50144 DEAL::Memory used by block (0, 1) = 5904 DEAL::Memory used by block (0, 2) = 180504 DEAL::Memory used by block (1, 0) = 20909304 DEAL::Memory used by block (1, 1) = 344734528 DEAL::Memory used by block (1, 2) = 21246732 DEAL::Memory used by block (2, 0) = 261504 DEAL::Memory used by block (2, 1) = 424332 DEAL::Memory used by block (2, 2) = 86904 DEAL:: DEAL::Nonzero entries: 53353179 DEAL:: copy_sparsity_pattern, wall time: 1176.15s. DEAL:: n_dofs dofhandler_m: 240 n_dofs dofhandler_s: 871215 n_dofs biorthogonal basis: 3615 n_dofs all:875070 setup_system, wall time: 1179.94s. Setup, wall time: 1180.14s. +-+++ | Total wallclock time elapsed since start| 1.18e+03s || | ||| | Section | no. calls | wall time | % of total | +-+---+++ | Setup | 1 | 1.18e+03s |1.e+02% | | copy_sparsity_pattern | 1 | 1.18e+03s |1.e+02% | | setup_intial_fe_distribution| 1 | 0.194s | 0.016% | | setup_system| 1 | 1.18e+03s |1.e+02% | +-+---+++
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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 https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. JobId thinkpad-lsx.site Tue Aug 16 12:52:39 2016 setup_intial_fe_distribution, wall time: 0.0151739s. DEAL::Nonzero entries: 6275947 copy_sparsity_pattern, wall time: 0.033499s. DEAL:: n_dofs dofhandler_m: 240 n_dofs dofhandler_s: 131769 n_dofs biorthogonal basis: 1089 n_dofs all:133098 setup_system, wall time: 0.542771s. Setup, wall time: 0.558091s. +-+++ | Total wallclock time elapsed since start| 0.921s || | ||| | Section | no. calls | wall time | % of total | +-+---+++ | Setup | 1 | 0.558s | 61.% | | copy_sparsity_pattern | 1 |0.0335s | 3.6% | | setup_intial_fe_distribution| 1 |0.0152s | 1.6% | | setup_system| 1 | 0.543s | 59.% | +-+---+++ JobId thinkpad-lsx.site Tue Aug 16 12:48:38 2016 setup_intial_fe_distribution, wall time: 0.0675499s. DEAL::Nonzero entries: 6275947 copy_sparsity_pattern, wall time: 0.052773s. DEAL:: n_dofs dofhandler_m: 240 n_dofs dofhandler_s: 131769 n_dofs biorthogonal basis: 1089 n_dofs all:133098 setup_system, wall time: 3.62941s. Setup, wall time: 3.69712s. +-+++ | Total wallclock time elapsed since start| 5.29s || | ||| | Section | no. calls | wall time | % of total | +-+---+++ | Setup | 1 | 3.70s | 70.% | | copy_sparsity_pattern | 1 |0.0528s | 1.0% | | setup_intial_fe_distribution| 1 |0.0675s | 1.3% | | setup_system| 1 | 3.63s | 69.% | +-+---+++
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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 get the number
> of nonzero entries in the dynamic sparsity pattern. This method also exists
> in BlockSparsityPattern (or all sparsity patterns that inherit from
> BlockSparsityPatternBase):
>
> https://dealii.org/developer/doxygen/deal.II/classBlockSparsityPatternBase.html
>
> What I'm trying to understand here is what kind of properties your problem
> has - whether there are many nonzero entries per row and other special
> things that could explain your problems.
>
> I just checked the 3D case of step-22 for the performance of
> BlockSparsityPattern::copy_from(BlockDynamicSparsityPattern) and the
> performance looks where I would expect it to be. It takes 1.19s to copy the
> sparsity pattern for a case with 1.6m DoFs (I have some modifications for
> the mesh compared to what you find online) on my laptop. Given that there
> are 275m nonzero entries in that matrix and I need to touch around 4.4 GB
> (= 4 x 275m x 4 bytes per unsigned int, once for clearing the data in the
> pattern, once for reading in the dynamic pattern, once for writing into the
> fixed pattern plus once for write-allocate on that last operation) of
> memory here, I reach 26% of the theoretical possible on this machine (~14
> GB/s memory transfer per core). While I would know how to reach more than
> 80% of peak memory bandwidth here, this function is no way near being
> relevant in the global run time in any of my performance profiles. And I'm
> likely the deal.II person with most affinity to performance numbers.
>
>
I checked the number of nonzero elements. For 133,098 dofs I got 6,347,893
nonzero elements in the BlockDynamicSparsityPattern and it took me 20.1535s
in Release and 56.5698s in Debug mode respectively to copy them.
> Is there anything else special about your configuration or problem as
> compared to the cases presented in the tutorial? What deal.II version are
> you using, what is the finite element? Any special constraints on those
> systems?
>
The configuration is special in my case. I have got two triangulations to
realize a domain which has more than one hanging node on a face. So I have
two triangulations describing the same geometry and the geometry is
separated in two parts. On the one part I have a quiet coarse mesh and on
the other part I have fine mesh. With the first triangulation I use
trilinear finite elements on the coarse part an FENothing on the finer part
and with the other triangulation I do the same thing vice versa. On the
interface I use Mortar basis functions to connect both parts in a weak
sense. Therefore I have to figure out the interface part first, then find
the corresponding degrees of freedom on the interface and with these
information I create the sparsity patterns for the connection blocks on my
own. This is why my block matrix has 3x3 blocks, the ones belonging to the
first and second triangulation and the connecting one belonging to the
Mortar part.
This is a rough overview concerning the setup situation. If we come to the
conclusion, that this is an important fact, I can explain the whole idea in
more detail. But this will be a lot of lines to write then.
Best regards
Dustin
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct FacePointData
{
unsigned int
master_face_no,
slave_face_no,
master_q_point_index;
dealii::hp::DoFHandler<3>::cell_iterator
master_cell,
slave_cell;
std::vector
slave_face_dofs,
master_face_dofs,
slave_local_face_dofs,
master_local_face_dofs,
biorthogonal_face_dofs;
};
class InterfaceData
{
public:
InterfaceData ();
std::map&
biorthogonal_master_dof_connections ();
std::map&
biorthogonal_slave_dof_connections ();
void
initialise (unsigned int const n_interface_q_points);
std::map&
master_biorthogonal_dof_connections ();
std::vector>&
master_q_points ();
std::map
Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function
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 the dynamic one? How can I get this information? > Have you checked that you do not run out of memory and see a large swap > time? > I'm quiet sure that this is not the case/problem since I used one of our compute servers with 64 GB memory. Moreover, at the moment the program runs with an additional global refinement, i.e. about 16 million dofs and only 33% of the memory is used. Swap isn't used at all. > > How do the run times behave when you choose a smaller problem size? (I > wonder if there is some higher than O(N) complexity somewhere.) > Even in this cases the time needed to copy is comparatively long. I attached a log file wherein the the times are listed for different numbers of dofs. It would be very helpful if you could provide us an example file that > only contains the setup phase so we can investigate the issue further. > Unfortunately this can not be done that easy. I have to reorganize things and kill a lot of superflous code. But besides that, I have a lot of other work to do. May be I can provide you an example file at the end of next week. Best regards, Dustin > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. JobId alliance Thu Jun 23 13:22:53 2016 * * Starting Simulation on Thu, 23.06.2016 at 13:22:53 ** Cycle::0 (Initial mesh) Setup:: ... Setup:setup_intial_fe_distribution:: ... Setup:setup_intial_fe_distribution:Time:: < 1 sec setup_intial_fe_distribution, wall time: 0.000339985s. Setup:setup_system:: ... Setup:setup_system:setup_data:: ... Setup:setup_system:setup_data:detect_contact_interface:: ... Setup:setup_system:setup_data:detect_contact_interface:Time:: < 1 sec Setup:setup_system:setup_data:setup_interface_q_point_data:: ... Setup:setup_system:setup_data:setup_interface_q_point_data:Time:: < 1 sec Setup:setup_system:setup_data:setup_interface_dof_connections:: ... Setup:setup_system:setup_data:setup_interface_dof_connections:Time:: < 1 sec Setup:setup_system:setup_data:Time:: < 1 sec Setup:setup_system:hanging_node_constraints:: ... Setup:setup_system:hanging_node_constraints:Time:: < 1 sec Setup:setup_system:interpolate_boundary_values:: ... Setup:setup_system:interpolate_boundary_values:Time:: < 1 sec Setup:setup_system:reinit_sparsity_pattern:: ... Setup:setup_system:reinit_sparsity_pattern:Time:: < 1 sec Setup:setup_system:make_sparsity_pattern_deal:: ... Setup:setup_system:make_sparsity_pattern_deal:Time:: < 1 sec Setup:setup_system:make_biorthogonal_sparsity_pattern:: ... Setup:setup_system:make_biorthogonal_sparsity_pattern:Time:: < 1 sec Setup:setup_system:copy_sparsity_pattern:: ... Setup:setup_system:copy_sparsity_pattern:Time:: < 1 sec Setup:setup_system:merge_and_close_constraints:: ... Setup:setup_system:merge_and_close_constraints:Time:: < 1 sec Setup:setup_system:Time:: < 1 sec Setup:setup_system:: n_dofs dofhandler_m: 81 n_dofs dofhandler_s: 135 n_dofs biorthogonal basis: 45 n_dofs all:261 setup_system, wall time: 0.00929093s. Setup:: Number of active cells: 24 Setup:: Number of degrees of freedom: 216 Setup:Time:: < 1 sec Setup, wall time: 0.0101869s. Assembling::... Assembling:Time:: < 1 sec Assembling, wall time: 0.00511193s. Solving::... Solving:cg::Starting value 0.130903 Solving:cg::Convergence step 7 value 1.40409e-08 Solving:cg::Starting value 0.103671 Solving:cg::Convergence step 7 value 1.58635e-08 Solving:cg::Starting value 0.0645919 Solving:cg:cg::Starting value 0.00513355 Solving:cg:cg::Convergence step 7 value 1.15629e-09 Solving:cg:cg::Starting value 0.00403430 Solving:cg:cg::Convergence step 7 value 2.42599e-09 Solving:cg:cg::Starting value 0.00101849 Solving:cg:cg::Convergence step 7 value 1.41922e-10 Solving:cg:cg::Starting value 0.000834389 Solving:cg:cg::Convergence step 7 value 5.36044e-10 Solving:cg:cg::Starting value 0.000228587 Solving:cg:cg::Convergence step 7 value 9.29881e-11 Solving:cg:cg::Starting value 0.000295453 Solving:cg:cg::Convergence step 7 value 2.47793e-10 Solving:cg:cg::Starting value 0.000123562 Solving:cg:cg::Convergence step 7 value 3.51006e-11 Solving:cg:cg::Starting value 0.000169932
