Re: [deal.II] Re: Saving particles for checkpointing

2020-12-09 Thread Wolfgang Bangerth

On 12/9/20 5:32 PM, blais...@gmail.com wrote:

I have one tiny question actually.
In all tests, the std::ostringstream oss which contains some information about 
the number of particles and the data being serialized is kept.
Generally, I guess this should be written to an auxiliary file, then re-read 
before deserialization can occur?


Yes, precisely. In fact, instead of a std::ostringstring, when you write to 
file you might as well have directly given a std::ofstream.


That that data could be written to a file is not important for the test, 
though, and so it doesn't do that.


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/aa85fbe5-5f91-9edb-b20c-3de81e5a0dcd%40colostate.edu.


[deal.II] Re: Saving particles for checkpointing

2020-12-09 Thread blais...@gmail.com
I have one tiny question actually.
In all tests, the std::ostringstream oss which contains some information 
about the number of particles and the data being serialized is kept.
Generally, I guess this should be written to an auxiliary file, then 
re-read before deserialization can occur?



On Wednesday, December 9, 2020 at 7:13:08 p.m. UTC-5 blais...@gmail.com 
wrote:

> I think they will! I feel kind-off dumb not having realized that :)
> Thanks!
> Bruno
>
>
> On Wednesday, December 9, 2020 at 6:06:17 p.m. UTC-5 peterrum wrote:
>
>> Do the following links help?
>> - 
>> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_01.cc
>> - 
>> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_02.cc
>>
>> Peter
>>
>> On Wednesday, 9 December 2020 at 23:15:09 UTC+1 blais...@gmail.com wrote:
>>
>>> Dear all, I hope you are well.
>>> I am trying to add checkpointing in our particle code. Particles do not 
>>> have a save function, but they have a serialize function, which I think 
>>> would be exactly what I need.
>>> However, the function is not documented. It takes as an argument 
>>> something of class Archive, which I could not find any information on.
>>> I also grepped all over the tests, but I could not find a usage of this 
>>> function.
>>>
>>> https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c
>>>
>>> Would anybody have a quick tutorial or example on how this function 
>>> could be used for checkpoint the particle_handler and the properties of the 
>>> particles?
>>> Thank you so much :)!
>>> Bruno
>>>
>>>

-- 
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/9e3ea43b-ab68-44e9-b85d-c0e47069e848n%40googlegroups.com.


Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

2020-12-09 Thread Kaushik Das
Thank you, Mark. I just built dealii from the source (deal.II-9.3.0-pre).
And my little test is passing now.
Thanks for the help.
-Kaushik

On Wed, Dec 9, 2020 at 4:36 PM Kaushik Das  wrote:

> Thank you Mark.
> I am using the dealii lib that I got from apt-get from
> deal.ii-9.2.0-backports.
> I used PETSc and the abort was on even 1 cpus. I tried 2, 3, 6 cpus and
> all aborted similarly.
>
> I will get the latest master branch and build that.
>
>
> Thanks,
> Kaushik
>
> On Wed, Dec 9, 2020 at 4:23 PM Marc Fehling  wrote:
>
>> From your stacktrace I can see you are using PETSc and deal.II 9.2.0
>> which already incorporates the specified patch. Would you try to build the
>> actual master branch anyways?
>> On Wednesday, December 9, 2020 at 2:11:59 PM UTC-7 Marc Fehling wrote:
>>
>>> Hi Kaushik,
>>>
>>> I am unable to reproduce your problem with the code you provided on the
>>> latest build of deal.II and Trilinos.
>>>
>>>- On how many processes did you run your program?
>>>- Did you use PETSc or Trilinos?
>>>- Could you try to build deal.II on the latest master branch? There
>>>is a chance that your issue has been solved upstream. Chances are high 
>>> that
>>>fix #8860  and the
>>>changes made to `get_interpolated_dof_values()` will solve your problem.
>>>
>>> Marc
>>> On Wednesday, December 9, 2020 at 7:14:57 AM UTC-7 k.d...@gmail.com
>>> wrote:
>>>
 Hi Marc and Bruno,
 I was able to reproduce this abort on an even simpler test. Please see
 the attached file.

 Initial grid:
  /*
 * ---
 * |  0 |  0 |
 * ---
 * |  1 |  1 | 0 - FEQ, 1 - FE_Nothing
 * ---
 */

 /* Set refine flags:
 * ---
 * |  R |  R |FEQ
 * ---
 * |  |  |FE_Nothing
 * ---
 */

 Then refine and solution trans. During the
 execute_coarsening_and_refinement, it aborts.

 Here is a stack trace:
 

 An error occurred in line <1167> of file
  in
 function
 Number&
 dealii::Vector::operator()(dealii::Vector::size_type) [with
 Number = double; dealii::Vector::size_type = unsigned int]
 The violated condition was:
 static_cast>>> typename std::common_type::type)>:: type>(i)
 < static_cast>>> std::common_type::type)>:: type>(size())
 Additional information:
 Index 0 is not in the half-open range [0,0). In the current case,
 this half-open range is in fact empty, suggesting that you are accessing an
 element of an empty collection such as a vector that has not been set to
 the correct size.

 Stacktrace:
 ---
 #0  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 dealii::Vector::operator()(unsigned int)
 #1  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 #2  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 dealii::parallel::distributed::SolutionTransfer<2,
 dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
 >::pack_callback(dealii::TriaIterator > const&,
 dealii::Triangulation<2, 2>::CellStatus)
 #3  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 dealii::parallel::distributed::SolutionTransfer<2,
 dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
 >::register_data_attach()::{lambda(dealii::TriaIterator>>> 2> > const&, dealii::Triangulation<2,
 2>::CellStatus)#1}::operator()(dealii::TriaIterator>>> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
 #4  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 std::_Function_handler >
 (dealii::TriaIterator > const&,
 dealii::Triangulation<2, 2>::CellStatus),
 dealii::parallel::distributed::SolutionTransfer<2,
 dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
 >::register_data_attach()::{lambda(dealii::TriaIterator>>> 2> > const&, dealii::Triangulation<2,
 2>::CellStatus)#1}>::_M_invoke(std::_Any_data const&,
 dealii::TriaIterator > const&,
 dealii::Triangulation<2, 2>::CellStatus&&)
 #5  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 std::function >
 (dealii::TriaIterator > const&,
 dealii::Triangulation<2,
 2>::CellStatus)>::operator()(dealii::TriaIterator>>> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
 #6  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 std::_Function_handler >
 (dealii::TriaIterator >,
 dealii::Triangulation<2, 2>::CellStatus), std::function>>> std::allocator > (dealii::TriaIterator >
 const&, dealii::Triangulation<2, 2>::CellStatus)>
 >::_M_invoke(std::_Any_data const&,
 dealii::TriaIterator >&&,
 dealii::Triangulation<2, 2>::CellStatus&&)
 #7  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
 std::function >
 (dealii::TriaIterator >,
 dealii::Triangulation<2,
 

[deal.II] Re: Saving particles for checkpointing

2020-12-09 Thread blais...@gmail.com
I think they will! I feel kind-off dumb not having realized that :)
Thanks!
Bruno


On Wednesday, December 9, 2020 at 6:06:17 p.m. UTC-5 peterrum wrote:

> Do the following links help?
> - 
> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_01.cc
> - 
> https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_02.cc
>
> Peter
>
> On Wednesday, 9 December 2020 at 23:15:09 UTC+1 blais...@gmail.com wrote:
>
>> Dear all, I hope you are well.
>> I am trying to add checkpointing in our particle code. Particles do not 
>> have a save function, but they have a serialize function, which I think 
>> would be exactly what I need.
>> However, the function is not documented. It takes as an argument 
>> something of class Archive, which I could not find any information on.
>> I also grepped all over the tests, but I could not find a usage of this 
>> function.
>>
>> https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c
>>
>> Would anybody have a quick tutorial or example on how this function could 
>> be used for checkpoint the particle_handler and the properties of the 
>> particles?
>> Thank you so much :)!
>> Bruno
>>
>>

-- 
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/8b8fb15a-4ba7-40dd-9cfe-151677b307e5n%40googlegroups.com.


[deal.II] Re: Saving particles for checkpointing

2020-12-09 Thread 'peterrum' via deal.II User Group
Do the following links help?
- 
https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_01.cc
- 
https://github.com/dealii/dealii/blob/master/tests/serialization/particle_handler_02.cc

Peter

On Wednesday, 9 December 2020 at 23:15:09 UTC+1 blais...@gmail.com wrote:

> Dear all, I hope you are well.
> I am trying to add checkpointing in our particle code. Particles do not 
> have a save function, but they have a serialize function, which I think 
> would be exactly what I need.
> However, the function is not documented. It takes as an argument something 
> of class Archive, which I could not find any information on.
> I also grepped all over the tests, but I could not find a usage of this 
> function.
>
> https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c
>
> Would anybody have a quick tutorial or example on how this function could 
> be used for checkpoint the particle_handler and the properties of the 
> particles?
> Thank you so much :)!
> Bruno
>
>

