Re: [dealii-developers] GUI preprocessor (a priori mesh refinement)

[Denis Davydov]

Hi Bruno,

Thanks, now it works and i have a full deal.II suite built together with 
python part. Yay!

Before starting writing the wrappers, i think we should have some tests for 
export strategy.
I would say the python preprocessor (leave along GUI for now) for mesh 
generation should work with normal triangulation (no MPI).
Then, the user C++ code should be able to read the output together with 
hanging nodes either to dealii::Triangulation or
dealii::p::d::Triangulation in case of MPI run.

Doing something like GridOut.write_msh() and GridOut.read_msh() will not 
work as information about hanging nodes
will not be read in correctly.

As far as i understand it is also not possible to do Triangulation< dim, 
spacedim >::save() and then 
parallel::distributed::Triangulation< dim, spacedim >::load() .

We could of course have different python wrappers for the two classes, but 
then the question is if one can 
save() p::d::Tria with a single MPI core run (from python wrappers) and 
then read it in in C++ code with an arbitrary number of MPI cores?

What do you guys think will be the best way to go around this issue?

Regards,
Denis.


On Wednesday, May 25, 2016 at 9:35:35 PM UTC+2, Bruno Turcksin wrote:
>
> Denis, 
>
> 2016-05-25 10:40 GMT-04:00 Bruno Turcksin  >: 
> > I will let you know once I have fixed the problem. 
> It should work now. 
>
> Best, 
>
> Bruno 
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dealii-developers] suffix in extra test outputs

[Denis Davydov]

Dear all,

I would like to suggest that we add some sensible info into suffix when 
adding
extra test output. For example

fragile_test.output
fragile_test.output.gcc6
fragile_test.ouptut.gcc4
fragile_test.output.clang8-sierra


When we have fragile tests with 3-4 different outputs, it is easier to 
"read" them if the filenames have some hints.
Ideally if the test fails on some system/compiler, one hopefully would have 
a clue whether or not it's because the test is fragile
or there is some problem indeed.

Note that commit messages may not contain any info on rationale why the 
extra outputs were added.
In the long run, i think it's better to document it in both places -- 
commit message and brief info in filename.

Regards,
Denis

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [dealii-developers] MPI_InitFinalize / active_cell_iterator / double free or corruption

[Denis Davydov]

Hi Wolfgang,

Attached is the error log.

Regards,
Denis.

