Re: [deal.II] A data structure for distributed storage of some cell "average"

[vachan potluri]

>
> The problem is a mismatch of expectations. Like in many other places, when
> you
> pass a cell-based vector to DataOut, it assumes that on every process, the
> vector has one entry for each active cell of the triangulation -- i.e., on
> every process it is a *local* vector -- rather than a distributed vector
> with
> one entry for each globally active cell. In other words, for cell-based
> vectors, we ignore the fact that the computation might be parallel.


Thank you for the response, looks like I didn't do my homework properly :P.
Copying the MPI vector into a Vector of size triang.n_active_cells()
and adding this vector instead to DataOut works.

Thanks again!

On Tue, 15 Jun 2021 at 04:24, Wolfgang Bangerth 
wrote:

> On 6/11/21 12:09 AM, vachan potluri wrote:
> >
> > I am having an issue in using DataOut for such vector in a parallel
> process. I
> > am attaching a MWE which captures my problem. I am encountering a
> segmentation
> > fault (signal 11).
>
> The problem is a mismatch of expectations. Like in many other places, when
> you
> pass a cell-based vector to DataOut, it assumes that on every process, the
> vector has one entry for each active cell of the triangulation -- i.e., on
> every process it is a *local* vector -- rather than a distributed vector
> with
> one entry for each globally active cell. In other words, for cell-based
> vectors, we ignore the fact that the computation might be parallel.
>
> Best
>   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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/88da546c-259d-aac8-89cf-598e7c1f6b33%40colostate.edu
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CALAVa_wF96oKWJZ6B77e2a80VDCk_vrGXqp-3sEN0it2XwbGgw%40mail.gmail.com.

Re: [deal.II] time dependent navier stokes (gallery) does not work

[hgbk...@gmail.com]

Hi Marc

The issue propagates up to master. The commit right before 
0c59a54d7385a8e862fa114201e91c0f3c53, which 
is a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8 still runs fine (in this 
particular example). Could you or someone verify this two particular 
commits and confirm my findings, and maybe with the example I attached?

On the time, it seems some fixes have been made after 
51c7b294f5f81c5c0f1ac1aa09670ea1729f563e so the time got back to normal in 
a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8. Therefore I would like to take 
this one back :)

For a36c5bc5fe032abff1ded245d3bfb2bd4af1bbb8:
+-+++
| Total wallclock time elapsed since start| 1.153e+04s ||
| |||
| Section | no. calls |  wall time | % of total |
+-+---+++
| Assemble system |  1000 | 1.346e+02s |  1.17e+00% |
| CG for A|  7278 | 1.108e+04s |  9.61e+01% |
| CG for Mp   |  7278 | 1.302e+01s |  1.13e-01% |
| CG for Sm   |  7379 | 2.360e+02s |  2.05e+00% |
| Output results  |   101 | 1.375e+01s |  1.19e-01% |
| Refine mesh |   100 | 2.851e+01s |  2.47e-01% |
+-+---+++

For 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e (slow)
+-+++
| Total wallclock time elapsed since start| 7.339e+04s ||
| |||
| Section | no. calls |  wall time | % of total |
+-+---+++
| Assemble system |  1000 | 1.486e+02s |  2.03e-01% |
| CG for A|  7268 | 5.602e+04s |  7.63e+01% |
| CG for Mp   |  7268 | 6.499e+02s |  8.86e-01% |
| CG for Sm   |  7369 | 1.608e+04s |  2.19e+01% |
| Output results  |   101 | 9.217e+00s | 0.000e+00% |
| Refine mesh |   100 | 1.345e+02s |  1.83e-01% |
+-+---+++

For d5ab9e084ae9aae301b121c22a5548539df7032e (slow)
+-+++
| Total wallclock time elapsed since start| 8.309e+04s ||
| |||
| Section | no. calls |  wall time | % of total |
+-+---+++
| Assemble system |  1000 | 1.562e+02s |  1.88e-01% |
| CG for A|  7268 | 6.681e+04s |  8.04e+01% |
| CG for Mp   |  7268 | 7.448e+02s |  8.96e-01% |
| CG for Sm   |  7369 | 1.489e+04s |  1.79e+01% |
| Output results  |   101 | 1.231e+01s | 0.000e+00% |
| Refine mesh |   100 | 7.927e+01s | 0.000e+00% |
+-+---+++