-- 
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/53991163-d407-4616-b69c-355f8853ac00n%40googlegroups.com.


[deal.II] Saving particles for checkpointing

2020-12-09 Thread blais...@gmail.com
Dear all, I hope you are well.
I am trying to add checkpointing in our particle code. Particles do not 
have a save function, but they have a serialize function, which I think 
would be exactly what I need.
However, the function is not documented. It takes as an argument something 
of class Archive, which I could not find any information on.
I also grepped all over the tests, but I could not find a usage of this 
function.
https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1ParticleHandler.html#a877e1aac8ef0ad6fa85ed400bf71eb1c

Would anybody have a quick tutorial or example on how this function could 
be used for checkpoint the particle_handler and the properties of the 
particles?
Thank you so much :)!
Bruno

-- 
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/11a1304d-fd8c-4ea1-8fb8-81e52ae748e8n%40googlegroups.com.


Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

2020-12-09 Thread Kaushik Das
Thank you Mark.
I am using the dealii lib that I got from apt-get from
deal.ii-9.2.0-backports.
I used PETSc and the abort was on even 1 cpus. I tried 2, 3, 6 cpus and all
aborted similarly.

I will get the latest master branch and build that.


Thanks,
Kaushik

On Wed, Dec 9, 2020 at 4:23 PM Marc Fehling  wrote:

