Re: [deal.II] segmentation fault when calling make_vectorized_array

2017-07-12 Thread Denis Davydov 
Hi Martin,

On Wednesday, July 12, 2017 at 6:05:30 PM UTC+2, Martin Kronbichler wrote:
>
> Hi Denis,
>
> what is a? Is it an element of an array? If yes, is the array of type 
> AlignedVector (or derived from that). 
>

no, it's just a member variable VectorizedArray: 

VectorizedArray a;

 

> You get this kind of error when there is a load or store to an address 
> that is not aligned by the size of the vectorized array, 32 bytes in your 
> case. The data types VectorizedArray make the compiler insert 'aligned 
> load/store' type of operations, which cannot always be guaranteed.
>
> Can you try to look at the problem in a debugger, e.g. gdb and post the 
> offending assembler line and a few before that to see the context?
>

here they are:

0x773913b1 ::Operator()+9> 
   mov%rdi,%rbx 
   │0x773913b4 ::Operator()+12>   callq  0x771d1f90 
<_ZN6dealii19MatrixFreeOperators4BaseILi3ENS_13LinearAlgebra11distributed6VectorIfEEEC2Ev@plt
   │0x773913b9 ::Operator()+17>   mov0x9ecd60(%rip),%rax# 0x77d7e120 
 
   │0x773913c0 ::Operator()+24>   lea0x10(%rax),%rax  
   │0x773913c4 ::Operator()+28>   mov%rax,(%rbx)  
   │0x773913c7 ::Operator()+31>   vxorps %xmm0,%xmm0,%xmm0
  >│0x773913cb ::Operator()+35>   vmovaps %ymm0,0xe0(%rbx)
   │0x773913d3 ::Operator()+43>   vmovaps 0x64ffc5(%rip),%ymm0# 0x779e13a0
   │0x773913db ::Operator()+51>   vmovaps %ymm0,0x100(%rbx)   
   │0x773913e3 ::Operator()+59>   mov-0x8(%rbp),%rbx 
   │0x773913e7 ::Operator()+63>   leaveq   
   │0x773913e8 ::Operator()+64>   retq

(I did a few replacement to ease the readability). Hopefully you can make 
sense out of it. 

Regards,
Denis. 

-- 
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] segmentation fault when calling make_vectorized_array

2017-07-12 Thread Martin Kronbichler 

Hi Denis,

what is a? Is it an element of an array? If yes, is the array of type 
AlignedVector (or derived from that).


You get this kind of error when there is a load or store to an address 
that is not aligned by the size of the vectorized array, 32 bytes in 
your case. The data types VectorizedArray make the compiler insert 
'aligned load/store' type of operations, which cannot always be guaranteed.


Can you try to look at the problem in a debugger, e.g. gdb and post the 
offending assembler line and a few before that to see the context?


Best,
Martin


On 12.07.2017 17:41, Denis Davydov wrote:

Hi all,

With the current master (182e974) I get a weird segmentation fault for 
*float* numbers when calling


|
 a =make_vectorized_array(0.);
|

inside a constructor of my class where

|
VectorizedArraya;
|

I see this only on a cluster (Intel Xeon Ivy Bridge), deal.II is 
compiled with *-march=native* with GCC 4.8.5 in Debug mode (obviously 
segmentation fault is there in Release as well).


Unfortunately, I wiped the old (working) installation and can't check 
it now,

but I think this used to work with *-march=native* a few months back.

Relevant config tests are:

|
--PerformingTestDEAL_II_HAVE_SSE2
--PerformingTestDEAL_II_HAVE_SSE2 -Success
--PerformingTestDEAL_II_HAVE_AVX
--PerformingTestDEAL_II_HAVE_AVX -Success
--PerformingTestDEAL_II_HAVE_AVX512
--PerformingTestDEAL_II_HAVE_AVX512 -Failed
--PerformingTestDEAL_II_HAVE_OPENMP_SIMD
--PerformingTestDEAL_II_HAVE_OPENMP_SIMD -Failed
|

If I try to replicate what *make_vectorized_array* does, then it works 
fine whereas calling it gives segfault:


|
constvalue_type u =0.;
VectorizedArrayresult;
  result =u;
// ^^ copy paste of make_vectorized_array
  a =u;
VectorizedArraydummy =make_vectorized_array(0.);// <- 
quick test for doubles
  a =make_vectorized_array(0.);<=Segmentationfault 
here!

|

I am puzzled with this... Any ideas where to dig?

Cheers,
Denis
--
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.


--
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] step-40. petsc with openmp

2017-07-12 Thread Kartik Jujare 
Thank you for the answer

Regards,
Kartik

On Tuesday, July 11, 2017 at 5:53:48 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 07/11/2017 08:33 AM, Kartik Jujare wrote: 
> > 
> > Does this still hold true of the Petsc wrappers not being thread-safe? 
>
> Yes. But it's not the wrappers that are the problem, it's that PETSc 
> itself is 
> not thread safe. 
>
> 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.

Re: [deal.II] Best approach for multi-variable system with multiple grids

2017-07-12 Thread 'Maxi Miller' via deal.II User Group 
I know that both components will behave quite differently, thus I assumed 
that I have to use two grids. In addition I was interested in how both 
parameters evolve over time. If I need only one grid, then I still have to 
store them separately, but it would be closer to example 33, wouldn't it?

Am Dienstag, 11. Juli 2017 22:22:39 UTC+2 schrieb Wolfgang Bangerth:
>
> On 07/11/2017 08:29 AM, 'Maxi Miller' via deal.II User Group wrote: 
> > Which of those two approaches is more beneficial for me (especcially 
> after I 
> > would like to extend it afterwards to two additional equations? Or is 
> there 
> > another approach I did not consider yet? 
>
> I don't think I quite understand your two options, but in any case: What 
> is 
> the reason why you need two different meshes? Is the qualitative behavior 
> of 
> the two variables vastly different? Unless the diffusion constants for the 
> two 
> variables is vastly different, there is usually no particularly good 
> reason to 
> use different meshes. 
>
> 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.