For 3c2a09881baa2a55f19e47586b5914babe1b145d:
+-+++
| Total wallclock time elapsed since start| 1.328e+04s ||
| |||
| Section | no. calls |  wall time | % of total |
+-+---+++
| Assemble system |  1000 | 1.769e+02s |  1.33e+00% |
| CG for A|  7278 | 1.135e+04s |  8.55e+01% |
| CG for Mp   |  7278 | 7.197e+01s |  5.42e-01% |
| CG for Sm   |  7379 | 1.256e+03s |  9.45e+00% |
| Output results  |   101 | 2.279e+01s |  1.72e-01% |
| Refine mesh |   100 | 3.357e+02s |  2.53e+00% |
+-+---+++

Best
Giang
On Monday, June 14, 2021 at 10:27:44 PM UTC+2 mafe...@gmail.com wrote:

> Hi Giang,
>
> > I did the git bisect (14 iterations) and it reveals that the commit 
> 0c59a54d7385a8e862fa114201e91c0f3c53 gives the problem.
>
> For convenience, I linked to the commit 
> 
>  
> with that specific hash. This commit is not part of the deal.ii 9.2 
> release, so it can not be the cause of the diverging solution as you found 
> it with version 9.2. Further, that commit only changes parts of the 
> `MatrixFree` implementation, which the code-gallery program does not use.
>
> I'm confused: So your 

Re: [deal.II] A data structure for distributed storage of some cell "average"

[Wolfgang Bangerth]

On 6/11/21 12:09 AM, vachan potluri wrote:


I am having an issue in using DataOut for such vector in a parallel process. I 
am attaching a MWE which captures my problem. I am encountering a segmentation 
fault (signal 11).


The problem is a mismatch of expectations. Like in many other places, when you 
pass a cell-based vector to DataOut, it assumes that on every process, the 
vector has one entry for each active cell of the triangulation -- i.e., on 
every process it is a *local* vector -- rather than a distributed vector with 
one entry for each globally active cell. In other words, for cell-based 
vectors, we ignore the fact that the computation might be parallel.


Best
 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/88da546c-259d-aac8-89cf-598e7c1f6b33%40colostate.edu.

Re: [deal.II] time dependent navier stokes (gallery) does not work

[Marc Fehling]

Hi Giang,

> I did the git bisect (14 iterations) and it reveals that the commit 
0c59a54d7385a8e862fa114201e91c0f3c53 gives the problem.

For convenience, I linked to the commit 

 
with that specific hash. This commit is not part of the deal.ii 9.2 
release, so it can not be the cause of the diverging solution as you found 
it with version 9.2. Further, that commit only changes parts of the 
`MatrixFree` implementation, which the code-gallery program does not use.

I'm confused: So your solution was fine right before that particular 
commit? 


> In addition somewhere between 
commit d5ab9e084ae9aae301b121c22a5548539df7032e 
and 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e makes the code run 
significantly slower.

Did you notice the slowdown only in `Debug` mode or also in `Release` mode?

Best,
Marc

On Monday, June 14, 2021 at 11:06:02 AM UTC-6 hgbk...@gmail.com wrote:

> Hi Wolfgang
>
> Thanks for the hint. Luckily the old code compiled and runs fine with 
> v9.0.0.
>
> I did the git bisect (14 iterations) and it reveals that the commit 
> 0c59a54d7385a8e862fa114201e91c0f3c53 gives the problem.
>
> In addition somewhere between 
> commit d5ab9e084ae9aae301b121c22a5548539df7032e 
> and 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e makes the code run 
> significantly slower.
>
> Unfortunately, I could not thoroughly go into the code and investigate the 
> problem. This is only to find out which commit has an issue.
>
> The test is performed with a slightly modified version of the original 
> example (see attached file) in which
>
> KellyErrorEstimator::estimate(dof_handler,
>face_quad_formula,
>typename FunctionMap::type(),
>present_solution,
>estimated_error_per_cell,
>fe.component_mask(velocity));
>
> is replaced by
>
> KellyErrorEstimator::estimate(dof_handler,
>face_quad_formula,
>{},
>present_solution,
>estimated_error_per_cell,
>fe.component_mask(velocity));
>
> This is because the FunctionMap is deprecated. I hope that it does not 
> affect the results.
>
> Best
> Giang
>
> On Wednesday, June 9, 2021 at 10:43:44 PM UTC+2 Wolfgang Bangerth wrote:
>
>> On 6/5/21 9:02 AM, hgbk...@gmail.com wrote: 
>> > 
>> > I have tried to run this example with deal.II 9.1.0 and this problem 
>> still 
>> > persists. With deal.II 9.0.0/9.0.1 the example fails to compile because 
>> it 
>> > requires affine_constraints.h, which is not yet introduced: 
>> > 
>> > 
>> /home/hbui/workspace2/deal.II/time_dependent_navier_stokes/time_dependent_navier_stokes.cc:9:10:
>>  
>>
>> > fatal error: deal.II/lac/affine_constraints.h: No such file or 
>> directory 
>> >  #include  
>>
>> This class used to be called ConstraintMatrix and was defined in 
>> deal.II/lac/constraint_matrix.h. 
>>
>> You could go back in the history of the NS gallery program to match the 
>> 9.0 
>> release. The github repository for the code gallery is here: 
>> https://github.com/dealii/code-gallery 
>> The history of the .cc file is here: 
>>
>>
>> https://github.com/dealii/code-gallery/commits/master/time_dependent_navier_stokes/time_dependent_navier_stokes.cc
>>  
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f35fb9c6-1c2c-4124-9425-ebb0e4ee30cbn%40googlegroups.com.

[deal.II] Linear operators - TrilinosWrappers

[Juan Felipe Giraldo]

Hello everyone,

I have implemented a residual-minimization framework that somehow is 
similar to DPG. I want to extend my results by using parallelization using 
MPI with PETSc or Trilinos. 
So far, I have solved the saddle point problem using the Schur complement 
exactly how it is described in step 20. Now, I am trying to replicate 
exactly the same solver but using the MPI wrappers and the linear operators.

The problem is that when I am trying to implement the inverse_operator to 
compute the Preconditioner of the Schur complement, I get an error saying 
that the functions are not matching "inverse_operator(op_aS, solver_aS, 
TrilinosWrappers::PreconditionIdentity())."

There is no much documentation about linear operators in parallel solvers, 
so if anyone has any suggestion on how to fix this problem, it would be 
well appreciated. 

I have pasted the complete function in below:


template 
void FEMwDG::
  solve()
  {
TimerOutput::Scope t(computing_timer, "solve");

LA::MPI::PreconditionJacobi prec_M;
 LA::MPI::PreconditionJacobi::AdditionalData data;
 prec_M.initialize(system_matrix.block(0, 0), data);
}

auto  = solution.block(0);
auto  = solution.block(1);
const auto  = system_rhs.block(0);
const auto  M = linear_operator(system_matrix.block(0, 
0));

const auto op_M  = linear_operator(M, prec_M);
const auto op_B   = 
linear_operator(system_matrix.block(0, 1));
const auto op_BT = 
linear_operator(system_matrix.block(1, 0));

ReductionControl  inner_solver_control2(5000,
1e-18 * 
system_rhs.l2_norm(),
1.e-2);

SolverCG cg(inner_solver_control2);
const auto op_M_inv = inverse_operator(M, cg, prec_M);

const auto op_S = op_BT * op_M_inv * op_B;
const auto op_aS = op_BT * linear_operator(prec_M) * 
op_B;

IterationNumberControl   iteration_number_control_aS(30, 1.e-18);
SolverCG solver_aS(iteration_number_control_aS);