> From your stacktrace I can see you are using PETSc and deal.II 9.2.0 which
> already incorporates the specified patch. Would you try to build the actual
> master branch anyways?
> On Wednesday, December 9, 2020 at 2:11:59 PM UTC-7 Marc Fehling wrote:
>
>> Hi Kaushik,
>>
>> I am unable to reproduce your problem with the code you provided on the
>> latest build of deal.II and Trilinos.
>>
>>- On how many processes did you run your program?
>>- Did you use PETSc or Trilinos?
>>- Could you try to build deal.II on the latest master branch? There
>>is a chance that your issue has been solved upstream. Chances are high 
>> that
>>fix #8860  and the
>>changes made to `get_interpolated_dof_values()` will solve your problem.
>>
>> Marc
>> On Wednesday, December 9, 2020 at 7:14:57 AM UTC-7 k.d...@gmail.com
>> wrote:
>>
>>> Hi Marc and Bruno,
>>> I was able to reproduce this abort on an even simpler test. Please see
>>> the attached file.
>>>
>>> Initial grid:
>>>  /*
>>> * ---
>>> * |  0 |  0 |
>>> * ---
>>> * |  1 |  1 | 0 - FEQ, 1 - FE_Nothing
>>> * ---
>>> */
>>>
>>> /* Set refine flags:
>>> * ---
>>> * |  R |  R |FEQ
>>> * ---
>>> * |  |  |FE_Nothing
>>> * ---
>>> */
>>>
>>> Then refine and solution trans. During the
>>> execute_coarsening_and_refinement, it aborts.
>>>
>>> Here is a stack trace:
>>> 
>>>
>>> An error occurred in line <1167> of file
>>>  in
>>> function
>>> Number&
>>> dealii::Vector::operator()(dealii::Vector::size_type) [with
>>> Number = double; dealii::Vector::size_type = unsigned int]
>>> The violated condition was:
>>> static_cast>> typename std::common_type::type)>:: type>(i)
>>> < static_cast>> std::common_type::type)>:: type>(size())
>>> Additional information:
>>> Index 0 is not in the half-open range [0,0). In the current case,
>>> this half-open range is in fact empty, suggesting that you are accessing an
>>> element of an empty collection such as a vector that has not been set to
>>> the correct size.
>>>
>>> Stacktrace:
>>> ---
>>> #0  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> dealii::Vector::operator()(unsigned int)
>>> #1  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> #2  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> dealii::parallel::distributed::SolutionTransfer<2,
>>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>>> >::pack_callback(dealii::TriaIterator > const&,
>>> dealii::Triangulation<2, 2>::CellStatus)
>>> #3  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> dealii::parallel::distributed::SolutionTransfer<2,
>>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>>> >::register_data_attach()::{lambda(dealii::TriaIterator>> 2> > const&, dealii::Triangulation<2,
>>> 2>::CellStatus)#1}::operator()(dealii::TriaIterator>> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
>>> #4  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> std::_Function_handler >
>>> (dealii::TriaIterator > const&,
>>> dealii::Triangulation<2, 2>::CellStatus),
>>> dealii::parallel::distributed::SolutionTransfer<2,
>>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>>> >::register_data_attach()::{lambda(dealii::TriaIterator>> 2> > const&, dealii::Triangulation<2,
>>> 2>::CellStatus)#1}>::_M_invoke(std::_Any_data const&,
>>> dealii::TriaIterator > const&,
>>> dealii::Triangulation<2, 2>::CellStatus&&)
>>> #5  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> std::function >
>>> (dealii::TriaIterator > const&,
>>> dealii::Triangulation<2,
>>> 2>::CellStatus)>::operator()(dealii::TriaIterator>> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
>>> #6  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> std::_Function_handler >
>>> (dealii::TriaIterator >,
>>> dealii::Triangulation<2, 2>::CellStatus), std::function>> std::allocator > (dealii::TriaIterator >
>>> const&, dealii::Triangulation<2, 2>::CellStatus)>
>>> >::_M_invoke(std::_Any_data const&,
>>> dealii::TriaIterator >&&,
>>> dealii::Triangulation<2, 2>::CellStatus&&)
>>> #7  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> std::function >
>>> (dealii::TriaIterator >,
>>> dealii::Triangulation<2,
>>> 2>::CellStatus)>::operator()(dealii::TriaIterator>> 2> >, dealii::Triangulation<2, 2>::CellStatus) const
>>> #8  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
>>> dealii::parallel::distributed::Triangulation<2,
>>> 2>::DataTransfer::pack_data(std::vector>> dealii::Triangulation<2, 2>::CellStatus,
>>> dealii::TriaIterator > >,
>>> std::allocator>> 2>::CellStatus, 

Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

2020-12-09 Thread Marc Fehling
>From your stacktrace I can see you are using PETSc and deal.II 9.2.0 which 
already incorporates the specified patch. Would you try to build the actual 
master branch anyways?
On Wednesday, December 9, 2020 at 2:11:59 PM UTC-7 Marc Fehling wrote:

> Hi Kaushik,
>
> I am unable to reproduce your problem with the code you provided on the 
> latest build of deal.II and Trilinos.
>
>- On how many processes did you run your program?
>- Did you use PETSc or Trilinos?
>- Could you try to build deal.II on the latest master branch? There is 
>a chance that your issue has been solved upstream. Chances are high that 
>fix #8860  and the changes 
>made to `get_interpolated_dof_values()` will solve your problem.
>
> Marc
> On Wednesday, December 9, 2020 at 7:14:57 AM UTC-7 k.d...@gmail.com wrote:
>
>> Hi Marc and Bruno,
>> I was able to reproduce this abort on an even simpler test. Please see 
>> the attached file. 
>>
>> Initial grid:
>>  /*
>> * ---
>> * |  0 |  0 |
>> * ---
>> * |  1 |  1 | 0 - FEQ, 1 - FE_Nothing
>> * ---
>> */
>>
>> /* Set refine flags:
>> * ---
>> * |  R |  R |FEQ
>> * ---
>> * |  |  |FE_Nothing
>> * ---
>> */
>>
>> Then refine and solution trans. During the  
>> execute_coarsening_and_refinement, it aborts. 
>>
>> Here is a stack trace:
>> 
>>
>> An error occurred in line <1167> of file 
>>  in 
>> function
>> Number& 
>> dealii::Vector::operator()(dealii::Vector::size_type) [with 
>> Number = double; dealii::Vector::size_type = unsigned int]
>> The violated condition was: 
>> static_cast> std::common_type::type)>:: type>(i) < 
>> static_cast> std::common_type::type)>:: type>(size())
>> Additional information: 
>> Index 0 is not in the half-open range [0,0). In the current case, 
>> this half-open range is in fact empty, suggesting that you are accessing an 
>> element of an empty collection such as a vector that has not been set to 
>> the correct size.
>>
>> Stacktrace:
>> ---
>> #0  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> dealii::Vector::operator()(unsigned int)
>> #1  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> #2  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> dealii::parallel::distributed::SolutionTransfer<2, 
>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
>> >::pack_callback(dealii::TriaIterator > const&, 
>> dealii::Triangulation<2, 2>::CellStatus)
>> #3  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> dealii::parallel::distributed::SolutionTransfer<2, 
>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
>> >::register_data_attach()::{lambda(dealii::TriaIterator> > 
>> 2> > const&, dealii::Triangulation<2, 
>> 2>::CellStatus)#1}::operator()(dealii::TriaIterator> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
>> #4  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> std::_Function_handler > 
>> (dealii::TriaIterator > const&, 
>> dealii::Triangulation<2, 2>::CellStatus), 
>> dealii::parallel::distributed::SolutionTransfer<2, 
>> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
>> >::register_data_attach()::{lambda(dealii::TriaIterator> > 
>> 2> > const&, dealii::Triangulation<2, 
>> 2>::CellStatus)#1}>::_M_invoke(std::_Any_data const&, 
>> dealii::TriaIterator > const&, 
>> dealii::Triangulation<2, 2>::CellStatus&&)
>> #5  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> std::function > 
>> (dealii::TriaIterator > const&, 
>> dealii::Triangulation<2, 
>> 2>::CellStatus)>::operator()(dealii::TriaIterator> 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
>> #6  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> std::_Function_handler > 
>> (dealii::TriaIterator >, 
>> dealii::Triangulation<2, 2>::CellStatus), std::function> std::allocator > (dealii::TriaIterator > 
>> const&, dealii::Triangulation<2, 2>::CellStatus)> 
>> >::_M_invoke(std::_Any_data const&, 
>> dealii::TriaIterator >&&, 
>> dealii::Triangulation<2, 2>::CellStatus&&)
>> #7  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> std::function > 
>> (dealii::TriaIterator >, 
>> dealii::Triangulation<2, 
>> 2>::CellStatus)>::operator()(dealii::TriaIterator> 2> >, dealii::Triangulation<2, 2>::CellStatus) const
>> #8  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
>> dealii::parallel::distributed::Triangulation<2, 
>> 2>::DataTransfer::pack_data(std::vector> dealii::Triangulation<2, 2>::CellStatus, 
>> dealii::TriaIterator > >, 
>> std::allocator> 2>::CellStatus, dealii::TriaIterator > > > > 
>> const&, std::vector > 
>> (dealii::TriaIterator >, 
>> dealii::Triangulation<2, 2>::CellStatus)>, 
>> std::allocator > 
>> (dealii::TriaIterator >, 
>> dealii::Triangulation<2, 2>::CellStatus)> > > const&, 
>> std::vector > 
>> (dealii::TriaIterator >, 
>> dealii::Triangulation<2, 2>::CellStatus)>, 
>> std::allocator > 
>> (dealii::TriaIterator 

Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

2020-12-09 Thread Marc Fehling
Hi Kaushik,

I am unable to reproduce your problem with the code you provided on the 
latest build of deal.II and Trilinos.

   - On how many processes did you run your program?
   - Did you use PETSc or Trilinos?
   - Could you try to build deal.II on the latest master branch? There is a 
   chance that your issue has been solved upstream. Chances are high that fix 
   #8860  and the changes made 
   to `get_interpolated_dof_values()` will solve your problem.
   
Marc
On Wednesday, December 9, 2020 at 7:14:57 AM UTC-7 k.d...@gmail.com wrote:

> Hi Marc and Bruno,
> I was able to reproduce this abort on an even simpler test. Please see the 
> attached file. 
>
> Initial grid:
>  /*
> * ---
> * |  0 |  0 |
> * ---
> * |  1 |  1 | 0 - FEQ, 1 - FE_Nothing
> * ---
> */
>
> /* Set refine flags:
> * ---
> * |  R |  R |FEQ
> * ---
> * |  |  |FE_Nothing
> * ---
> */
>
> Then refine and solution trans. During the  
> execute_coarsening_and_refinement, it aborts. 
>
> Here is a stack trace:
> 
>
> An error occurred in line <1167> of file 
>  in 
> function
> Number& 
> dealii::Vector::operator()(dealii::Vector::size_type) [with 
> Number = double; dealii::Vector::size_type = unsigned int]
> The violated condition was: 
> static_cast std::common_type::type)>:: type>(i) < 
> static_cast std::common_type::type)>:: type>(size())
> Additional information: 
> Index 0 is not in the half-open range [0,0). In the current case, this 
> half-open range is in fact empty, suggesting that you are accessing an 
> element of an empty collection such as a vector that has not been set to 
> the correct size.
>
> Stacktrace:
> ---
> #0  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> dealii::Vector::operator()(unsigned int)
> #1  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> #2  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> dealii::parallel::distributed::SolutionTransfer<2, 
> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
> >::pack_callback(dealii::TriaIterator > const&, 
> dealii::Triangulation<2, 2>::CellStatus)
> #3  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> dealii::parallel::distributed::SolutionTransfer<2, 
> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
> >::register_data_attach()::{lambda(dealii::TriaIterator > 
> 2> > const&, dealii::Triangulation<2, 
> 2>::CellStatus)#1}::operator()(dealii::TriaIterator 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
> #4  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> std::_Function_handler > 
> (dealii::TriaIterator > const&, 
> dealii::Triangulation<2, 2>::CellStatus), 
> dealii::parallel::distributed::SolutionTransfer<2, 
> dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2> 
> >::register_data_attach()::{lambda(dealii::TriaIterator > 
> 2> > const&, dealii::Triangulation<2, 
> 2>::CellStatus)#1}>::_M_invoke(std::_Any_data const&, 
> dealii::TriaIterator > const&, 
> dealii::Triangulation<2, 2>::CellStatus&&)
> #5  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> std::function > 
> (dealii::TriaIterator > const&, 
> dealii::Triangulation<2, 
> 2>::CellStatus)>::operator()(dealii::TriaIterator 2> > const&, dealii::Triangulation<2, 2>::CellStatus) const
> #6  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> std::_Function_handler > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 2>::CellStatus), std::function std::allocator > (dealii::TriaIterator > 
> const&, dealii::Triangulation<2, 2>::CellStatus)> 
> >::_M_invoke(std::_Any_data const&, 
> dealii::TriaIterator >&&, 
> dealii::Triangulation<2, 2>::CellStatus&&)
> #7  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> std::function > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 
> 2>::CellStatus)>::operator()(dealii::TriaIterator 2> >, dealii::Triangulation<2, 2>::CellStatus) const
> #8  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> dealii::parallel::distributed::Triangulation<2, 
> 2>::DataTransfer::pack_data(std::vector dealii::Triangulation<2, 2>::CellStatus, 
> dealii::TriaIterator > >, 
> std::allocator 2>::CellStatus, dealii::TriaIterator > > > > 
> const&, std::vector > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 2>::CellStatus)>, 
> std::allocator > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 2>::CellStatus)> > > const&, 
> std::vector > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 2>::CellStatus)>, 
> std::allocator > 
> (dealii::TriaIterator >, 
> dealii::Triangulation<2, 2>::CellStatus)> > > const&)
> #9  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0: 
> dealii::parallel::distributed::Triangulation<2, 
> 2>::execute_coarsening_and_refinement()
> #10  /home/kdas/FE_NothingTest/build/test_distributed: main
>
> Thank you very much,
> Kaushik 
>
> On Tue, Dec 8, 2020 at 6:25 PM Marc Fehling  wrote:
>
>> Hi Kaushik,
>>
>> the 

