Re: [deal.II] Re: Finding unconnected regions in a triangulation

[Kaushik Das]

I see. thanks for the tip.

On Mon, Jul 10, 2023 at 1:07 PM Daniel Arndt  wrote:

> Kaushik,
>
> The implementation for those functions is pretty simple so it shouldn't be
> too hard to modify them to meet your needs, see
> https://dealii.org/current/doxygen/deal.II/grid__tools_8cc_source.html#l03828
> .
>
> Best,
> Daniel
>
> On Mon, Jul 10, 2023 at 1:01 PM Kaushik Das  wrote:
>
>> Hi   Bruno, thank you very much for your quick reply. This is what I was
>> looking for. Thanks. But I have another question, is there a way the
>> generate these graph by only considering a subset of cells from a
>> triangulation? Like cells that has a specific fe_index or material_id or
>> flags? Thank you.
>>
>> On Mon, Jul 10, 2023 at 11:43 AM Bruno Turcksin 
>> wrote:
>>
>>> Kaushik,
>>>
>>> You could use get_face_connectivity_of_cells()
>>> <https://dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a002fd376a184234ccbf5eca8f8fd7012>
>>> or get_vertex_connectivity_of_cells()
>>> <https://dealii.org/current/doxygen/deal.II/namespaceGridTools.html#ab54e2fb68484ddaedaab56de13323169>
>>> (depending on what you mean by connected) to have a sparsity pattern. This
>>> maps to a graph where the nodes are the cells, now you just need to check
>>> if the graph is connected see here
>>> <https://en.wikipedia.org/wiki/Connectivity_(graph_theory)#Computational_aspects>
>>>
>>> Best,
>>>
>>> Bruno
>>> On Monday, July 10, 2023 at 10:33:21 AM UTC-4 k.d...@gmail.com wrote:
>>>
>>>> Hi all,
>>>> Is there any way to find or count number of unconnected regions in a
>>>> triangulation. Triangulation will have non zero refinement levels.
>>>> Thanks,
>>>> Kaushik
>>>>
>>> --
>>> 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/gQH57TWRGP0/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> dealii+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/dealii/c77b5d42-9228-497a-ab2b-2ac25dc06fb7n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/dealii/c77b5d42-9228-497a-ab2b-2ac25dc06fb7n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CAC-fs6vmote0mqgCu7d60EjRrsAHpRPw-kSXeJJRtaFXg%2BXDtw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/dealii/CAC-fs6vmote0mqgCu7d60EjRrsAHpRPw-kSXeJJRtaFXg%2BXDtw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/gQH57TWRGP0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/CAOYDWbKH7hTA9PhQ8kE%2Bx8eUONPLjqGMCipEnWF9UYpKbLvX1g%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAOYDWbKH7hTA9PhQ8kE%2Bx8eUONPLjqGMCipEnWF9UYpKbLvX1g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAC-fs6t3jSRmm7PmTN_21rpRP%3DUazcT1p1nk28KGojBt-Q8jqg%40mail.gmail.com.

Re: [deal.II] Re: Finding unconnected regions in a triangulation

[Kaushik Das]

Hi   Bruno, thank you very much for your quick reply. This is what I was
looking for. Thanks. But I have another question, is there a way the
generate these graph by only considering a subset of cells from a
triangulation? Like cells that has a specific fe_index or material_id or
flags? Thank you.

On Mon, Jul 10, 2023 at 11:43 AM Bruno Turcksin 
wrote:

> Kaushik,
>
> You could use get_face_connectivity_of_cells()
> 
> or get_vertex_connectivity_of_cells()
> 
> (depending on what you mean by connected) to have a sparsity pattern. This
> maps to a graph where the nodes are the cells, now you just need to check
> if the graph is connected see here
> 
>
> Best,
>
> Bruno
> On Monday, July 10, 2023 at 10:33:21 AM UTC-4 k.d...@gmail.com wrote:
>
>> Hi all,
>> Is there any way to find or count number of unconnected regions in a
>> triangulation. Triangulation will have non zero refinement levels.
>> Thanks,
>> Kaushik
>>
> --
> 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/gQH57TWRGP0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/c77b5d42-9228-497a-ab2b-2ac25dc06fb7n%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/CAC-fs6vmote0mqgCu7d60EjRrsAHpRPw-kSXeJJRtaFXg%2BXDtw%40mail.gmail.com.

[deal.II] Finding unconnected regions in a triangulation

[Kaushik Das]

Hi all,
Is there any way to find or count number of unconnected regions in a 
triangulation. Triangulation will have non zero refinement levels. 
Thanks,
Kaushik 

-- 
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/6cedc1e1-fa5e-4f31-9281-e819d0a7a594n%40googlegroups.com.

[deal.II] Re: Building with TRILINOS and SEACUS

[Kaushik Das]

Hi all,
I was able to build dealii with Trilinous by first building 
trillions-release-13-4-1 
instead of the latest Trilinos version. 

On Saturday, March 18, 2023 at 5:01:22 PM UTC-4 Kaushik Das wrote:

> Hello all,
> I built Trilinos from source on a RedHat 7.9 enterprise server and then 
> tried to building deallii with Trilinos support but I keep getting errors 
> like this one below: 
>
> -- Enabled Kokkos devices: SERIAL
> -- Found EPETRA_CONFIG_H
> -- TRILINOS_LIBRARY_ROL::all_libs not found! The call was:
> -- FIND_LIBRARY(TRILINOS_LIBRARY_ROL::all_libs NAMES ROL::all_libs 
> HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
> NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
> -- TRILINOS_LIBRARY_Tempus::all_libs not found! The call was:
> -- FIND_LIBRARY(TRILINOS_LIBRARY_Tempus::all_libs NAMES 
> Tempus::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH 
> NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH 
> NO_CMAKE_FIND_ROOT_PATH)
>
> ... (similar errors) 
>
> _CMAKE_FIND_ROOT_PATH)
> -- TRILINOS_LIBRARY_KokkosCore::all_libs not found! The call was:
> -- FIND_LIBRARY(TRILINOS_LIBRARY_KokkosCore::all_libs NAMES 
> KokkosCore::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH 
> NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH 
> NO_CMAKE_FIND_ROOT_PATH)
> -- TRILINOS_LIBRARY_Gtest::all_libs not found! The call was:
> -- FIND_LIBRARY(TRILINOS_LIBRARY_Gtest::all_libs NAMES Gtest::all_libs 
> HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
> NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
> --   TRILINOS_VERSION: 14.1
> --   TRILINOS_LIBRARIES: *** Required variable 
> "TRILINOS_LIBRARY_ROL::all_libs" set to NOTFOUND ***
> --   TRILINOS_LIBRARIES: *** Required variable 
> "TRILINOS_LIBRARY_Tempus::all_libs" set to NOTFOUND ***
> --   TRILINOS_LIBRARIES: *** Required variable 
> "TRILINOS_LIBRARY_MueLu::all_libs" set to NOTFOUND ***
>
>
> But I do have those libraries built and installed in the default location
>
> $ ls -l /usr/local/lib/libkokkosalgorithms.so*
> lrwxrwxrwx. 1 root root25 Mar 18 12:24 
> /usr/local/lib/libkokkosalgorithms.so -> libkokkosalgorithms.so.14
> lrwxrwxrwx. 1 root root27 Mar 18 12:24 
> /usr/local/lib/libkokkosalgorithms.so.14 -> libkokkosalgorithms.so.14.1
> -rwxr-xr-x. 1 root root 15288 Mar 18 12:02 
> /usr/local/lib/libkokkosalgorithms.so.14.1
>
> $ ls -l /usr/local/lib/librol*
> lrwxrwxrwx. 1 root root12 Mar 18 12:24 /usr/local/lib/librol.so -> 
> librol.so.14
> lrwxrwxrwx. 1 root root14 Mar 18 12:24 /usr/local/lib/librol.so.14 -> 
> librol.so.14.1
> -rwxr-xr-x. 1 root root 19560 Mar 18 12:24 /usr/local/lib/librol.so.14.1
>
> $ ls -l /usr/local/lib/*empus*
> lrwxrwxrwx. 1 root root  15 Mar 18 12:24 /usr/local/lib/libtempus.so 
> -> libtempus.so.14
> lrwxrwxrwx. 1 root root  17 Mar 18 12:24 
> /usr/local/lib/libtempus.so.14 -> libtempus.so.14.1
> -rwxr-xr-x. 1 root root 7116480 Mar 18 12:23 
> /usr/local/lib/libtempus.so.14.1
>
>
>
>

-- 
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/7e21555f-152c-4ed3-828f-5e1dc95595c7n%40googlegroups.com.

Re: [deal.II] Open source finite element preprocessor

[Kaushik Das]

Thank you Marco. Trame looks promising.
-Kaushik

On Wed, Jan 18, 2023 at 11:40 AM Marco Nawijn 
wrote:

> Hi,
>
> Maybe Trame is an option for you?
> You have to build something yourself, but a lot of the complexity is
> hidden.
>
> https://kitware.github.io/trame/
>
> Marco
>
> On Wed, Jan 18, 2023, 4:05 PM Kaushik Das  wrote:
>
>> Hi all,
>> I have been using deal.ii for a while. I would like to create a simple
>> but customized preprocessor for my deal.ii application.
>>
>> Please suggest any customizable open-source FE analysis preprocessor that
>> I can use as a base to build on.
>>
>> I am looking for something that will visualize 3D geometry, and have some
>> basic picking (registering x,y,z of mouse clicks), and UI functionality.
>> This UI will write a prm file that can then be sent to deal.ii.
>>
>> I am looking for something that is dealii_parameter_gui + 3D geometry
>> visualization + mousing click picking.
>>
>> I am not looking for a mesh generator. I generate mesh using deal.ii
>> functionality. I am not looking for a post-processor or results visualizer,
>> I am very happy to use ParaView for post-processing.
>>
>> Thank you very much for your help.
>> Kaushik
>>
>> --
>> 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/ec3dc317-2c03-46c6-8626-5b5d9f1c7e4en%40googlegroups.com
>> <https://groups.google.com/d/msgid/dealii/ec3dc317-2c03-46c6-8626-5b5d9f1c7e4en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/I2_r4dUXKK4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/CABCJ_1KfcuArYAqx0q1tQEzUbwobki9S4LyP3Bav1AQ4fdbq6Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CABCJ_1KfcuArYAqx0q1tQEzUbwobki9S4LyP3Bav1AQ4fdbq6Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAC-fs6uYc3cQ9ZqbnshYbZbjBZafQ1iaFM5bwfcQY%3D6KM%3DzHJw%40mail.gmail.com.

[deal.II] Building with TRILINOS and SEACUS

[Kaushik Das]

Hello all,
I built Trilinos from source on a RedHat 7.9 enterprise server and then 
tried to building deallii with Trilinos support but I keep getting errors 
like this one below: 

-- Enabled Kokkos devices: SERIAL
-- Found EPETRA_CONFIG_H
-- TRILINOS_LIBRARY_ROL::all_libs not found! The call was:
-- FIND_LIBRARY(TRILINOS_LIBRARY_ROL::all_libs NAMES ROL::all_libs 
HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
-- TRILINOS_LIBRARY_Tempus::all_libs not found! The call was:
-- FIND_LIBRARY(TRILINOS_LIBRARY_Tempus::all_libs NAMES 
Tempus::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH 
NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH 
NO_CMAKE_FIND_ROOT_PATH)

... (similar errors) 

_CMAKE_FIND_ROOT_PATH)
-- TRILINOS_LIBRARY_KokkosCore::all_libs not found! The call was:
-- FIND_LIBRARY(TRILINOS_LIBRARY_KokkosCore::all_libs NAMES 
KokkosCore::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH 
NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH 
NO_CMAKE_FIND_ROOT_PATH)
-- TRILINOS_LIBRARY_Gtest::all_libs not found! The call was:
-- FIND_LIBRARY(TRILINOS_LIBRARY_Gtest::all_libs NAMES Gtest::all_libs 
HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH 
NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH)
--   TRILINOS_VERSION: 14.1
--   TRILINOS_LIBRARIES: *** Required variable 
"TRILINOS_LIBRARY_ROL::all_libs" set to NOTFOUND ***
--   TRILINOS_LIBRARIES: *** Required variable 
"TRILINOS_LIBRARY_Tempus::all_libs" set to NOTFOUND ***
--   TRILINOS_LIBRARIES: *** Required variable 
"TRILINOS_LIBRARY_MueLu::all_libs" set to NOTFOUND ***


But I do have those libraries built and installed in the default location

$ ls -l /usr/local/lib/libkokkosalgorithms.so*
lrwxrwxrwx. 1 root root25 Mar 18 12:24 
/usr/local/lib/libkokkosalgorithms.so -> libkokkosalgorithms.so.14
lrwxrwxrwx. 1 root root27 Mar 18 12:24 
/usr/local/lib/libkokkosalgorithms.so.14 -> libkokkosalgorithms.so.14.1
-rwxr-xr-x. 1 root root 15288 Mar 18 12:02 
/usr/local/lib/libkokkosalgorithms.so.14.1

$ ls -l /usr/local/lib/librol*
lrwxrwxrwx. 1 root root12 Mar 18 12:24 /usr/local/lib/librol.so -> 
librol.so.14
lrwxrwxrwx. 1 root root14 Mar 18 12:24 /usr/local/lib/librol.so.14 -> 
librol.so.14.1
-rwxr-xr-x. 1 root root 19560 Mar 18 12:24 /usr/local/lib/librol.so.14.1

$ ls -l /usr/local/lib/*empus*
lrwxrwxrwx. 1 root root  15 Mar 18 12:24 /usr/local/lib/libtempus.so -> 
libtempus.so.14
lrwxrwxrwx. 1 root root  17 Mar 18 12:24 /usr/local/lib/libtempus.so.14 
-> libtempus.so.14.1
-rwxr-xr-x. 1 root root 7116480 Mar 18 12:23 
/usr/local/lib/libtempus.so.14.1



-- 
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/de7d3d89-b51b-4498-8d50-9b860c925e2cn%40googlegroups.com.

[deal.II] Open source finite element preprocessor

[Kaushik Das]

Hi all,
I have been using deal.ii for a while. I would like to create a simple but 
customized preprocessor for my deal.ii application. 

Please suggest any customizable open-source FE analysis preprocessor that I 
can use as a base to build on. 

I am looking for something that will visualize 3D geometry, and have some 
basic picking (registering x,y,z of mouse clicks), and UI functionality. 
This UI will write a prm file that can then be sent to deal.ii. 

I am looking for something that is dealii_parameter_gui + 3D geometry 
visualization + mousing click picking.

I am not looking for a mesh generator. I generate mesh using deal.ii 
functionality. I am not looking for a post-processor or results visualizer, 
I am very happy to use ParaView for post-processing. 

Thank you very much for your help.
Kaushik 

-- 
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/ec3dc317-2c03-46c6-8626-5b5d9f1c7e4en%40googlegroups.com.

Re: [deal.II] Dividing up IteratorRange into chunks

[Kaushik Das]

Thank you very much for catching the mistake. 
It is working now.

As for the  Threads::split_range
I am getting a compilation error. 
Something like std pair cannot be created for 
FilteredIterator>>>

Is these utility methods in the Threads namespace available even if I build 
deal.ii without TBB support?

Thanks,
Kaushik 
On Saturday, June 11, 2022 at 6:41:27 PM UTC-4 Wolfgang Bangerth wrote:

> On 6/10/22 15:11, Kaushik Das wrote:
> > for (size_t i = 0; i <  total_cell_count   ; i += chunkSize)
> >  {
> > for (auto j = i; j < std::min(i + chunkSize, 
> total_task_count); j++)
>
> The mistake is here: It should have been
> std::min(..., total_cell_count)
> instead of
> std::min(..., total_task_count)
>
> That said, there is also this function that already does what you require:
>
>
> https://dealii.org/developer/doxygen/deal.II/group__threads.html#ga86c4f26c4dacddd38ee225dd1796d7e1
>
> 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/656fdb7c-8fa2-498b-a758-76cfcf70967fn%40googlegroups.com.

[deal.II] Dividing up IteratorRange into chunks

[Kaushik Das]

Hi all,

I want to divide an IteratorRange into smaller chunks and then run some 
tasks on those smaller ItegratorRanges. 

I tried to do this as follows:

const auto  LargeRangeOfCells = 
filter_iterators(m_triangulation.active_cell_iterators(),
  
 IteratorFilters::LocallyOwnedCell());
size_t total_cell_count = std::distance( LargeRangeOfCells.begin(),  
LargeRangeOfCells.end());
auto start_cell =  LargeRangeOfCells.begin();
auto end_cell = start_cell;
for (size_t i = 0; i <  total_cell_count   ; i += chunkSize)
 {
for (auto j = i; j < std::min(i + chunkSize, total_task_count); 
j++)
{
++end_cell;
}
IteratorRange SmallRangeOfCells(*start_cell, *end_cell);
AddToTaskQueue(tasksOnCells( SmallRangeOfCells);
start_cell = end_cell;
}

But at one cell inside the method tasksOnCells, this assert fails:

An error occurred in line <996> of file 
 in function
const Accessor& dealii::TriaRawIterator::operator*() const 
[with Accessor = dealii::CellAccessor<3, 3>]
The violated condition was: 
Accessor::structure_dimension != Accessor::dimension || state() == 
IteratorState::valid
Additional information: 
You tried to dereference a cell iterator for which this is not 
possible. More information on this iterator: level=-1, index=-1, 
state=past_the_end

What is the correct way to divide a filtered iterator range?

Thanks,
Kaushik  

-- 
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/5157dc77-caa1-479a-911f-df6d0c547e04n%40googlegroups.com.

Re: [deal.II] Re: Meshing complex geometries

[Kaushik Das]

Hi Peter,
Yes, I am using isotropic refinement. For some geometries, using
anisotropic refinement, I may be able to keep the problem size smaller. I
am also experimenting with using p::d::triangulation, and there is a
limitation that anisotropic refinement does not work with
p::d::triangulation.
Ideally, I would like to use anisotropic refinement with hp::FECollection
on p::d::triangulation. My problems sizes are often > 3M DOFs and they are
transient heat transfer problems that take 10s hr to a few days on 32
CPUs.
Thanks for the help.
Kaushik

On Sun, Nov 7, 2021 at 8:34 AM Peter Munch  wrote:

> Hi Kaushik,
>
> > Is there a plan for relaxing this limitation in the future? Is there
> any other way to do this?
>
> Unfortunately, there are currently no active developments regarding
> anisotropic refinement. Would it be an option to refine isotropically?
> Latter works very well parllel::distributed::Triangulation in parallel.
>
> PM
>
> On Sunday, 7 November 2021 at 13:48:04 UTC+1 k.d...@gmail.com wrote:
>
>> Forgot to attach the figure. Here it is.
>>
>> On Sunday, November 7, 2021 at 7:45:02 AM UTC-5 Kaushik Das wrote:
>>
>>> Hi all,
>>> I am trying to mesh a complex geometry by first creating a triangulation
>>> of the bounding box of the geometry and then successively refining the
>>> cells that are within the geometry.  I use a hp::FECollection to assign  
>>> FE_Nothing()
>>> to cells that are outside the boundary and FE_Q(1) to cells inside
>>> the geometry. Please see the attached figure, which shows only FE_Q cells.
>>> A limitation that I am facing is I cannot use an anisotropic refinement
>>> case because make_hanging_node_constraints does not support
>>> hp::FECollection.
>>> Is there a plan for relaxing this limitation in the future? Is there any
>>> other way to do this?
>>> I want to keep the axis-aligned nature of cells that are generated this
>>> way. It is an additive manufacturing application. Therefore, using an
>>> external tet mesh generator is not a good option for me.
>>> Thanks,
>>> Kaushik
>>>
>> --
> 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/agfsxb_wKqM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/652623a8-1308-4cce-93b0-79c646a0410bn%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/652623a8-1308-4cce-93b0-79c646a0410bn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAC-fs6vsKkEq-wRKur7Zhc78rdbzcCHhaOCUoPJUYABvg4LT5Q%40mail.gmail.com.

[deal.II] Re: Meshing complex geometries

[Kaushik Das]

Forgot to attach the figure. Here it is. 

On Sunday, November 7, 2021 at 7:45:02 AM UTC-5 Kaushik Das wrote:

> Hi all,
> I am trying to mesh a complex geometry by first creating a triangulation 
> of the bounding box of the geometry and then successively refining the 
> cells that are within the geometry.  I use a hp::FECollection to assign  
> FE_Nothing() 
> to cells that are outside the boundary and FE_Q(1) to cells inside 
> the geometry. Please see the attached figure, which shows only FE_Q cells. 
> A limitation that I am facing is I cannot use an anisotropic refinement 
> case because make_hanging_node_constraints does not support 
> hp::FECollection. 
> Is there a plan for relaxing this limitation in the future? Is there any 
> other way to do this?
> I want to keep the axis-aligned nature of cells that are generated this 
> way. It is an additive manufacturing application. Therefore, using an 
> external tet mesh generator is not a good option for me. 
> Thanks,
> Kaushik 
>

-- 
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/3a161d85-2b20-4200-b995-6b67e9eca15an%40googlegroups.com.

[deal.II] Meshing complex geometries

[Kaushik Das]

Hi all,
I am trying to mesh a complex geometry by first creating a triangulation of 
the bounding box of the geometry and then successively refining the cells 
that are within the geometry.  I use a hp::FECollection to assign  
FE_Nothing() 
to cells that are outside the boundary and FE_Q(1) to cells inside the 
geometry. Please see the attached figure, which shows only FE_Q cells. 
A limitation that I am facing is I cannot use an anisotropic refinement 
case because make_hanging_node_constraints does not support 
hp::FECollection. 
Is there a plan for relaxing this limitation in the future? Is there any 
other way to do this?
I want to keep the axis-aligned nature of cells that are generated this 
way. It is an additive manufacturing application. Therefore, using an 
external tet mesh generator is not a good option for me. 
Thanks,
Kaushik 

-- 
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/3cd958f2-a479-49d7-8d53-6367c46bef21n%40googlegroups.com.

Re: [deal.II] Map from dof index to vertex index

[Kaushik Das]

Thank you, Prof. Bangerth.
Yes, I am using Q1 elements.
I was able to do it following your hint.
I am assuming that the ordering/sequence of dofs that we get
from cell->get_dof_indices() will always be the same as the
ordering/sequence of vertexes in a cell, that is the 'canonical' ordering
given in GeometryInfo. Will that be true for linear hex Q1 elements always?

Thank you very much,
Kaushik

On Thu, Jul 15, 2021 at 6:30 PM Wolfgang Bangerth 
wrote:

> On 7/15/21 3:09 PM, Kaushik Das wrote:
> >
> > Is there a way to know which dof_index is located at which vertex.
> >
> > For example, I want to "map" a dof_index that I get from
> > affine_constrains.get_constraint_entries(line);
> >
> > to a vertex index that are in the range of triangulation.begin_vertex()
> and
> > triangulation.end_vertex().
>
> Kaushik,
> there is no such way in the library because, in general, DoFs need not be
> located on vertices. That is only true for the Q1 element.
>
> But if you look at the implementation of the
> DoFTools::map_dofs_to_support_points(), you can probably come up with a
> way to
> get what you are looking, assuming you really are only using Q1 elements.
>
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/cNZzfrSjTF4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/b963d470-97f9-f79a-3ab8-4c31dbb70c94%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/CAC-fs6v2o-NfpbXRe6EitAD%3DXftE_R5EsZn2Tf%3DDwy5kQPE5ZQ%40mail.gmail.com.

[deal.II] Map from dof index to vertex index

[Kaushik Das]

Hello,

Is there a way to know which dof_index is located at which vertex. 

For example, I want to "map" a dof_index that I get from 
affine_constrains.get_constraint_entries(line);

to a vertex index that are in the range of triangulation.begin_vertex() and 
triangulation.end_vertex().

Thank you,
Kaushik 

-- 
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/3875a9eb-a3cd-428a-a104-cf7fe2ac60e2n%40googlegroups.com.

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

[Kaushik Das]

Hello Prof. Bangerth and others,

Thanks to all of you, I can write a small test that seems to be doing what
I want following Marc's suggestion. But I have a few questions (the test
code is attached)

   -  cell->set_dof_values(local_data, m_completely_distributed_solution);

Does set_dof_values set entries in m_completely_distributed_solution that
are not owned by the current rank?

   - m_completely_distributed_solution.compress(VectorOperation::insert);

After  set_dof_values, if I call  compress(VectorOperation::insert) on that
PETSc vector, now, does that mean that I now have entries in that
distributed vector that are not owned by the current rank?

   - m_locally_relevant_solution = m_completely_distributed_solution;

Will this assignment of a distributed vector to a locally relevant vector
correctly set the ghost values?

If this test code is correct, it will be great to add this as a test to
deal.ii. My current work will be dependent on this part working correctly,
and it will be nice to have a test that can alert us if something changes
in the future.

Thank you very much,
Kaushik


On Mon, Jan 4, 2021 at 4:54 PM Wolfgang Bangerth 
wrote:

>
> Kaushik
> Marc and others have already answered the technical details, so just one
> overall comment:
>
> > Let me explain what I am trying to do and why.
> > I want to solve a transient heat transfer problem of the additive
> > manufacturing (AM) process. In AM processes, metal powder is deposited
> in
> > layers, and then a laser source scans each layer and melts and bonds the
> > powder to the layer underneath it. To simulate this layer by layer
> process, I
> > want to start with a grid that covers all the layers, but initially,
> only the
> > bottom-most layer is active and all other layers are inactive, and then
> as
> > time progresses, I want to activate one layer at a time. I read on this
> > mailing list that cell "birth" or "activation" can be done by changing a
> cell
> > from FE_Nothing to FE_Q using p-refinement. I was trying to keep all
> cells of
> > the grid initially to FE_Nothing except the bottom-most layer. And then
> > convert one layer at a time to FE_Q. My questions are:
> > 1. Does this make sense?
>
> Yes, this is how I would do things as well. It is quite possible that
> nobody
> has ever tried this, and that some of the steps don't work without further
> modification -- but whatever doesn't work should be treated as either a
> missing feature, or a bug. The general approach is sound.
>
> When I try to build a code with a work flow that is not quite standard, I
> (like you) frequently run into things that don't quite work. My usual
> approach
> is then to write a small and self-contained test case that illustrates the
> issue without the overhead of the actual application. Most of the time,
> one
> can show the issue with <100 lines of code. This then goes into a github
> issue
> so that one can write a fix for this particular problem without having to
> understand the overall code architecture, the application, etc. I would
> encourage you to follow this kind of work-flow!
>
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/ssEva6C2PU8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/5ebefd8a-5dde-603e-76d1-6967c7783504%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/CAC-fs6sJ-GLAumx6YqiXMDbG3kQeg3Xzy_mQzZ4t%3DLhkM_xdFQ%40mail.gmail.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 

//
//  Including cell_data_transfer.h did not work. Had to include 
cell_data_transfer.templates.h why?
//
//#include 
#include 

namespace LA
{
#if defined(DEAL_II_WITH_PETSC) && !defined(DEAL_II_PETSC_WITH_COMPLEX) && \

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

[Kaushik Das]

Hi Bruno,
Thanks for the help. I just saw in your online profile that you were in
Texas A, I was a post-doc at Aerospace TAMU 2009-12, small world!
Can use I a dealii::LinearAlgebra::distributed::Vector with the PETSc
solver? If not then, I think I have to copy the solution from a PETSc
vector to a dealii vector after the solution in every time step.
thanks,
Kaushik

On Sun, Jan 3, 2021 at 8:35 PM Bruno Turcksin 
wrote:

> Kaushik,
>
> I am working on the exact same problem for the same application :-)
> PETSc Vector do not support compress(min) You need to use a
> dealii::LinearAlgebra::distributed::Vector instead.
>
> Best,
>
> Bruno
>
> Le sam. 2 janv. 2021 à 18:38, Kaushik Das  a écrit :
> >
> > Hi Marc,
> > I tried using cell data transfer as you suggested.
> > But I am having trouble in calling compress after getting the
> transferred data to a PETSc Vector:
> > My test code is attached. My confusion is mainly when to call to
> compress after the cell data transfer.
> >
> > m_completely_distributed_solution =
> std::numeric_limits::max();
> >
> > std::vector>
> transferred_data(m_triangulation.n_active_cells());
> > m_cell_data_trans.unpack(transferred_data);
> >
> > i = 0;
> > for (auto  : m_dof_handler.active_cell_iterators())
> > {
> > std::vector cell_data = transferred_data[i];
> > if (cell_data.size() != 0)
> > {
> > Vector
> local_data(GeometryInfo<2>::vertices_per_cell);
> > for (unsigned int j = 0; j <
> GeometryInfo<2>::vertices_per_cell; j++)
> > {
> > local_data = cell_data[j];
> > }
> > cell->set_dof_values_by_interpolation(local_data,
> m_completely_distributed_solution);
> > }
> > i++;
> > }
> >
> >
>  //m_completely_distributed_solution.compress(VectorOperation::min); //
> calling compress aborts here
> >
> > for (unsigned int i = 0; i <
> m_completely_distributed_solution.size(); ++i)
> > if (m_completely_distributed_solution(i) ==
> std::numeric_limits::max())
> > m_completely_distributed_solution(i) = 2; // 2 is the
> initial condition I want apply to newly created dofs
> >
> >//
> m_completely_distributed_solution.compress(VectorOperation::min); // aborts
> here too Missing compress() or calling with wrong VectorOperation argument.
> > // exchange_cell_data_to_ghosts ??
> > m_locally_relevant_solution = m_completely_distributed_solution;
> >
> >
> > Calling compress from either of those two places results in exceptions:
> > An error occurred in line <387> of file
>  in function
> > void
> dealii::PETScWrappers::VectorBase::compress(dealii::VectorOperation::values)
> > The violated condition was:
> > last_action == ::dealii::VectorOperation::unknown || last_action ==
> operation
> > Additional information:
> > Missing compress() or calling with wrong VectorOperation argument.
> >
> >
> >
> > Thank you very much for your help.
> > Happy New year,
> > Kaushik
> >
> >
> >
> > On Sat, Jan 2, 2021 at 9:55 AM Kaushik Das  wrote:
> >>
> >> Thank you.
> >> I will try CellDataTransfer method as you suggested.
> >> The test code that I attached earlier has a mistake.
> cell->set_active_fe_index(0) should be protected by a if
> (cell->is_locally_owned()). I have attached a corrected test here.
> >> Thanks,
> >> Kaushik
> >>
> >> On Thu, Dec 31, 2020 at 8:05 PM Marc Fehling 
> wrote:
> >>>
> >>> Kaushik,
> >>>
> >>> in addition to what I just wrote, your example from above has revealed
> a bug in the `p::d::SolutionTransfer` class that Wolfgang and I were
> discussing in the course of this chatlog. Thank you very much for this! We
> are working on a solution for this issue.
> >>>
> >>> I would encourage you to use the `p::d::CellDataTransfer` class for
> your use case as described in the last message.
> >>>
> >>> Marc
> >>>
> >>> On Thursday, December 31, 2020 at 6:02:00 PM UTC-7 Marc Fehling wrote:
> >>>>
> >>>> Hi Kaushik,
> >>>>
> >>>> Yes, this is possible by changing a cell from FE_Nothing to FE_Q
> using p-refinement.
> >>>>
> >>>> You can do this with t

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

[Kaushik Das]

Hi Marc,
I tried using cell data transfer as you suggested.
But I am having trouble in calling compress after getting the
transferred data to a PETSc Vector:
My test code is attached. My confusion is mainly when to call to
compress after the cell data transfer.

m_completely_distributed_solution =
std::numeric_limits::max();

std::vector>
transferred_data(m_triangulation.n_active_cells());
m_cell_data_trans.unpack(transferred_data);

i = 0;
for (auto  : m_dof_handler.active_cell_iterators())
{
std::vector cell_data = transferred_data[i];
if (cell_data.size() != 0)
{
Vector
local_data(GeometryInfo<2>::vertices_per_cell);
for (unsigned int j = 0; j <
GeometryInfo<2>::vertices_per_cell; j++)
{
local_data = cell_data[j];
}
cell->set_dof_values_by_interpolation(local_data,
m_completely_distributed_solution);
}
i++;
}

//m_completely_distributed_solution.compress(VectorOperation::min);
// calling compress aborts here

for (unsigned int i = 0; i <
m_completely_distributed_solution.size(); ++i)
if (m_completely_distributed_solution(i) ==
std::numeric_limits::max())
m_completely_distributed_solution(i) = 2; // 2 is the
initial condition I want apply to newly created dofs

   // m_completely_distributed_solution.compress(VectorOperation::min);
// aborts here too Missing compress() or calling with wrong VectorOperation
argument.
// exchange_cell_data_to_ghosts ??
m_locally_relevant_solution = m_completely_distributed_solution;


Calling compress from either of those two places results in exceptions:
An error occurred in line <387> of file
 in function
void
dealii::PETScWrappers::VectorBase::compress(dealii::VectorOperation::values)
The violated condition was:
last_action == ::dealii::VectorOperation::unknown || last_action ==
operation
Additional information:
Missing compress() or calling with wrong VectorOperation argument.



Thank you very much for your help.
Happy New year,
Kaushik



On Sat, Jan 2, 2021 at 9:55 AM Kaushik Das  wrote:

> Thank you.
> I will try CellDataTransfer method as you suggested.
> The test code that I attached earlier has a
> mistake. cell->set_active_fe_index(0) should be protected by a if
> (cell->is_locally_owned()). I have attached a corrected test here.
> Thanks,
> Kaushik
>
> On Thu, Dec 31, 2020 at 8:05 PM Marc Fehling  wrote:
>
>> Kaushik,
>>
>> in addition to what I just wrote, your example from above has revealed a
>> bug in the `p::d::SolutionTransfer` class that Wolfgang and I were
>> discussing in the course of this chatlog. Thank you very much for this! We
>> are working on a solution for this issue.
>>
>> I would encourage you to use the `p::d::CellDataTransfer` class for your
>> use case as described in the last message.
>>
>> Marc
>>
>> On Thursday, December 31, 2020 at 6:02:00 PM UTC-7 Marc Fehling wrote:
>>
>>> Hi Kaushik,
>>>
>>> Yes, this is possible by changing a cell from FE_Nothing to FE_Q using
>>> p-refinement.
>>>
>>> You can do this with the method described in #11132
>>> <https://github.com/dealii/dealii/pull/11132>: Imitate what
>>> p::d::SolutionTransfer is doing with the more versatile tool
>>> p::d::CellDataTransfer and consider the following:
>>>
>>>- Prepare a data container like `Vector>` where the
>>>outer layer represents each cell in the current mesh, and the inner layer
>>>corresponds to the dof values inside each cell.
>>>- Prepare data for the updated grid on the old grid.
>>>   - On already activated cells, store dof values with
>>>   `cell->get_interpolated_dof_values()`.
>>>   - On all other cells, store an empty container.
>>>   - Register your data container for and execute coarsening and
>>>refinement.
>>>- Interpolate the old solution on the new mesh.
>>>- Initialize your new solution vector with invalid values
>>>   `std::numeric_limits::infinity`.
>>>   - On previously activated cells, extract the stored data with
>>>   `cell->set_dof_values_by_interpolation()`.
>>>   - Skip all other cells which only have an empty container.
>>>- On non-ghosted solution vectors, call
>>>`compress(VectorOperation::min)` to get correct values on ghost cells.
>>>
>>> This leaves you with a correctly interpolated solution on the new mesh,
>>> where all newly activated dofs hav

Re: [deal.II] Build problem version 9.3.0-pre

[Kaushik Das]

update: I deleted the build folder and then run the cmake configuration
again. Then make install. That solved the problem. Thanks.

On Sat, Jan 2, 2021 at 10:01 AM Kaushik Das  wrote:

> Hi all:
>
> I have been building deal.ii via a github fork for last few months
> successfully., This morning I did a  git fetch upstream and then git merge
> upstream/master and I am getting a number of build errors.
> Any idea what I may be doing wrong?
> Here is my config and the build errors.
>
> ###
> #
> #  deal.II configuration:
> #CMAKE_BUILD_TYPE:   DebugRelease
> #BUILD_SHARED_LIBS:  ON
> #CMAKE_INSTALL_PREFIX:   /home/kdas/dealii/install
> #CMAKE_SOURCE_DIR:   /home/kdas/dealii
> #(version 9.3.0-pre, shortrev 67887ee247)
> #CMAKE_BINARY_DIR:   /home/kdas/dealii/build
> #CMAKE_CXX_COMPILER: GNU 9.3.0 on platform Linux x86_64
> #/usr/bin/c++
> #
> #  Configured Features (DEAL_II_ALLOW_BUNDLED = ON,
> DEAL_II_ALLOW_AUTODETECTION = ON):
> #  ( DEAL_II_WITH_64BIT_INDICES = OFF )
> #  ( DEAL_II_WITH_ADOLC = OFF )
> #DEAL_II_WITH_ARPACK set up with external dependencies
> #DEAL_II_WITH_ASSIMP set up with external dependencies
> #DEAL_II_WITH_BOOST set up with external dependencies
> #DEAL_II_WITH_COMPLEX_VALUES = ON
> #  ( DEAL_II_WITH_CUDA = OFF )
> #  ( DEAL_II_WITH_GINKGO = OFF )
> #DEAL_II_WITH_GMSH set up with external dependencies
> #DEAL_II_WITH_GSL set up with external dependencies
> #  ( DEAL_II_WITH_HDF5 = OFF )
> #DEAL_II_WITH_LAPACK set up with external dependencies
> #DEAL_II_WITH_METIS set up with external dependencies
> #DEAL_II_WITH_MPI set up with external dependencies
> #DEAL_II_WITH_MUPARSER set up with external dependencies
> #DEAL_II_WITH_OPENCASCADE set up with external dependencies
> #DEAL_II_WITH_P4EST set up with external dependencies
> #DEAL_II_WITH_PETSC set up with external dependencies
> #DEAL_II_WITH_SCALAPACK set up with external dependencies
> #  ( DEAL_II_WITH_SIMPLEX_SUPPORT = OFF )
> #  ( DEAL_II_WITH_SLEPC = OFF )
> #  ( DEAL_II_WITH_SUNDIALS = OFF )
> #  ( DEAL_II_WITH_SYMENGINE = OFF )
> #DEAL_II_WITH_TASKFLOW set up with bundled packages
> #DEAL_II_WITH_TBB set up with external dependencies
> #DEAL_II_WITH_TRILINOS set up with external dependencies
> #DEAL_II_WITH_UMFPACK set up with external dependencies
> #DEAL_II_WITH_ZLIB set up with external dependencies
> #
> #  Component configuration:
> #  ( DEAL_II_COMPONENT_DOCUMENTATION = OFF )
> #DEAL_II_COMPONENT_EXAMPLES
> #  ( DEAL_II_COMPONENT_PACKAGE = OFF )
> #  ( DEAL_II_COMPONENT_PYTHON_BINDINGS = OFF )
> #
> #  Detailed information (compiler flags, feature configuration) can be
> found in detailed.log
> #
> #  Run  $ make info  to print a help message with a list of top level
> targets
> #
> ###
>
> [ 15%] Building CXX object source/fe/CMakeFiles/obj_fe_debug.dir/fe.cc.o
> /home/kdas/dealii/source/fe/fe.cc:1290:13: error: ‘QCollection’ in
> namespace ‘dealii::hp’ does not name a template type; did you mean
> ‘FECollection’?
>  1290 |   const hp::QCollection ,
>   | ^~~
>   | FECollection
> /home/kdas/dealii/source/fe/fe.cc:1290:24: error: expected ‘,’ or ‘...’
> before ‘<’ token
>  1290 |   const hp::QCollection ,
>   |^
> /home/kdas/dealii/source/fe/fe.cc:1287:1: error: no declaration matches
> ‘std::unique_ptr, 
> >::InternalDataBase> dealii::FiniteElement<, 
> >::get_face_data(dealii::UpdateFlags, const dealii::Mapping spacedim>&, int) const’
>  1287 | FiniteElement::get_face_data(
>   | ^~~~
> In file included from
> /home/kdas/dealii/build/include/deal.II/hp/fe_collection.h:22,
>  from
> /home/kdas/dealii/build/include/deal.II/dofs/dof_handler.h:38,
>  from
> /home/kdas/dealii/build/include/deal.II/dofs/dof_accessor.h:22,
>  from /home/kdas/dealii/source/fe/fe.cc:20:
> /home/kdas/dealii/build/include/deal.II/fe/fe.h:2770:3: note: candidate
> is: ‘virtual std::unique_ptr, 
> >::InternalDataBase> dealii::FiniteElement<, 
> >::get_face_data(dealii::UpdateFlags, const dealii::Mapping spacedim>&, const dealii::Quadrature<(dim - 1)>&,
> dealii::internal::FEValuesImplementation::FiniteElementRelatedData spacedim>&) const’
>  2770 |   get_face_data(const UpdateFlags update_flags,
>   |   ^

[deal.II] Build problem version 9.3.0-pre

[Kaushik Das]

Hi all:

I have been building deal.ii via a github fork for last few months 
successfully., This morning I did a  git fetch upstream and then git merge  
upstream/master and I am getting a number of build errors. 
Any idea what I may be doing wrong?
Here is my config and the build errors. 

###
#
#  deal.II configuration:
#CMAKE_BUILD_TYPE:   DebugRelease
#BUILD_SHARED_LIBS:  ON
#CMAKE_INSTALL_PREFIX:   /home/kdas/dealii/install
#CMAKE_SOURCE_DIR:   /home/kdas/dealii
#(version 9.3.0-pre, shortrev 67887ee247)
#CMAKE_BINARY_DIR:   /home/kdas/dealii/build
#CMAKE_CXX_COMPILER: GNU 9.3.0 on platform Linux x86_64
#/usr/bin/c++
#
#  Configured Features (DEAL_II_ALLOW_BUNDLED = ON, 
DEAL_II_ALLOW_AUTODETECTION = ON):
#  ( DEAL_II_WITH_64BIT_INDICES = OFF )
#  ( DEAL_II_WITH_ADOLC = OFF )
#DEAL_II_WITH_ARPACK set up with external dependencies
#DEAL_II_WITH_ASSIMP set up with external dependencies
#DEAL_II_WITH_BOOST set up with external dependencies
#DEAL_II_WITH_COMPLEX_VALUES = ON
#  ( DEAL_II_WITH_CUDA = OFF )
#  ( DEAL_II_WITH_GINKGO = OFF )
#DEAL_II_WITH_GMSH set up with external dependencies
#DEAL_II_WITH_GSL set up with external dependencies
#  ( DEAL_II_WITH_HDF5 = OFF )
#DEAL_II_WITH_LAPACK set up with external dependencies
#DEAL_II_WITH_METIS set up with external dependencies
#DEAL_II_WITH_MPI set up with external dependencies
#DEAL_II_WITH_MUPARSER set up with external dependencies
#DEAL_II_WITH_OPENCASCADE set up with external dependencies
#DEAL_II_WITH_P4EST set up with external dependencies
#DEAL_II_WITH_PETSC set up with external dependencies
#DEAL_II_WITH_SCALAPACK set up with external dependencies
#  ( DEAL_II_WITH_SIMPLEX_SUPPORT = OFF )
#  ( DEAL_II_WITH_SLEPC = OFF )
#  ( DEAL_II_WITH_SUNDIALS = OFF )
#  ( DEAL_II_WITH_SYMENGINE = OFF )
#DEAL_II_WITH_TASKFLOW set up with bundled packages
#DEAL_II_WITH_TBB set up with external dependencies
#DEAL_II_WITH_TRILINOS set up with external dependencies
#DEAL_II_WITH_UMFPACK set up with external dependencies
#DEAL_II_WITH_ZLIB set up with external dependencies
#
#  Component configuration:
#  ( DEAL_II_COMPONENT_DOCUMENTATION = OFF )
#DEAL_II_COMPONENT_EXAMPLES
#  ( DEAL_II_COMPONENT_PACKAGE = OFF )
#  ( DEAL_II_COMPONENT_PYTHON_BINDINGS = OFF )
#
#  Detailed information (compiler flags, feature configuration) can be 
found in detailed.log
#
#  Run  $ make info  to print a help message with a list of top level 
targets
#
###

[ 15%] Building CXX object source/fe/CMakeFiles/obj_fe_debug.dir/fe.cc.o
/home/kdas/dealii/source/fe/fe.cc:1290:13: error: ‘QCollection’ in 
namespace ‘dealii::hp’ does not name a template type; did you mean 
‘FECollection’?
 1290 |   const hp::QCollection ,
  | ^~~
  | FECollection
/home/kdas/dealii/source/fe/fe.cc:1290:24: error: expected ‘,’ or ‘...’ 
before ‘<’ token
 1290 |   const hp::QCollection ,
  |^
/home/kdas/dealii/source/fe/fe.cc:1287:1: error: no declaration matches 
‘std::unique_ptr,  
>::InternalDataBase> dealii::FiniteElement<,  
>::get_face_data(dealii::UpdateFlags, const dealii::Mapping&, int) const’
 1287 | FiniteElement::get_face_data(
  | ^~~~
In file included from 
/home/kdas/dealii/build/include/deal.II/hp/fe_collection.h:22,
 from 
/home/kdas/dealii/build/include/deal.II/dofs/dof_handler.h:38,
 from 
/home/kdas/dealii/build/include/deal.II/dofs/dof_accessor.h:22,
 from /home/kdas/dealii/source/fe/fe.cc:20:
/home/kdas/dealii/build/include/deal.II/fe/fe.h:2770:3: note: candidate is: 
‘virtual std::unique_ptr,  
>::InternalDataBase> dealii::FiniteElement<,  
>::get_face_data(dealii::UpdateFlags, const dealii::Mapping&, const dealii::Quadrature<(dim - 1)>&, 
dealii::internal::FEValuesImplementation::FiniteElementRelatedData&) const’
 2770 |   get_face_data(const UpdateFlags update_flags,
  |   ^


And number of other errors.

Thank you,
Kaushik 

-- 
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/ff754f6c-0268-4992-89e3-5875299a7de5n%40googlegroups.com.

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

[Kaushik Das]

Thank you.
I will try CellDataTransfer method as you suggested.
The test code that I attached earlier has a
mistake. cell->set_active_fe_index(0) should be protected by a if
(cell->is_locally_owned()). I have attached a corrected test here.
Thanks,
Kaushik

On Thu, Dec 31, 2020 at 8:05 PM Marc Fehling  wrote:

> Kaushik,
>
> in addition to what I just wrote, your example from above has revealed a
> bug in the `p::d::SolutionTransfer` class that Wolfgang and I were
> discussing in the course of this chatlog. Thank you very much for this! We
> are working on a solution for this issue.
>
> I would encourage you to use the `p::d::CellDataTransfer` class for your
> use case as described in the last message.
>
> Marc
>
> On Thursday, December 31, 2020 at 6:02:00 PM UTC-7 Marc Fehling wrote:
>
>> Hi Kaushik,
>>
>> Yes, this is possible by changing a cell from FE_Nothing to FE_Q using
>> p-refinement.
>>
>> You can do this with the method described in #11132
>> : Imitate what
>> p::d::SolutionTransfer is doing with the more versatile tool
>> p::d::CellDataTransfer and consider the following:
>>
>>- Prepare a data container like `Vector>` where the
>>outer layer represents each cell in the current mesh, and the inner layer
>>corresponds to the dof values inside each cell.
>>- Prepare data for the updated grid on the old grid.
>>   - On already activated cells, store dof values with
>>   `cell->get_interpolated_dof_values()`.
>>   - On all other cells, store an empty container.
>>   - Register your data container for and execute coarsening and
>>refinement.
>>- Interpolate the old solution on the new mesh.
>>- Initialize your new solution vector with invalid values
>>   `std::numeric_limits::infinity`.
>>   - On previously activated cells, extract the stored data with
>>   `cell->set_dof_values_by_interpolation()`.
>>   - Skip all other cells which only have an empty container.
>>- On non-ghosted solution vectors, call
>>`compress(VectorOperation::min)` to get correct values on ghost cells.
>>
>> This leaves you with a correctly interpolated solution on the new mesh,
>> where all newly activated dofs have the value `infinity`.
>>
>> You can now (and not earlier!!!) assign the values you have in mind for
>> the newly activated dofs. You may want to exchange data on ghost cells once
>> more with `GridTools::exchange_cell_data_to_ghosts()`.
>>
>> This is a fairly new feature in the library for a very specific use case,
>> so there is no dedicated class for transferring solutions across finite
>> element activation yet. If you successfully manage to make this work, would
>> you be willing to turn this into a class for the deal.II library?
>>
>> Marc
>> On Wednesday, December 30, 2020 at 8:22:59 AM UTC-7 k.d...@gmail.com
>> wrote:
>>
>>> Hi all,
>>> Thank you for your reply.
>>> Let me explain what I am trying to do and why.
>>> I want to solve a transient heat transfer problem of the additive
>>> manufacturing (AM) process. In AM processes, metal powder is deposited in
>>> layers, and then a laser source scans each layer and melts and bonds the
>>> powder to the layer underneath it. To simulate this layer by layer process,
>>> I want to start with a grid that covers all the layers, but initially, only
>>> the bottom-most layer is active and all other layers are inactive, and then
>>> as time progresses, I want to activate one layer at a time. I read on this
>>> mailing list that cell "birth" or "activation" can be done by changing a
>>> cell from FE_Nothing to FE_Q using p-refinement. I was trying to keep all
>>> cells of the grid initially to FE_Nothing except the bottom-most layer. And
>>> then convert one layer at a time to FE_Q. My questions are:
>>> 1. Does this make sense?
>>> 2. I have to do two other things for this to work. (a) When a cell
>>> becomes FE_Q from FE_Nothing, dofs that are activating for the 1st time, I
>>> need to apply a non-zero initial value to those dofs. This is to simulation
>>> the metal powder deposited at a specified temperature,. e.g. room
>>> temperature. (b) the dofs, that were shared between a FE_Q and FE_Nothing
>>> cells before the p-refinement and now shared between FE_Q and FE_Nothing
>>> cells after refinement, should retrain their values from before the
>>> refinement.
>>>
>>> Another way to simulation this process would be to use a cell "awaking"
>>> process, instead of the cell "birth". I keep call cells FE_Q but apply a
>>> very low diffusivity to the cells of the layers that are not yet "awake".
>>> But this way, I have to solve a larger system in all time steps. I was
>>> hoping to save some computation time, by only forming a system consists of
>>> cells that are in the "active" layers only.
>>>
>>> Please let me if this makes sense? Is there any other method in deal.ii
>>> that can simulation such a process?
>>> Thank you very much and happy holidays.
>>> 

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

[Kaushik Das]

Hi all,
Thank you for your reply.
Let me explain what I am trying to do and why.
I want to solve a transient heat transfer problem of the additive
manufacturing (AM) process. In AM processes, metal powder is deposited in
layers, and then a laser source scans each layer and melts and bonds the
powder to the layer underneath it. To simulate this layer by layer process,
I want to start with a grid that covers all the layers, but initially, only
the bottom-most layer is active and all other layers are inactive, and then
as time progresses, I want to activate one layer at a time. I read on this
mailing list that cell "birth" or "activation" can be done by changing a
cell from FE_Nothing to FE_Q using p-refinement. I was trying to keep all
cells of the grid initially to FE_Nothing except the bottom-most layer. And
then convert one layer at a time to FE_Q. My questions are:
1. Does this make sense?
2. I have to do two other things for this to work. (a) When a cell becomes
FE_Q from FE_Nothing, dofs that are activating for the 1st time, I need to
apply a non-zero initial value to those dofs. This is to simulation the
metal powder deposited at a specified temperature,. e.g. room temperature.
(b) the dofs, that were shared between a FE_Q and FE_Nothing cells before
the p-refinement and now shared between FE_Q and FE_Nothing cells after
refinement, should retrain their values from before the refinement.

Another way to simulation this process would be to use a cell "awaking"
process, instead of the cell "birth". I keep call cells FE_Q but apply a
very low diffusivity to the cells of the layers that are not yet "awake".
But this way, I have to solve a larger system in all time steps. I was
hoping to save some computation time, by only forming a system consists of
cells that are in the "active" layers only.

Please let me if this makes sense? Is there any other method in deal.ii
that can simulation such a process?
Thank you very much and happy holidays.
Kaushik


On Tue, Dec 29, 2020 at 12:26 PM Wolfgang Bangerth 
wrote:

> On 12/28/20 5:11 PM, Marc Fehling wrote:
> >
> > In case a FE_Nothing has been configured to dominate, the solution
> should be
> > continuous on the interface if I understood correctly, i.e., zero on the
> face.
> > I will write a few tests to see if this is actually automatically the
> case in
> > user applications. If so, this check for domination will help other
> users to
> > avoid this pitfall :)
> >
>
> More tests = more better :-)
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/ssEva6C2PU8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/0398a440-3ee2-9642-9c27-c519eb2f12e5%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/CAC-fs6tnRZ5LDwCts8uO1ZmH9u6dMkY4vWK8SANKKcXSAaBtjQ%40mail.gmail.com.

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

[Kaushik Das]

Hi Marc:
Thank you again for your help.
I have another problem.
A small test code is attached.

I have one cell of FEQ element. I refine that into four cells and then
assign FE_q to two of them and FE_nothing to the other two child cells.
Then when I try to transfer the solution, the code aborts.

Is this a limitation?

Thank you very much,
Kaushik


On Wed, Dec 9, 2020 at 7:16 PM Kaushik Das  wrote:

> 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 <https://github.com/dealii/dealii/pull/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,

Re: [deal.II] Time loop in step-26

[Kaushik Das]

Hello Prof Bangerth:
Unfortunately, I now think it may be better for me not to create a pull
request to fix this issue in example-26 just so I don't inadvertently
create an IP related conflict with my employer. It's a low chance but
still, I think it's better I don't do this.
Thank you for the help in resolving this.
Kaushik

On Mon, Dec 7, 2020 at 2:57 PM Wolfgang Bangerth 
wrote:

> On 12/7/20 11:56 AM, Kaushik Das wrote:
> > I would love to help. Do I have to create a fork on my git account and
> push
> > through that? Or can I will create a new branch on deal.ii and push
> there?
>
> There's a good description of the process here:
> https://github.com/dealii/dealii/wiki/Contributing
>
> I'm looking forward to the patch!
> Best
>   Wolfgang
>
> --
> 
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/IYeaNcpjlHk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/7fb92a75-8699-1633-8768-f01b0d2ab1df%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/CAC-fs6uxki5%2B5Mt-jvkPMVEn7xTaSndgeoZWbpmT%2BcOXNcQ%2B%3DQ%40mail.gmail.com.

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

[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 <https://github.com/dealii/dealii/pull/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,
>>>> dea

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

[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

[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)
>> {
>>

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

[Kaushik Das]

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)
{
  if (counter > ((dim == 2) ? 4 : 8))
cell->set_coarsen_flag();
  else
cell->set_refine_flag();
}

But this still aborts.
Kaushik

On Tue, Dec 8, 2020 at 8:36 AM Bruno Turcksin 
wrote:

> Hi,
>
> Are you sure that your test makes sense? You randomly assign FE indices to
> cells then you refine and coarsen cells. But what does it mean to coarsen 4
> cells together when one of them is FE_Nothing? What would you expect to
> happen?
>
> Best,
>
> Bruno
>
> On Monday, December 7, 2020 at 5:54:10 PM UTC-5 k.d...@gmail.com wrote:
>
>> Hi all:
>>
>> I modified the test  tests/mpi/solution_transfer_05.cc to add a
>> FE_Nohting element to the FECollection. I also modified the other elements
>> to FE_Q.
>>
>> When I run the test, it's aborting in solution transfer.
>> Is there any limitations in using FE_Nothing with parallel solution
>> transfer?
>> The modified test is attached.
>> Thank you very much.
>> Kaushik
>>
>> 
>> 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.
>>
>>
>> --
> 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/ssEva6C2PU8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/609b0457-ba90-4aa2-a7d1-5b798d5349ebn%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/CAC-fs6t%3DSSMODByyuRKBMBa20mCnuBb4jQmn04ZoLN6yC73faQ%40mail.gmail.com.
// -
//
// Copyright (C) 2019 - 2020 by the deal.II authors
//
// This file is part of the deal.II library.
//
// The deal.II library is free software; you can use it, redistribute
// it, and/or modify it under the terms of the GNU Lesser General
// Public License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
// The full text of the license can be found in the file LICENSE.md at
// the top level directory of deal.II.
//
// -



// This test crashed at some point: We have set and sent active_fe_indices based
// on the refinement flags on the p::d::Triangulation object. However, p4est has
// the last word on deciding which cells will be refined -- and p4est makes use
// of it in the specific scenario provided as a test. A fix has been introduced
// along with this test.


#include 

#include 
#include 

#include 
#include 

#include 
#include 

#include 

#include 
#include 

#include 

#include 

#include "tests.h"


template 
void
test()
{
  // setup
  parallel::distributed::Triangulation tria(MPI_COMM_WORLD);
  GridGenerator::hyper_cube(tria);
  tria.refine_global(2);

  const unsigned intmax_degree = 6 - dim;
  hp::FECollection fe_dgq;
  
  fe_dgq.push_back(FE_Nothing());
  for (unsigned int deg = 1; deg <= max_degree - 1; ++deg)
fe_dgq.push_back(FE_Q(deg));

  hp::DoFHandler dgq_dof_handler(tria);

  // randomly assign fes
  for (const auto  : dgq_dof_handler.active_cell_iterators())
if (cell->is_locally_owned())
  cell->set_active_fe_index(Testing::rand() % max_degree);
  dgq_dof_handler.distribute_dofs(fe_dgq);

  // prepare index sets
  IndexSet 

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

[Kaushik Das]

Hi all:

I modified the test  tests/mpi/solution_transfer_05.cc to add a FE_Nohting 
element to the FECollection. I also modified the other elements to FE_Q. 

When I run the test, it's aborting in solution transfer. 
Is there any limitations in using FE_Nothing with parallel solution 
transfer? 
The modified test is attached.
Thank you very much.
Kaushik 

 
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.


-- 
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/124ed0f1-8ae6-4222-b6dd-badebc278c78n%40googlegroups.com.
// -
//
// Copyright (C) 2019 - 2020 by the deal.II authors
//
// This file is part of the deal.II library.
//
// The deal.II library is free software; you can use it, redistribute
// it, and/or modify it under the terms of the GNU Lesser General
// Public License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
// The full text of the license can be found in the file LICENSE.md at
// the top level directory of deal.II.
//
// -



// This test crashed at some point: We have set and sent active_fe_indices based
// on the refinement flags on the p::d::Triangulation object. However, p4est has
// the last word on deciding which cells will be refined -- and p4est makes use
// of it in the specific scenario provided as a test. A fix has been introduced
// along with this test.


#include 

#include 
#include 

#include 
#include 

#include 
#include 

#include 

#include 
#include 

#include 

#include 

#include "tests.h"


template 
void
test()
{
  // setup
  parallel::distributed::Triangulation tria(MPI_COMM_WORLD);
  GridGenerator::hyper_cube(tria);
  tria.refine_global(2);

  const unsigned intmax_degree = 6 - dim;
  hp::FECollection fe_dgq;
  
  fe_dgq.push_back(FE_Nothing());
  for (unsigned int deg = 1; deg <= max_degree - 1; ++deg)
fe_dgq.push_back(FE_Q(deg));

  hp::DoFHandler dgq_dof_handler(tria);

  // randomly assign fes
  for (const auto  : dgq_dof_handler.active_cell_iterators())
if (cell->is_locally_owned())
  cell->set_active_fe_index(Testing::rand() % max_degree);
  dgq_dof_handler.distribute_dofs(fe_dgq);

  // prepare index sets
  IndexSet dgq_locally_owned_dofs = dgq_dof_handler.locally_owned_dofs();
  IndexSet dgq_locally_relevant_dofs;
  DoFTools::extract_locally_relevant_dofs(dgq_dof_handler,
  dgq_locally_relevant_dofs);
  IndexSet dgq_ghost_dofs = dgq_locally_relevant_dofs;
  dgq_ghost_dofs.subtract_set(dgq_locally_owned_dofs);

  // prepare dof_values
  LinearAlgebra::distributed::Vector dgq_solution;
  dgq_solution.reinit(dgq_locally_owned_dofs, dgq_ghost_dofs, MPI_COMM_WORLD);
  VectorTools::interpolate(dgq_dof_handler,
   Functions::ZeroFunction(),
   dgq_solution);
  dgq_solution.update_ghost_values();

  parallel::distributed::SolutionTransfer<
dim,
LinearAlgebra::distributed::Vector,
hp::DoFHandler>
dgq_soltrans(dgq_dof_handler);
  dgq_soltrans.prepare_for_coarsening_and_refinement(dgq_solution);

  // refine and transfer
  {
unsigned int counter = 0;
for (auto cell = tria.begin_active(); cell != tria.end(); ++cell, ++counter)
  if (cell->is_locally_owned())
{
  if (counter > ((dim == 2) ? 4 : 8))
cell->set_coarsen_flag();
  else
cell->set_refine_flag();
}
  }

  tria.execute_coarsening_and_refinement();
  dgq_dof_handler.distribute_dofs(fe_dgq);

  // prepare index sets
  dgq_locally_owned_dofs = dgq_dof_handler.locally_owned_dofs();
  DoFTools::extract_locally_relevant_dofs(dgq_dof_handler,
  dgq_locally_relevant_dofs);
  dgq_ghost_dofs = dgq_locally_relevant_dofs;
  dgq_ghost_dofs.subtract_set(dgq_locally_owned_dofs);

  // unpack dof_values
  dgq_solution.reinit(dgq_locally_owned_dofs, dgq_ghost_dofs, MPI_COMM_WORLD);
  

Re: [deal.II] Time loop in step-26

[Kaushik Das]

Thank you Prof. Bangerth.
I would love to help. Do I have to create a fork on my git account and push
through that? Or can I will create a new branch on deal.ii and push there?
I was working on converting step-26 to use a distributed triangulation and
parallel solvers following step-40, and it seems that it worked. But I have
a few questions, that I will ask in a separate email.
Thank you again for your help.
-Kaushik


On Mon, Dec 7, 2020 at 12:21 PM Wolfgang Bangerth 
wrote:

>
> > So the bug must have been introduced between March 2016 and April 2017.
> It
> > would be interesting to figure out which pull request caused this,
>
> It was #4083: https://github.com/dealii/dealii/pull/4083
>
> I think if you add the two lines back, that would work. Do you want to
> write
> such a patch, or would you like to leave that to us?
>
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/IYeaNcpjlHk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/dfd34a71-e981-87fb-1257-d7bbd695e6c7%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/CAC-fs6vq5TK_Pff%2BhmfTLDCRQ2oKL1WvZdveDyrpPRWpY8GgbA%40mail.gmail.com.

[deal.II] Time loop in step-26

[Kaushik Das]

Hi all,
I have a question about the time loop in step-26. 
We are incrementing timestep_number at the beginning of the loop and it is 
initialized to 0 in the constructor. Should not then the if statement for 
pre_refinement will be only true just once when timestep_number = 1? 
Should not we decrement  timestep_number inside the if part of the loop?
Thank you,
Kaushik 

while (time <= 0.5)
{
time += time_step;
++timestep_number;
...

if ((timestep_number == 1) &&
(pre_refinement_step < n_adaptive_pre_refinement_steps))
{
...
}
else if ((timestep_number > 0) && (timestep_number % 5 == 0))
{
...
}
old_solution = solution;
}

-- 
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/4c20d930-602b-44c4-84d8-b99df2e4a4ban%40googlegroups.com.

Re: [deal.II] Selectively coarsen after a refinement step

[Kaushik Das]

Thank you very much for your help. After some trial and error, I was able
to do it. I have attached the code if that can be of any help to others
searching for similar solutions. I was modifying step-1.cc and did not
modify the file name. Thank you for your suggestion of using the error
estimation for corsening, I will try that too.
Kaushik

On Mon, Nov 30, 2020 at 2:52 PM Wolfgang Bangerth 
wrote:

> On 11/30/20 12:36 PM, Kaushik Das wrote:
> > saveRefinement<3> SaveRefinement(triangulation);
>
> Unrelated to your question, but this convention is very hard to read for
> most
> programmers: You name a class with lower-case first letter and a variable
> with
> upper-case first letter. Both use CamelCase. It's quite difficult to see
> from
> the name what's a variable and what's a class.
>
>
> > triangulation.signals.pre_refinement.connect([] {
> > SaveRefinement(); })
> >
> > /// refine the mesh
> > 
> > triangulation.load_coarsen_flags(SaveRefinement.cellRefined);
> > triangulation.execute_coarsening_and_refinement();
> >
> > At this point, I am hitting Assert(v.size() == n_active_cells(),
> > ExcGridReadError())   in load_coarsen_flags.
> >
> > Which also makes sense to me now, because those flags saved from
> > save_refine_flags are now parent cells, and I have to mark their child
> cells
> > for coarsening.
>
> That's correct.
>
>
> > I will greatly appreciate any hint on how that can be done.
>
> You need to store a map from the old cell to the flags. You could use
>std::map
> for example.
>
>
> > I looked into the Step-26 example. There is another reason I wanted to
> refine
> > the mesh based on geometric criteria. In addition to the laser spot, I
> would
> > like to refine the mesh near the layer that is being printed at the
> given time
> > step. And coarsen the layers underneath it. I am trying to simulation a
> layer
> > upon layer printing process following a paper by Claire Bruna-Rosso et
> al.,
> > who also used deal.ii. They used the FE_Nothing element to exclude the
> layers
> > that are yet to be printed from the solution.
>
> You can refine by your geometric argument, but it might be easiest to
> coarsen
> based on the general indicators.
>
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/6hhi5Xf0_mQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/696423e9-f1ac-6394-04a4-676fb6668040%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/CAC-fs6sOCQ%3DOOXAhbcp4prvPQvWzBKUDRVqf8ZRHW0oUPwGycg%40mail.gmail.com.
/* -
 *
 * Copyright (C) 1999 - 2019 by the deal.II authors
 *
 * This file is part of the deal.II library.
 *
 * The deal.II library is free software; you can use it, redistribute
 * it, and/or modify it under the terms of the GNU Lesser General
 * Public License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 * The full text of the license can be found in the file LICENSE.md at
 * the top level directory of deal.II.
 *
 * -

 */

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

using namespace dealii;

template 
void vtk_out(const Triangulation , int level = -1)
{
  std::string fileName =
"grid-" + (level >= 0 ? std::to_string(level) : "") + ".vtk";
  std::ofstream out("grid-" + std::to_string(level) + ".vtk");
  GridOut

[deal.II] Selectively coarsen after a refinement step

[Kaushik Das]

Hi:
I am new to Deal.ii and reading through the examples to learn more. But I 
have a question, that I did not find a suitable answer in the example 
problems. 

I am trying to solve a transient heat conduction problem over a domain due 
to laser heating in an additive manufacturing process. At each time step, I 
want to refine the mesh at the laser spot and then coarsen the end of the 
time step and then in the next time step laser spot moves and I can again 
refine the mesh where the laser is then. I know the position of the laser 
at all times.

Something like this:

Triangulation<3> triangulation;
GridGenerator::subdivided_hyper_rectangle(triangulation, repetitions, left, 
right, true);

// Refine the mesh based on some geometric criteria, like material 
interfaces, near edges, etc.

Loop over time step starts

// Refine at the laser spot

// do calculations. 

// coarsen to get back to the state where the mesh was at the beginning of 
the time step. 

Loop ends

I tried two different ways. 

1. At the end of the time step, call set_coarsen_flag on those cells that 
were marked with set_refine_flag at the beginning of the step.  But, cells 
that were refined due to smoothing are left refined which is not desirable.
2. Add a pre_refinement signal and then save the save_refine_flags during 
refinement and then load_coarsen_flags that vector from the 
save_refine_flags call. But here I am getting assert failure on mismatched 
size of that vector and the active number of cells whining calling 
execute_coarsening_and_refinement to do the coarsening. 

I also thought of using the persistenttrainregulation class, but I am not 
sure if that covers my use-case. 

I may be able to write some geometric criteria to figure out which cells 
need coarsening. But I am hoping there is a faster method to do this 
because there must be some way to know which cells got refined and by how 
much and just coarsen them again. 

Thank you very much.
-Kaushik 


 

-- 
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/80992164-7465-48f4-8344-ee80dcd7d4d0n%40googlegroups.com.