Re: Re: [deal.II] global dof renumbering with parallel triangulation and trilinos direct solver (Bug ?)

[Denis Davydov]

FYI, I created a GitHub issue to further track this 
problem: https://github.com/dealii/dealii/issues/2966

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] Question concerning BlockSparsityPattern.copy_from() member function

[Dustin Kumor]

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&
master_slave_dof_connections ();

unsigned int
n_cells_master ();

unsigned int
n_cells_slave ();

unsigned int
ndofs_biorthogonal ();

std::vector&
q_point_data ();

void

Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function

[Martin Kronbichler]

Dear Dustin,

I had a look at your program on my machine with the most recent 
development version of deal.II. Here is the final timer output in 
release mode:


+-+++
| Total wallclock time elapsed since start| 1.02s ||
| |||
| Section | no. calls |  wall time | % of total |
+-+---+++
| Setup   | 1 | 0.618s |   60.% |
| copy_sparsity_pattern   | 1 | 0.0557s |   5.4% |
| setup_intial_fe_distribution| 1 | 0.0119s |   1.2% |
| setup_system| 1 | 0.606s |   59.% |
+-+---+++

As you can see, the copy operation is very cheap on my machine at 
0.0557s versus 20.2s on your machine. When looking at the profiles, I 
cannot see anything suspicious either. My primary suspecion right now is 
that you are on an old version of deal.II where we had bad code in that 
function. (But I don't remember having changed anything during the last 
year.) What version are you using?


Best,
Martin

--
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] error when trying to initialize PETSc preconditioners

[Ignacio Tomas]

Timo:

Simple question: basically, now I have to download the new file
''include/deal.II/lac/petsc_precondition.h'' from the repository, replace
it in my dealii source code and recompile deal, that should do the trick?

Ignacio.

On Sun, Aug 14, 2016 at 8:02 PM, Timo Heister  wrote:

> Thanks, this should fix it: https://github.com/dealii/dealii/pull/2963
>
> On Sat, Aug 13, 2016 at 5:28 PM, Ignacio Tomas  wrote:
> > This is the whole error message
> >
> >
> >
> >
> >
> > terminate called after throwing an instance of
> > 'dealii::StandardExceptions::ExcInvalidState'
> >   what():
> > 
> > An error occurred in line <68> of file
> >  lac/petsc_precondition.cc>
> > in function
> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
> > The violated condition was:
> > pc == NULL
> > The name and call sequence of the exception was:
> > StandardExceptions::ExcInvalidState ()
> > Additional Information:
> > (none)
> > 
> >
> > [nachote:11234] *** Process received signal ***
> > [nachote:11234] Signal: Aborted (6)
> > [nachote:11234] Signal code:  (-6)
> > [nachote:11234] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)
> > [0x7f0cacb08d10]
> > [nachote:11234] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)
> > [0x7f0cac14c267]
> > [nachote:11234] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)
> > [0x7f0cac14deca]
> > [nachote:11234] [ 3]
> > /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_
> cxx27__verbose_terminate_handlerEv+0x16d)
> > [0x7f0cac84a06d]
> > [nachote:11234] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5eee6)
> > [0x7f0cac847ee6]
> > [nachote:11234] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ef31)
> > [0x7f0cac847f31]
> > [nachote:11234] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f149)
> > [0x7f0cac848149]
> > [nachote:11234] [ 7]
> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii18deal_II_exceptions9internals11issue_
> errorINS_18StandardExceptions15ExcInvalidStateEEEvNS1_
> 17ExceptionHandlingEPKciS7_S7_S7_T_+0x84)
> > [0x7f0cb0a182d4]
> > [nachote:11234] [ 8]
> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers18Prec
> onditionerBase9create_pcEv+0xf9)
> > [0x7f0cb2a72689]
> > [nachote:11234] [ 9]
> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers23Prec
> onditionBlockJacobi10initializeERKNS0_10MatrixBaseERKNS1_
> 14AdditionalDataE+0x34)
> > [0x7f0cb2a742c4]
> > [nachote:11234] [10]
> > ./main(_ZN8PsystemsILi1EE26initialize_preconditionersEv+0x2c) [0x46536c]
> > [nachote:11234] [11]
> > ./main(_ZN8PsystemsILi1EE23timeloopSSP2EVnotlumpedEv+0x36) [0x43ca76]
> > [nachote:11234] [12] ./main(_ZN8PsystemsILi1EE14validation_runEv+0x356)
> > [0x43d376]
> > [nachote:11234] [13] ./main(main+0x55) [0x4354c5]
> > [nachote:11234] [14] /lib/x86_64-linux-gnu/libc.so.
> 6(__libc_start_main+0xf0)
> > [0x7f0cac137a40]
> > [nachote:11234] [15] ./main(_start+0x29) [0x4356f9]
> > [nachote:11234] *** End of error message ***
> > CMakeFiles/run.dir/build.make:49: recipe for target 'CMakeFiles/run'
> failed
> > make[3]: *** [CMakeFiles/run] Aborted (core dumped)
> > CMakeFiles/Makefile2:130: recipe for target 'CMakeFiles/run.dir/all'
> failed
> > make[2]: *** [CMakeFiles/run.dir/all] Error 2
> > CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule'
> failed
> > make[1]: *** [CMakeFiles/run.dir/rule] Error 2
> > Makefile:136: recipe for target 'run' failed
> > make: *** [run] Error 2
> >
> >
> >
> > Clearly you can see that the error happens at
> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
> >
> >
> >
> > On Sat, Aug 13, 2016 at 12:03 PM, Timo Heister 
> wrote:
> >>
> >> > and stops again with a
> >> > error when I make the call to initialize for the second time which is
> >> > expected since ''initialize()'' can only be called once.
> >>
> >> I would hope that calling initialize() more than once works. What is
> >> the error you are getting?
> >>
> >>
> >> --
> >> Timo Heister
> >> http://www.math.clemson.edu/~heister/
> >>
> >> --
> >> 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 a topic in the
> >> Google Groups "deal.II User Group" group.
> >> To unsubscribe from this topic, visit
> >> https://groups.google.com/d/topic/dealii/NiShx850REE/unsubscribe.
> >> To unsubscribe from this group and all its topics, 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/deal