Re: [deal.II] initial values of different-type data

2020-12-09 Thread Matthias Maier
You have to be a bit careful - unfortunately, C++ has one of the most
convoluted rules when objects are zero initialized or not.

As a rule of thumb:

* whenever you are working with a plain "double", "float", "int",
  etc. it is best to explicitly initialize the variable (because C++ in
  most cases does not initialize the variable for you):

  unsigned int i = 0;
  double d = 0.;
  float f = 0.;

* in case of a "container" like std::vector, dealii::Vector,
  dealii::Tensor elements are default initialized:

  dealii::Tensor<1, dim> t; // zeroes elements
  dealii::Vector V;
  V.reinit(10);  // zeroes elements

  std::vector v;
  v.resize(10);  // zeroes elements

I do not understand your second question :-(

Best,
Matthias


On Wed, Dec  9, 2020, at 09:43 CST, Chenyi LUO  wrote:

> Hi dealii developers,
>
> I would like to ask(confirm)whether zero is the initial value of
> different-type data, e.g. for  double, int, Vector and Tensor. For
> example, if I just define double x;. Does x have an initial value of 0.0?
>
> Moreover, in my task, I set initial values of a variable, e.g. "a",  to
> be one in the whole domain. When I assemble the residual vector, I need
> to first compute the value of "a" at quadrature points (which turns out
> not exactly 1.0). Consequently, when I compute, e.g. "3*a^4-2*a^3+a^2",
> the answer is not zero. Is it avoidable?
>
> Best,
>
> Chenyi

-- 
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/87blf2ud45.fsf%4043-1.org.


[deal.II] initial values of different-type data

2020-12-09 Thread Chenyi LUO
Hi dealii developers,

I would like to ask(confirm)whether zero is the initial value of
different-type data, e.g. for  double, int, Vector and Tensor. For
example, if I just define double x;. Does x have an initial value of 0.0?

Moreover, in my task, I set initial values of a variable, e.g. "a",  to
be one in the whole domain. When I assemble the residual vector, I need
to first compute the value of "a" at quadrature points (which turns out
not exactly 1.0). Consequently, when I compute, e.g. "3*a^4-2*a^3+a^2",
the answer is not zero. Is it avoidable?

Best,

Chenyi

-- 
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/CANmBX4TfES8vYsWN4uiEd5BTGJrC8Mkpaw%3DHzTO%3Ddo8-7VJD0g%40mail.gmail.com.


Re: [deal.II] Div-conforming elements in 3D

2020-12-09 Thread Konrad Simon
Hi David, 

Many thanks for the hint. After some research I believe I stumbled over this 
issue#7970 ? Let's see what I 
can do.

Best,
Konrad
On Tuesday, December 8, 2020 at 10:56:44 PM UTC+1 Wells, David wrote:

> Hi Konrad,
>
> This isn't a very satisfying answer but, to the best of my knowledge, 
> these Hdiv elements weren't written with general unstructured 3D meshes in 
> mind. I suspect, without looking more closely, that this is a problem on 
> our side.
>
> We document this for the FE_RaviartThomasNodal class but for 
> FE_RaviartThomas this is just a comment in the source file. Would you be 
> willing to write a patch explaining things better for the other Hdiv 
> classes?
>
> Best,
> David
> --
> *From:* dea...@googlegroups.com  on behalf of 
> Konrad Simon 
> *Sent:* Monday, December 7, 2020 12:48 PM
> *To:* deal.II User Group 
> *Subject:* [deal.II] Div-conforming elements in 3D 
>  
> Dear Deal.ii community, 
>
> Sorry for spamming the mailing list again. I posted some of the below 
> stuff already in another post but that might have been with too many 
> unnecessary details and confusing ideas from my side.
>
> I am not sure if I stumbled over something and would like to report on 
> that. 
>
> Goal is to project a given function onto a finite element space over a 
> certain mesh. The focus here shall be on H(div)-conforming elements such as 
> Raviart-Thomas and Brezzi-Douglas-Marini Elements.
>
> I do so with several different meshes and I noticed an inconsistency in 
> the projection on meshes with, say, not so simple topology (e.g., holes and 
> voids). 
>
> Observations:
> 1. The problematic meshes do have faces with non-standard orientation. My 
> first thought was this was not carried over to the mapping of the 
> H(div)-basis but I was wrong. The mesh orientation is consistent (as far as 
> I can tell). A cube, for example, is not problematic. Please see two 
> example plots below.
>
> 2. The issue arises with both Raviart-Thomas and Brezzi-Douglas-Marini 
> Elements.
>
> 3. The issue arises in 3D only. 
>
> Any ideas what I ran into?
>
> Best,
> Konrad[image: plate_with_hole.png][image: hyper_shell.png]
>
> -- 
> 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/fa304b41-f83f-4c96-a2f7-c4e9e813553fn%40googlegroups.com
>  
> 
> .
>

-- 
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/2570e306-91b1-4d03-90fa-9a3777066264n%40googlegroups.com.


Re: [deal.II] Re: Parallel distributed hp solution transfer with FE_nothing

2020-12-09 Thread Kaushik Das
Hi Marc and Bruno,
I was able to reproduce this abort on an even simpler test. Please see the
attached file.

Initial grid:
 /*
* ---
* |  0 |  0 |
* ---
* |  1 |  1 | 0 - FEQ, 1 - FE_Nothing
* ---
*/

/* Set refine flags:
* ---
* |  R |  R |FEQ
* ---
* |  |  |FE_Nothing
* ---
*/

Then refine and solution trans. During the
execute_coarsening_and_refinement, it aborts.

Here is a stack trace:

An error occurred in line <1167> of file
 in
function
Number&
dealii::Vector::operator()(dealii::Vector::size_type) [with
Number = double; dealii::Vector::size_type = unsigned int]
The violated condition was:
static_cast::type)>:: type>(i) <
static_cast::type)>:: type>(size())
Additional information:
Index 0 is not in the half-open range [0,0). In the current case, this
half-open range is in fact empty, suggesting that you are accessing an
element of an empty collection such as a vector that has not been set to
the correct size.