On Tuesday, September 6, 2016 at 11:06:23 AM UTC+2, Wolfgang Bangerth wrote:
>
> Denis 
> Can you post the error message and back trace you get? 
> Best
> Wolfgang
>
>
>  Original message ----
> From: Denis Davydov <davy...@gmail.com > 
> Date:09/06/2016 02:44 (GMT-07:00) 
> To: "deal.II developers" <dealii-d...@googlegroups.com > 
> Subject: [dealii-developers] MPI_InitFinalize / active_cell_iterator / 
> double free or corruption 
>
> Dear all,
>
> I just came across a very interesting problem with (active) cell iterator 
> being used as a member of a class in a library
>
>   template 
>   class Atom
>   {
>   public:
> Atom();
> typename dealii::DoFHandler::active_cell_iterator parent_cell;
>   };
>
>
> This leads to double free or corruption on GCC in Release mode only. 
> The code runs on Clang both in Debug and Release modes.
>
> The prerequisites are as follows (if any of those is not the case, problem 
> disappears!)
> 1. use Utilities::MPI::MPI_InitFinalize  in .cc file
> 2. In the user library, have a default constructor for a class, which 
> contains DoFHandler::active_cell_iterator
> 3. link .cc against the library, do not declare and define the class 
> directly inside .cc
>
> Attached is a one-dummy-class library with a dummy test which demonstrates 
> the issue.
> Using GCC it should be enough to do the normal sequence of : cmake / make 
> / make test
> to see the problem.
>
> Given that DoFHandler::active_cell_iterator has a default constructor,
> I think one should not see a problem with encapsulating this class inside 
> a user class.
>
> It could still be my mistake somewhere, but I squeezed the code so much, 
> that
> I simply fail to see what could be wrong here. Especially given the 
> prerequisites above.
>
> If the attached code turns out to be fine, then we would have to
> (i)  find out the origin of the problem inside deal.II
> (ii) find out how to add a unit test which builds a library and an 
> executable
>
> Regards,
> Denis.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii-develop...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=CwMFaQ=ODFT-G5SujMiGrKuoJJjVg=KkOrCga5IcWjxrpeTIn1nmQG6jJSnwzdZwfNniMeeCc=i0BtibjfmPV3wSHod94Wv66Y54qB8dpYaW_t4TvAry4=0IDCRR_cEHJyCoLRjGPcYRH-Th6EgIXXdjE5Vi7L7ro=>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
$ make test
Running tests...
Test project /home/davydden/libs/init_finalize/_build
Start 1: core/atoms_to_cells_01.debug
1/2 Test #1: core/atoms_to_cells_01.debug .   Passed0.20 sec
Start 2: core/atoms_to_cells_01.release
*** Error in 
`/home/davydden/libs/init_finalize/_build/tests/core/atoms_to_cells_01.release/atoms_to_cells_01.release':
 double free or corruption (!prev): 0x0106f1f0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fa65bc05725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fa65bc0df4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fa65bc11abc]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0x9a)[0x7fa65bbc835a]
/home/davydden/spack/opt/spack/linux-Ubuntu16-x86_64/gcc-5.4.0/dealii-develop-b4u3pdzih7qp3kymzkmtk2msfz6hjyfz/lib/libdeal_II.g.so.8.5.0-pre(+0x20c1a63)[0x7fa647e2aa63]
=== Memory map: 
0040-00403000 r-xp  08:06 6825798
/home/davydden/libs/init_finalize/_build/tests/core/atoms_to_cells_01.release/atoms_to_cells_01.release
00403000-00404000 r--p 2000 08:06 6825798
/home/davydden/libs/init_finalize/_build/tests/core/atoms_to_cells_01.release/atoms_to_cells_01.release
00404000-00405000 rw-p 3000 08:06 6825798
/home/davydden/libs/init_finalize/_build/tests/core/atoms_to_cells_01.release/atoms_to_cells_01.release
00e4c000-0118c000 rw-p  00:00 0  [heap]
7fa61000-7fa610021000 rw-p  00:00 0 
7fa610021000-7fa61400 ---p  00:00 0 
7fa61800-7fa618021000 rw-p  00:00 0 
7fa618021000-7fa61c00 ---p  00:00 0 
7fa61f42d000-7fa62142d000 rw-p  00:00 0 
7fa62142d000-7fa62162d000 rw-p  00:00 0 
7fa62162d000-7

[dealii-developers] MPI_InitFinalize / active_cell_iterator / double free or corruption

[Denis Davydov]

Dear all,

I just came across a very interesting problem with (active) cell iterator 
being used as a member of a class in a library

  template 
  class Atom
  {
  public:
Atom();
typename dealii::DoFHandler::active_cell_iterator parent_cell;
  };


This leads to double free or corruption on GCC in Release mode only. 
The code runs on Clang both in Debug and Release modes.

The prerequisites are as follows (if any of those is not the case, problem 
disappears!)
1. use Utilities::MPI::MPI_InitFinalize  in .cc file
2. In the user library, have a default constructor for a class, which 
contains DoFHandler::active_cell_iterator
3. link .cc against the library, do not declare and define the class 
directly inside .cc

Attached is a one-dummy-class library with a dummy test which demonstrates 
the issue.
Using GCC it should be enough to do the normal sequence of : cmake / make / 
make test
to see the problem.

Given that DoFHandler::active_cell_iterator has a default constructor,
I think one should not see a problem with encapsulating this class inside a 
user class.

It could still be my mistake somewhere, but I squeezed the code so much, 
that
I simply fail to see what could be wrong here. Especially given the 
prerequisites above.

If the attached code turns out to be fine, then we would have to
(i)  find out the origin of the problem inside deal.II
(ii) find out how to add a unit test which builds a library and an 
executable

Regards,
Denis.

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


init_finalize.tar.gz
Description: Binary data

Re: [dealii-developers] MPI_InitFinalize / active_cell_iterator / double free or corruption

[Denis Davydov]

I have good news and bad news. Good news is that I found where the problem 
lies.
Bad news -- it's deal.II@master. 
I did two fresh builds of deal.II on Ubuntu with Candi -- one 8.4.1 and one 
@master.
8.4.1 runs fine, @master gives this ugly error. 

Bisection in process...


On Tuesday, September 6, 2016 at 11:19:17 AM UTC+2, Denis Davydov wrote:
>
> Hi Wolfgang,
>
> Attached is the error log.
>
> Regards,
> Denis.
>
> On Tuesday, September 6, 2016 at 11:06:23 AM UTC+2, Wolfgang Bangerth 
> wrote:
>>
>> Denis 
>> Can you post the error message and back trace you get? 
>> Best
>> Wolfgang
>>
>>
>>  Original message 
>> From: Denis Davydov <davy...@gmail.com> 
>> Date:09/06/2016 02:44 (GMT-07:00) 
>> To: "deal.II developers" <dealii-d...@googlegroups.com> 
>> Subject: [dealii-developers] MPI_InitFinalize / active_cell_iterator / 
>> double free or corruption 
>>
>> Dear all,
>>
>> I just came across a very interesting problem with (active) cell iterator 
>> being used as a member of a class in a library
>>
>>   template 
>>   class Atom
>>   {
>>   public:
>> Atom();
>> typename dealii::DoFHandler::active_cell_iterator parent_cell;
>>   };
>>
>>
>> This leads to double free or corruption on GCC in Release mode only. 
>> The code runs on Clang both in Debug and Release modes.
>>
>> The prerequisites are as follows (if any of those is not the case, 
>> problem disappears!)
>> 1. use Utilities::MPI::MPI_InitFinalize  in .cc file
>> 2. In the user library, have a default constructor for a class, which 
>> contains DoFHandler::active_cell_iterator
>> 3. link .cc against the library, do not declare and define the class 
>> directly inside .cc
>>
>> Attached is a one-dummy-class library with a dummy test which 
>> demonstrates the issue.
>> Using GCC it should be enough to do the normal sequence of : cmake / make 
>> / make test
>> to see the problem.
>>
>> Given that DoFHandler::active_cell_iterator has a default 
>> constructor,
>> I think one should not see a problem with encapsulating this class inside 
>> a user class.
>>
>> It could still be my mistake somewhere, but I squeezed the code so much, 
>> that
>> I simply fail to see what could be wrong here. Especially given the 
>> prerequisites above.
>>
>> If the attached code turns out to be fine, then we would have to
>> (i)  find out the origin of the problem inside deal.II
>> (ii) find out how to add a unit test which builds a library and an 
>> executable
>>
>> Regards,
>> Denis.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "deal.II developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dealii-develop...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=CwMFaQ=ODFT-G5SujMiGrKuoJJjVg=KkOrCga5IcWjxrpeTIn1nmQG6jJSnwzdZwfNniMeeCc=i0BtibjfmPV3wSHod94Wv66Y54qB8dpYaW_t4TvAry4=0IDCRR_cEHJyCoLRjGPcYRH-Th6EgIXXdjE5Vi7L7ro=>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [dealii-developers] Re: Python bindings

[Denis Davydov]

Hi Rene,

> On 18 Nov 2016, at 09:43, rene.m...@gmail.com wrote:

> Hi Denis,
> 
> thanks for the info. Those bindings cover a different subset than what I did, 
> so I'll be keeping mine for the time being. If anybody wants to take a look 
> and talk about integrating them upstream at some point it'd be very open to 
> that.

I guess nobody will mind if you contribute them upstream ;-) 
It does not have to be all-at-once, maybe just start with a small part of what 
you did, create a PR and then we can discuss it within a PR interface 
https://github.com/dealii/dealii/pulls .

Regards,
Denis.

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dealii-developers] Re: automated bulk github issue creation

[Denis Davydov]

One could probably break the PVS report into a big TODO list and then check 
items once someone
addresses a part of the big issue.

Another option is to break them into comments and then one can link to a 
comment
inside PVS issue, but this would quickly render issue page unusable.

>From my point of view -- both are worse than scripting separate sub-issues. 
E-mails can be deleted and issues which are closed don't obscure the view
of opened issues.

Cheers,
Denis.


On Friday, November 11, 2016 at 10:24:41 PM UTC+1, Timo Heister wrote:
>
> Hey all, 
>
> while I am very happy to see many static analysis problems to be 
> reported and fixed, I would like to discuss the bulk creation of 
> github issues that has happened over the last weeks. 
>
> I feel these create unnecessary noise (when browsing issues and in our 
> email inboxes) that makes it difficult to look at other pullrequests 
> and issues and as such waste time. I also don't see an advantage over 
> having a single issue and partially addressing it if it is too much 
> work to tackle them in a single PR. 
>
> Thoughts? 
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [dealii-developers] use Github Projects feature

[Denis Davydov]

On Friday, October 14, 2016 at 2:31:08 AM UTC+2, Matthias Maier wrote:
>
> On Thu, Oct 13, 2016, at 15:59 CDT, Denis Davydov <davy...@gmail.com 
> > wrote: 
>
> Ps.: Denis, I am disappointed. You forgot to mention the most important 
> feature. You can add emoticons to comments of others :-P 
>

You will be surprised, but there is a reason for me not mentioning it 
it is not a part of September updated :-

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dealii-developers] do_vectorized() in struct Dot and alike for shared memory parallel reduction

[Denis Davydov]

Hi All,

I was digging around lac/vectorized_operations_internal.h 

 
and noticed that objects that are used in SIMD to do reduction are of the 
form:

template 

  struct Dot
  {
VectorizedArray
do_vectorized(const size_type i) const
{
  VectorizedArray x, y;
  x.load(X+i);
  y.load(Y+i);
  return x * y;
}

const Number  *X;

const Number2 *Y;
 }

which are used like

VectorizedArray r0 = op.do_vectorized(index);
VectorizedArray r1 = op.do_vectorized(index+nvecs);
VectorizedArray r2 = op.do_vectorized(index+2*nvecs);
VectorizedArray r3 = op.do_vectorized(index+3*nvecs);

where 

const unsigned int nvecs = VectorizedArray::n_array_elements;


I wonder should not declarations be moved to the class variable as *mutable*
?
I don't know internals of VectorizedArray, but i would assume that 
currently it allocates memory for the two variables on each call to 
do_vectorized(),
which would not be the case otherwise.

Regards,
Denis.

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.