[deal.II] Re: Data exchanges in IO

[bjpalmer58]

On Friday, August 12, 2016 at 4:05:33 PM UTC-7, Daniel Arndt wrote:
>
> Bruce,
>  
>  
>
>> The p_local_solution vector is filled with values as the result of 
>> solving a linear equation, p_local_rho is filled with values by looping 
>> over individual elements and assigning values calculated from other 
>> quantities. Part of the reason the p_local_rho vector doesn't have ghost 
>> nodes is that you can't access individual elements for a ghosted vector.
>>
> You can't write to a ghosted vector, but you can read from it. Is this 
> what you mean?
>

My impression was that you can use the [] operator on ghosted vector, 
i.e. using something like p_local_solution[i] (for a ghosted 
vector) in either an access or assignment statement throws and error. 
Although, now that I'm looking through the code with fresh eyes, it looks 
like p_local_solution(i) does work, at least for accesses.

The DataOut object appears to only handle ghosted vectors. It also appears 
>> that you need to call ompress on non-ghosted vectors (this was determined 
>> empirically based on error messages). 
>>
> Yes, for proper output you should use ghosted vectors that store the 
> solution on all the dofs of locally owned cells. If you modify a parallel 
> vector you have to call compress as mentioned in step-40 [1] for example. 
> Would you want to have this information at some different place as well. If 
> yes, where?
>

I guess I was under the impression that you only had to do compress on a 
ghosted vector, but I'm not sure where I got that idea. I think it might be 
useful to have a general description of distributed vectors that clarifies 
ghosted/non-ghosted, what happens when you call compress for 
both ghosted/non-ghosted vectors (and what is happening when you choose 
insert versus add), and how you can trigger a ghost element update. The 
exact role of compress is hard to fathom, since if you already have a 
distributed vector without ghost cells and you modify local elements, it is 
hard to see what else needs to happen before the vector is ready for use 
(maybe just get rid of an internal flag that marks the vector as 
"modified"?). Also, I seem to run into problems where I could call compress 
with an insert argument, but not an add argument. Again, it is not clear to 
me what the distinction is. The current documentation says:

In short, you need to call compress() in the following cases (and only in 
those cases, though calling compress() in other cases just costs some 
performance):

   1. At the end of your assembly loop on matrices and vectors. This needs 
   to be done if you write entries directly or if you use 
   *ConstraintMatrix::distribute_local_to_global* 
   
.
 
   Use VectorOperation::add.
   2. When you are done setting individual elements in a matrix/vector 
   before any other operations are done (adding to elements, other operations 
   like scaling, solving, reading, etc.). Use VectorOperation::insert.
   3. Like in 2., but for adding values to individual elements. Use 
   VectorOperation::add.

I guess 3) is obscure. Does this mean that you are adding a new element 
where none existed before or that you are incrementing an existing element? 
If the former, aren't the total number of elements in a vector specified 
when you declare the vector size so how do you add more elements?

