Re: [deal.II] Re: Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

2020-01-28 Thread Feimi Yu
Hi Daniel, Thanks for the solution! >From my understanding, it's picking template void sum(const T , const MPI_Comm _communicator, U ) instead of template void sum(const ArrayView , const MPI_Comm & mpi_communicator, const ArrayView & sums) And that's why it is complaining that ",

Re: [deal.II] Re: Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

2020-01-28 Thread Daniel Arndt
Feimi, it's picking the wrong overload. Utilities::MPI::sum(local_vector, mpi_communicator, local_vector); works as well as Utilities::MPI::sum(my_view, mpi_communicator, my_view); Best, Daniel Am Di., 28. Jan. 2020 um 12:57 Uhr schrieb Feimi Yu : > Hi Bruno, > > Thanks for your reply! >

[deal.II] Re: Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

2020-01-28 Thread Feimi Yu
Hi Bruno, Thanks for your reply! That's not true. The input and output arrays may be the same as described in the documentation. The template instatiation error does not check whether they are the same, either. In addition, two different arrays give the same error. Feimi On Tuesday, January

[deal.II] Re: Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

2020-01-28 Thread Feimi Yu
I uploaded a minimal code to reproduce the problem I encountered. Thanks! Feimi On Monday, January 27, 2020 at 1:42:18 PM UTC-5, Feimi Yu wrote: > > Hi, > > I was trying to use the the function Utilities::MPI::sum >

Re: [deal.II] Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

2020-01-28 Thread Feimi Yu
Hi Jean-Paul, Thanks for your reply! Yes, I did try passing an ArrayView, with no luck. I was told the same undefined reference thing. Feimi On Tuesday, January 28, 2020 at 1:53:35 AM UTC-5, Jean-Paul Pelteret wrote: > > Dear Feimi, > > On first glance, it looks like the object you send in as

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-28 Thread Ihar Suvorau
Hi, David, okay, please, attaching these files also. On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: > > Hi Ihar, > > It looks like nothing went wrong with PETsc. Would you please also > send a copy of deal.II's detailed.log and, if available, > CMakeCache.txt from the

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-28 Thread David Wells
Hi Ihar, It looks like nothing went wrong with PETsc. Would you please also send a copy of deal.II's detailed.log and, if available, CMakeCache.txt from the build directory? Thanks, David On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau wrote: > > Sure, attaching a file, please. > > On Monday,

Re: [deal.II] ParameterHandler question

2020-01-28 Thread Wolfgang Bangerth
On 1/27/20 9:01 AM, David Wells wrote: > It sounds like you want to use Patterns::Map or Patterns::List. They can also be nested, which I think is essentially what you want. Though if all of the entries of the list have the form {set var = bool, set var2 = string, etc} then you might as well

Re: [deal.II] Dirichlet boundary condition (homogeneous) on selected dofs

2020-01-28 Thread Wolfgang Bangerth
Krishanu, > I understood that the the Dirichlet boundary condition in this problem was > being applied on only the top surface. But what I am trying to implement > seems > a little different to me. I will try to explain in a little more detail with > an example in the following part. > > I