const auto preconditioner_S =
inverse_operator(op_aS, solver_aS, 
TrilinosWrappers::PreconditionIdentity());
const auto schur_rhs = op_BT * op_M_inv * L ;

SolverControlsolver_control_S(2000, 1.e-12);
SolverCG solver_S(solver_control_S);

const auto op_S_inv = inverse_operator(op_S, solver_S, preconditioner_S 
);

U = op_S_inv * schur_rhs;
std::cout << solver_control_S.last_step()
  << " CG Schur complement iterations to obtain convergence."
  << std::endl;
E = op_M_inv * (L - op_B * U);
 }

Thank you so much, 

Regards,
Felipe




-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/40b8db07-5243-4603-825b-9e7850580206n%40googlegroups.com.

Re: [deal.II] time dependent navier stokes (gallery) does not work

[hgbk...@gmail.com]

Hi Wolfgang

Thanks for the hint. Luckily the old code compiled and runs fine with 
v9.0.0.

I did the git bisect (14 iterations) and it reveals that the commit 
0c59a54d7385a8e862fa114201e91c0f3c53 gives the problem.

In addition somewhere between 
commit d5ab9e084ae9aae301b121c22a5548539df7032e 
and 51c7b294f5f81c5c0f1ac1aa09670ea1729f563e makes the code run 
significantly slower.

Unfortunately, I could not thoroughly go into the code and investigate the 
problem. This is only to find out which commit has an issue.

The test is performed with a slightly modified version of the original 
example (see attached file) in which

KellyErrorEstimator::estimate(dof_handler,
   face_quad_formula,
   typename FunctionMap::type(),
   present_solution,
   estimated_error_per_cell,
   fe.component_mask(velocity));

is replaced by

KellyErrorEstimator::estimate(dof_handler,
   face_quad_formula,
   {},
   present_solution,
   estimated_error_per_cell,
   fe.component_mask(velocity));

This is because the FunctionMap is deprecated. I hope that it does not 
affect the results.

Best
Giang

On Wednesday, June 9, 2021 at 10:43:44 PM UTC+2 Wolfgang Bangerth wrote:

> On 6/5/21 9:02 AM, hgbk...@gmail.com wrote: 
> > 
> > I have tried to run this example with deal.II 9.1.0 and this problem 
> still 
> > persists. With deal.II 9.0.0/9.0.1 the example fails to compile because 
> it 
> > requires affine_constraints.h, which is not yet introduced: 
> > 
> > 
> /home/hbui/workspace2/deal.II/time_dependent_navier_stokes/time_dependent_navier_stokes.cc:9:10:
>  
>
> > fatal error: deal.II/lac/affine_constraints.h: No such file or directory 
> >  #include  
>
> This class used to be called ConstraintMatrix and was defined in 
> deal.II/lac/constraint_matrix.h. 
>
> You could go back in the history of the NS gallery program to match the 
> 9.0 
> release. The github repository for the code gallery is here: 
> https://github.com/dealii/code-gallery 
> The history of the .cc file is here: 
>
>
> https://github.com/dealii/code-gallery/commits/master/time_dependent_navier_stokes/time_dependent_navier_stokes.cc
>  
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/4aae27e3-9525-4e3c-aa5c-cb5aa17eefcdn%40googlegroups.com.
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
//#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 

namespace fluid
{
  using namespace dealii;