I'm not sure I have any great ideas about where to put this. Adding a 
section to the glossary under "Distributed Vectors and Matrices" might be 
one possibility. Another might be to create a standalone document on 
Distributed Data Structures for Parallel Computing that could give an 
overview of the DEAL II parallel programming model


 

> The vecScale function is just designed to multiply all values of an 
>> un-ghosted vector by a constant. 
>>
> You could also use operator*= [2] for this.
>

Using this function seems to solve the problem. Not sure why the other 
version doesn't work, but this does the trick.

If you don't change the values of the vectors using vecScale then the data 
>> for "Phi" and "Rho" appears smooth (but the scale is unwieldy). If you 
>> change the values of the vectors using vecScale, then "Phi" looks okay but 
>> "Rho" appears to have unscaled values at locations that look like they are 
>> at processor boundaries. I'm puzzled about how this is happening, since my 
>> understanding is that a data exchange happens when you do the assignment 
>> rho = p_local_rho. The vecScale function only operates on un-ghosted 
>> vectors, but is it possible that it is missing some values somewhere?
>>
> This sounds weird as you do the exact same thing to (rho, p_local_rho) and 
> (p_local_solution, phi). So you observe that p_local_solution looks wrong 
> as well? Do you have a minimal working example showing this problem?
>

The results coming from p_local_solution look good (smooth) and appear to 
h

Re: [deal.II] error when trying to initialize PETSc preconditioners

[Timo Heister]

Yes, or you wait another 2 hours (then it should be merged) and just
pull the latest development version from github.

On Mon, Aug 15, 2016 at 2:34 PM, Ignacio Tomas  wrote:
> Timo:
>
> Simple question: basically, now I have to download the new file
> ''include/deal.II/lac/petsc_precondition.h'' from the repository, replace it
> in my dealii source code and recompile deal, that should do the trick?
>
> Ignacio.
>
> On Sun, Aug 14, 2016 at 8:02 PM, Timo Heister  wrote:
>>
>> Thanks, this should fix it: https://github.com/dealii/dealii/pull/2963
>>
>> On Sat, Aug 13, 2016 at 5:28 PM, Ignacio Tomas  wrote:
>> > This is the whole error message
>> >
>> >
>> >
>> >
>> >
>> > terminate called after throwing an instance of
>> > 'dealii::StandardExceptions::ExcInvalidState'
>> >   what():
>> > 
>> > An error occurred in line <68> of file
>> >
>> > 
>> > in function
>> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
>> > The violated condition was:
>> > pc == NULL
>> > The name and call sequence of the exception was:
>> > StandardExceptions::ExcInvalidState ()
>> > Additional Information:
>> > (none)
>> > 
>> >
>> > [nachote:11234] *** Process received signal ***
>> > [nachote:11234] Signal: Aborted (6)
>> > [nachote:11234] Signal code:  (-6)
>> > [nachote:11234] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)
>> > [0x7f0cacb08d10]
>> > [nachote:11234] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)
>> > [0x7f0cac14c267]
>> > [nachote:11234] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)
>> > [0x7f0cac14deca]
>> > [nachote:11234] [ 3]
>> >
>> > /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x16d)
>> > [0x7f0cac84a06d]
>> > [nachote:11234] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5eee6)
>> > [0x7f0cac847ee6]
>> > [nachote:11234] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ef31)
>> > [0x7f0cac847f31]
>> > [nachote:11234] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f149)
>> > [0x7f0cac848149]
>> > [nachote:11234] [ 7]
>> >
>> > /home/nachotex/Documents/deal/deal/dealii841installation/lib/libdeal_II.so.8.4.1(_ZN6dealii18deal_II_exceptions9internals11issue_errorINS_18StandardExceptions15ExcInvalidStateEEEvNS1_17ExceptionHandlingEPKciS7_S7_S7_T_+0x84)
>> > [0x7f0cb0a182d4]
>> > [nachote:11234] [ 8]
>> >
>> > /home/nachotex/Documents/deal/deal/dealii841installation/lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers18PreconditionerBase9create_pcEv+0xf9)
>> > [0x7f0cb2a72689]
>> > [nachote:11234] [ 9]
>> >
>> > /home/nachotex/Documents/deal/deal/dealii841installation/lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers23PreconditionBlockJacobi10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE+0x34)
>> > [0x7f0cb2a742c4]
>> > [nachote:11234] [10]
>> > ./main(_ZN8PsystemsILi1EE26initialize_preconditionersEv+0x2c) [0x46536c]
>> > [nachote:11234] [11]
>> > ./main(_ZN8PsystemsILi1EE23timeloopSSP2EVnotlumpedEv+0x36) [0x43ca76]
>> > [nachote:11234] [12] ./main(_ZN8PsystemsILi1EE14validation_runEv+0x356)
>> > [0x43d376]
>> > [nachote:11234] [13] ./main(main+0x55) [0x4354c5]
>> > [nachote:11234] [14]
>> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)
>> > [0x7f0cac137a40]
>> > [nachote:11234] [15] ./main(_start+0x29) [0x4356f9]
>> > [nachote:11234] *** End of error message ***
>> > CMakeFiles/run.dir/build.make:49: recipe for target 'CMakeFiles/run'
>> > failed
>> > make[3]: *** [CMakeFiles/run] Aborted (core dumped)
>> > CMakeFiles/Makefile2:130: recipe for target 'CMakeFiles/run.dir/all'
>> > failed
>> > make[2]: *** [CMakeFiles/run.dir/all] Error 2
>> > CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule'
>> > failed
>> > make[1]: *** [CMakeFiles/run.dir/rule] Error 2
>> > Makefile:136: recipe for target 'run' failed
>> > make: *** [run] Error 2
>> >
>> >
>> >
>> > Clearly you can see that the error happens at
>> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
>> >
>> >
>> >
>> > On Sat, Aug 13, 2016 at 12:03 PM, Timo Heister 
>> > wrote:
>> >>
>> >> > and stops again with a
>> >> > error when I make the call to initialize for the second time which is
>> >> > expected since ''initialize()'' can only be called once.
>> >>
>> >> I would hope that calling initialize() more than once works. What is
>> >> the error you are getting?
>> >>
>> >>
>> >> --
>> >> Timo Heister
>> >> http://www.math.clemson.edu/~heister/
>> >>
>> >> --
>> >> 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 a topic in the
>> >> Google Groups "deal.II User Group" group.
>> >> To unsubscribe from this topic, visit
>> >> https://groups.google.com/d/topic/dealii/NiShx850REE/unsubscribe.
>> >> To unsubscribe from this group and all its topics, sen