Stacktrace:
---
#0  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
dealii::Vector::operator()(unsigned int)
#1  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
#2  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
dealii::parallel::distributed::SolutionTransfer<2,
dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>::pack_callback(dealii::TriaIterator > const&,
dealii::Triangulation<2, 2>::CellStatus)
#3  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
dealii::parallel::distributed::SolutionTransfer<2,
dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>::register_data_attach()::{lambda(dealii::TriaIterator > const&, dealii::Triangulation<2,
2>::CellStatus)#1}::operator()(dealii::TriaIterator > const&, dealii::Triangulation<2, 2>::CellStatus) const
#4  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
std::_Function_handler >
(dealii::TriaIterator > const&,
dealii::Triangulation<2, 2>::CellStatus),
dealii::parallel::distributed::SolutionTransfer<2,
dealii::PETScWrappers::MPI::Vector, dealii::hp::DoFHandler<2, 2>
>::register_data_attach()::{lambda(dealii::TriaIterator > const&, dealii::Triangulation<2,
2>::CellStatus)#1}>::_M_invoke(std::_Any_data const&,
dealii::TriaIterator > const&,
dealii::Triangulation<2, 2>::CellStatus&&)
#5  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
std::function >
(dealii::TriaIterator > const&,
dealii::Triangulation<2,
2>::CellStatus)>::operator()(dealii::TriaIterator > const&, dealii::Triangulation<2, 2>::CellStatus) const
#6  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
std::_Function_handler >
(dealii::TriaIterator >,
dealii::Triangulation<2, 2>::CellStatus), std::function > (dealii::TriaIterator >
const&, dealii::Triangulation<2, 2>::CellStatus)>
>::_M_invoke(std::_Any_data const&,
dealii::TriaIterator >&&,
dealii::Triangulation<2, 2>::CellStatus&&)
#7  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
std::function >
(dealii::TriaIterator >,
dealii::Triangulation<2,
2>::CellStatus)>::operator()(dealii::TriaIterator >, dealii::Triangulation<2, 2>::CellStatus) const
#8  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
dealii::parallel::distributed::Triangulation<2,
2>::DataTransfer::pack_data(std::vector::CellStatus,
dealii::TriaIterator > >,
std::allocator::CellStatus, dealii::TriaIterator > > > >
const&, std::vector >
(dealii::TriaIterator >,
dealii::Triangulation<2, 2>::CellStatus)>,
std::allocator >
(dealii::TriaIterator >,
dealii::Triangulation<2, 2>::CellStatus)> > > const&,
std::vector >
(dealii::TriaIterator >,
dealii::Triangulation<2, 2>::CellStatus)>,
std::allocator >
(dealii::TriaIterator >,
dealii::Triangulation<2, 2>::CellStatus)> > > const&)
#9  /lib/x86_64-linux-gnu/libdeal.ii.g.so.9.2.0:
dealii::parallel::distributed::Triangulation<2,
2>::execute_coarsening_and_refinement()
#10  /home/kdas/FE_NothingTest/build/test_distributed: main

Thank you very much,
Kaushik

On Tue, Dec 8, 2020 at 6:25 PM Marc Fehling  wrote:

> Hi Kaushik,
>
> the `p::d::SolutionTransfer` class should be able to deal with `FENothing`
> elements in your example. The tricky cases are when you're coarsening a
> `FENothing` element with others as Bruno already pointed out
> (h-coarsening), or if you change a `FENothing` element to a different
> element in the process (p-adaptation). But with your recent modification,
> you avoid these cases.
>
> I suspect that something else causes the error in your program. Could you
> run a debugger on this and give us the backtrace for the exception? This
> will give us more clues to figure out what goes wrong!
>
> Best,
> Marc
> On Tuesday, December 8, 2020 at 7:13:29 AM UTC-7 k.d...@gmail.com wrote:
>
>> Hi Bruno:
>> Thanks for pointing that out.
>> I tried to not refine FE_nothing cells by modifying the refine loop:
>> (The modified test is attached).
>>
>> for (auto  : dgq_dof_handler.active_cell_iterators())
>>   if (cell->is_locally_owned() && cell->active_fe_index () != 0)
>> {
>>

[deal.II] dealii on Apple M1

2020-12-09 Thread Alexey Ozeritskiy
Hi All,

Has anyone tried to compile dealii for Apple M1 ? Can you share your 
experience? I've tried to do this for version 9.2 without success.

-- 
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/21fe9dee-2c83-45e4-9626-1da3bd19a7fan%40googlegroups.com.