  // @sect3{Create the triangulation}
  // The code to create triangulation is copied from
  // [Martin Kronbichler's
  // code](https://github.com/kronbichler/adaflo/blob/master/tests/flow_past_cylinder.cc)
  // with very few modifications.
  //
  // @sect4{Helper function}
  void create_triangulation_2d(Triangulation<2> ,
   bool compute_in_2d = true)
  {
SphericalManifold<2> boundary(Point<2>(0.5, 0.2));
Triangulation<2> left, middle, right, tmp, tmp2;
GridGenerator::subdivided_hyper_rectangle(
  left,
  std::vector({3U, 4U}),
  Point<2>(),
  Point<2>(0.3, 0.41),
  false);
GridGenerator::subdivided_hyper_rectangle(
  right,
  std::vector({18U, 4U}),
  Point<2>(0.7, 0),
  Point<2>(2.5, 0.41),
  false);

// Create middle part first as a hyper shell.
GridGenerator::hyper_shell(middle, Point<2>(0.5, 0.2), 0.05, 0.2, 4, true);
middle.reset_all_manifolds();
for (Triangulation<2>::cell_iterator cell = middle.begin();
 cell != middle.end();
 ++cell)
  for (unsigned int f = 0; f < GeometryInfo<2>::faces_per_cell; ++f)
{
  bool is_inner_rim = true;
  for (unsigned int v = 0; v < GeometryInfo<2>::vertices_per_face; 

[deal.II] Re: Deal.II site appears to be down

[Bruno Turcksin]

Alex,

I think it's because we are preparing for the release of deal.II 9.3.0 If 
you use the direct link to the 9.2 documentation 
https://dealii.org/9.2.0/doxygen/deal.II/index.html it works fine. It's the 
"current" link which seems to be broken.

Best,

Bruno

On Monday, June 14, 2021 at 9:37:48 AM UTC-4 alexanderc...@gmail.com wrote:

> I am also unable to access the website, although it is specifically the 
> documentation pages that are down.
>
> Best,
> Alex
>
> On Monday, June 14, 2021 at 2:16:08 a.m. UTC+2 corbin@gmail.com wrote:
>
>> Hello everyone,
>>
>> It seems dealii.org is experiencing some problems or is down (I'm on the 
>> east coast of the US)--checking on 
>> https://downforeveryoneorjustme.com/dealii.org, it seems the server is 
>> not responding and the issue isn't local to me.
>>
>> I'm posting this for the site admins just in case I'm the first to notice.
>>
>> Best,
>> Corbin 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/665a61a1-23db-4085-a59e-03918125bf5an%40googlegroups.com.

[deal.II] Re: Deal.II site appears to be down

[Alex Cumberworth]

I am also unable to access the website, although it is specifically the 
documentation pages that are down.

Best,
Alex

On Monday, June 14, 2021 at 2:16:08 a.m. UTC+2 corbin@gmail.com wrote:

> Hello everyone,
>
> It seems dealii.org is experiencing some problems or is down (I'm on the 
> east coast of the US)--checking on 
> https://downforeveryoneorjustme.com/dealii.org, it seems the server is 
> not responding and the issue isn't local to me.
>
> I'm posting this for the site admins just in case I'm the first to notice.
>
> Best,
> Corbin 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0ca30dd9-eab3-4c5a-b00f-27efe8e9bf21n%40googlegroups.com.

Re: [deal.II] A data structure for distributed storage of some cell "average"

[vachanpo...@gmail.com]

Hello,

I have a small question and I think the issue lies here. Are these two 
function calls equivalent?

ghosted_vector.reinit(
  /*locally owned indices*/,
  /*ghost indices only*/,
  mpi_communicator
);

ghosted_vector.reinit(
  /*locally owned indices*/,
  /*relevant indices (owned + ghost)*/,
  mpi_communicator
);

The program runs as expected for a serial execution. I am using the first 
version here and may be that is causing a crash in a parallel execution.

Any reference to a use case of 
p::d::Triangulation::global_active_cell_index_partitioner() would be very 
helpful :) !

Thanks
On Friday, June 11, 2021 at 11:40:37 AM UTC+5:30 vachanpo...@gmail.com 
wrote:

> Hello,
>
> I am having an issue in using DataOut for such vector in a parallel 
> process. I am attaching a MWE which captures my problem. I am encountering 
> a segmentation fault (signal 11).
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
>
> using namespace dealii;
> namespace LA
> {
> using namespace ::LinearAlgebraPETSc;
> }
>
> int main(int argc, char **argv)
> {
> Utilities::MPI::MPI_InitFinalize mpi_initialization(argc, argv, 1);
>
> constexpr int dim = 3;
>
> MPI_Comm mpi_comm(MPI_COMM_WORLD);
>
> parallel::distributed::Triangulation triang(mpi_comm);
> GridGenerator::subdivided_hyper_cube(triang, 5);
> const std::shared_ptr cell_partitioner 
> =
> triang.global_active_cell_index_partitioner().lock();
> LA::MPI::Vector vec(cell_partitioner->locally_owned_range(), mpi_comm);
> LA::MPI::Vector gh_vec(
> cell_partitioner->locally_owned_range(),
> cell_partitioner->ghost_indices(),
> mpi_comm
> );
>
> DoFHandler dof_handler(triang);
> FE_DGQ fe(2);
> dof_handler.distribute_dofs(fe);
>
> for(auto : dof_handler.active_cell_iterators()){
> if(!cell->is_locally_owned()) continue;
>
> vec[cell->global_active_cell_index()] = cell->global_active_cell_index();
> }
> vec.compress(VectorOperation::insert);
>
> gh_vec = vec;
>
> DataOut data_out;
> DataOutBase::VtkFlags flags;
> flags.write_higher_order_cells = true;
> data_out.set_flags(flags);
>
> data_out.attach_dof_handler(dof_handler);
>
> data_out.add_data_vector(gh_vec, "x");
>
> data_out.build_patches(
> MappingQGeneric(2),
> 2,
> DataOut::CurvedCellRegion::curved_inner_cells
> );
>
> std::ofstream proc_file(
> "output" + Utilities::int_to_string(
> Utilities::MPI::this_mpi_process(mpi_comm),
> 2
> ) + ".vtu"
> );
> data_out.write_vtu(proc_file);
> proc_file.close();
>
> if(Utilities::MPI::this_mpi_process(mpi_comm) == 0){
> std::vector filenames;
> for(int i=0; i filenames.emplace_back(
> "output" + Utilities::int_to_string(i, 2) + ".vtu"
> );
> } // loop over processes
>
> std::ofstream master_file("output.pvtu");
> data_out.write_pvtu_record(master_file, filenames);
> master_file.close();
> }
> return 0;
> }
>
>
> I suspect I am not partitioning the ghosted vector properly hence causing 
> a mismatch in what is available and what DataOut wants. Am I missing any 
> other step in between?
>
> Thanking in anticipation
>
> On Tue, 8 Jun 2021 at 19:32, vachan potluri  wrote:
>
>> Thank you :).
>>
>> On Tue, 8 Jun, 2021, 19:24 Wolfgang Bangerth,  
>> wrote:
>>
>>> On 6/8/21 4:18 AM, vachanpo...@gmail.com wrote:
>>> > If I want to add such a vector to DataOut, will the regular 
>>> > DataOut::add_data_vector() work? Or is something else required to be 
>>> done?
>>>
>>> Yes, DataOut::add_data_vector() can take two kinds of vectors:
>>> * Ones that have as many entries as there are DoFs
>>> * Ones that have as many entries as there are active cells
>>>
>>> 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+un...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/dealii/2c89ac60-d144-8ef3-62db-f15770096bd6%40colostate.edu
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/c4fe656c-bee2-40e4-878f-a2f845589539n%40googlegroups.com.

[deal.II] Re: online deal.II workshop: Friday, June 18

['David' via deal.II User Group]

Hi Timo,

short question: will the workshop afterwards be available on YouTube 
analogous to the last workshop?

Regards, 
David
On Wednesday, 2 June 2021 at 17:36:08 UTC+2 Timo Heister wrote:

> Hi all,
>
> We would like to announce a one-day deal.II workshop on June 18, 2021
> with several talks about recent developments in the library, the 9.3
> release, and interesting user projects. The talks will be available
> live using zoom and available as a video at a later time.
>
> For more information including a schedule, please see:
> https://dealii.org/workshop-2021/
>
> Information on how to join will be made available closer to the date.
> We hope to see you there!
>
> Best,
> Timo and the deal.II developers
>
> -- 
> 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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/084cee70-63c3-43ed-9202-574f8df34aa6n%40googlegroups.com.