Re: [deal.II] error when trying to initialize PETSc preconditioners

[Ignacio Tomas]

Great! Many thanks for solving this problem. I owe at least a lunch.

On Mon, Aug 15, 2016 at 3:25 PM, Timo Heister  wrote:

> Yes, or you wait another 2 hours (then it should be merged) and just
> pull the latest development version from github.
>
> On Mon, Aug 15, 2016 at 2:34 PM, Ignacio Tomas  wrote:
> > Timo:
> >
> > Simple question: basically, now I have to download the new file
> > ''include/deal.II/lac/petsc_precondition.h'' from the repository,
> replace it
> > in my dealii source code and recompile deal, that should do the trick?
> >
> > Ignacio.
> >
> > On Sun, Aug 14, 2016 at 8:02 PM, Timo Heister 
> wrote:
> >>
> >> Thanks, this should fix it: https://github.com/dealii/dealii/pull/2963
> >>
> >> On Sat, Aug 13, 2016 at 5:28 PM, Ignacio Tomas 
> wrote:
> >> > This is the whole error message
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > terminate called after throwing an instance of
> >> > 'dealii::StandardExceptions::ExcInvalidState'
> >> >   what():
> >> > 
> >> > An error occurred in line <68> of file
> >> >
> >> >  lac/petsc_precondition.cc>
> >> > in function
> >> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
> >> > The violated condition was:
> >> > pc == NULL
> >> > The name and call sequence of the exception was:
> >> > StandardExceptions::ExcInvalidState ()
> >> > Additional Information:
> >> > (none)
> >> > 
> >> >
> >> > [nachote:11234] *** Process received signal ***
> >> > [nachote:11234] Signal: Aborted (6)
> >> > [nachote:11234] Signal code:  (-6)
> >> > [nachote:11234] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)
> >> > [0x7f0cacb08d10]
> >> > [nachote:11234] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)
> >> > [0x7f0cac14c267]
> >> > [nachote:11234] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)
> >> > [0x7f0cac14deca]
> >> > [nachote:11234] [ 3]
> >> >
> >> > /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_
> cxx27__verbose_terminate_handlerEv+0x16d)
> >> > [0x7f0cac84a06d]
> >> > [nachote:11234] [ 4] /usr/lib/x86_64-linux-gnu/
> libstdc++.so.6(+0x5eee6)
> >> > [0x7f0cac847ee6]
> >> > [nachote:11234] [ 5] /usr/lib/x86_64-linux-gnu/
> libstdc++.so.6(+0x5ef31)
> >> > [0x7f0cac847f31]
> >> > [nachote:11234] [ 6] /usr/lib/x86_64-linux-gnu/
> libstdc++.so.6(+0x5f149)
> >> > [0x7f0cac848149]
> >> > [nachote:11234] [ 7]
> >> >
> >> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii18deal_II_exceptions9internals11issue_
> errorINS_18StandardExceptions15ExcInvalidStateEEEvNS1_
> 17ExceptionHandlingEPKciS7_S7_S7_T_+0x84)
> >> > [0x7f0cb0a182d4]
> >> > [nachote:11234] [ 8]
> >> >
> >> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers18Prec
> onditionerBase9create_pcEv+0xf9)
> >> > [0x7f0cb2a72689]
> >> > [nachote:11234] [ 9]
> >> >
> >> > /home/nachotex/Documents/deal/deal/dealii841installation/
> lib/libdeal_II.so.8.4.1(_ZN6dealii13PETScWrappers23Prec
> onditionBlockJacobi10initializeERKNS0_10MatrixBaseERKNS1_
> 14AdditionalDataE+0x34)
> >> > [0x7f0cb2a742c4]
> >> > [nachote:11234] [10]
> >> > ./main(_ZN8PsystemsILi1EE26initialize_preconditionersEv+0x2c)
> [0x46536c]
> >> > [nachote:11234] [11]
> >> > ./main(_ZN8PsystemsILi1EE23timeloopSSP2EVnotlumpedEv+0x36) [0x43ca76]
> >> > [nachote:11234] [12] ./main(_ZN8PsystemsILi1EE14validation_
> runEv+0x356)
> >> > [0x43d376]
> >> > [nachote:11234] [13] ./main(main+0x55) [0x4354c5]
> >> > [nachote:11234] [14]
> >> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)
> >> > [0x7f0cac137a40]
> >> > [nachote:11234] [15] ./main(_start+0x29) [0x4356f9]
> >> > [nachote:11234] *** End of error message ***
> >> > CMakeFiles/run.dir/build.make:49: recipe for target 'CMakeFiles/run'
> >> > failed
> >> > make[3]: *** [CMakeFiles/run] Aborted (core dumped)
> >> > CMakeFiles/Makefile2:130: recipe for target 'CMakeFiles/run.dir/all'
> >> > failed
> >> > make[2]: *** [CMakeFiles/run.dir/all] Error 2
> >> > CMakeFiles/Makefile2:138: recipe for target 'CMakeFiles/run.dir/rule'
> >> > failed
> >> > make[1]: *** [CMakeFiles/run.dir/rule] Error 2
> >> > Makefile:136: recipe for target 'run' failed
> >> > make: *** [run] Error 2
> >> >
> >> >
> >> >
> >> > Clearly you can see that the error happens at
> >> > void dealii::PETScWrappers::PreconditionerBase::create_pc()
> >> >
> >> >
> >> >
> >> > On Sat, Aug 13, 2016 at 12:03 PM, Timo Heister 
> >> > wrote:
> >> >>
> >> >> > and stops again with a
> >> >> > error when I make the call to initialize for the second time which
> is
> >> >> > expected since ''initialize()'' can only be called once.
> >> >>
> >> >> I would hope that calling initialize() more than once works. What is
> >> >> the error you are getting?
> >> >>
> >> >>
> >> >> --
> >> >> Timo Heister
> >> >> http://www.math.clemson.edu/~heister/
> >> >>
> >> >> --
> >> >> The deal.II project is lo

Re: [deal.II] error when trying to initialize PETSc preconditioners

[Wolfgang Bangerth]

On 08/15/2016 02:46 PM, Ignacio Tomas wrote:

Great! Many thanks for solving this problem. I owe at least a lunch.


Ah, now I'm jealous I left this easy to fix bug to Timo! ;-)

Cheers
 W.

--

Wolfgang Bangerth  email: bange...@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] Re: Derivative of a scalar function in the code

[Daniel Arndt]

Benhour,

What exactly is your problem? Lots of the examples programs, i.e. step-14, 
step-15, step-18, step-31, step-32, step-35, step-43 and step-44, use 
FEValues::get_function_gradients.

Best,
Daniel

Am Montag, 15. August 2016 03:13:14 UTC+2 schrieb benhour@gmail.com:
>
> Dear All,
> I want to extract the first derivative and the gradient of a scalar 
> function in dealii. Maybe I should use the void FEValuesViews::Scalar 
> <
>  
> dim, spacedim >::get_function_gradients. However, I really do not kn ow how 
> I should use it in a real code. I do really appreciate it if you help me to 
> write it.
>
> Best,
> Benhour
>
>

-- 
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.