Re: [deal.II] Refinement on a parallel distributed triangulation with periodic BC

2020-11-17 Thread Daniel Arndt
Maurice,

make_periodicity_constraints loops (recursively) over all faces referenced
in a PeriodicFacePair and applies constraints. You could copy the
implementation in
https://www.dealii.org/developer/doxygen/deal.II/dof__tools__constraints_8cc_source.html#l02269
and modify accordingly or set up an empty ConstraintMatrix objects and
modify the constraints created by make_periodicity_constraints to your
needs.

Best,
Daniel

Am Mo., 16. Nov. 2020 um 10:09 Uhr schrieb 'maurice rohracker' via deal.II
User Group :

> Dear deal.II community,
>
> For a software project at FAU Erlangen-Nuremberg, I implemented a
> distributed memory parallel version of a homogenization problem.
>
> Since we handle periodicity with an offset value, I implemented the
> periodic BC in the following manner:
>
>
>1. Read mesh
>2. Collect periodic faces (triangulation)
>3. Add periodic faces to triangulation
>4. Collect periodic faces (dofHandler)
>5. Make periodic constraint and set inhomogeneity to periodic DOFs on
>the boundary.
>
> Next step would be to add a mesh refinement. My first try was adding
> `triangulation.refine_global(nGlobalRefinement);` after the third step.
>
> Unfortunately, when we try to access cells with `!cell.is_artificial()`
> from the resulting vector of `collect_periodic_faces()` to get all locally
> relevant boundary cells to add the inhomogeneity, the following assertion
> is raised:
>
> The violated condition was:
> this->active()
> Additional information:
> is_artificial() can only be called on active cells!
>
> Looking at the doc of `collect_periodic_faces` (This function will collect
> periodic face pairs on the coarsest mesh level of the given mesh (a
> Triangulation
>  or
> DoFHandler
> ) and
> add them to the vector matched_pairs leaving the original contents
> intact.)  the resulting vector will only contain parent cells, on which the
> call `is_artifiical()` is not possible.
>
> So we thought if we change the `cell_iterator` in `collect_periodic_faces`
> to `active_cell_iterator` we get a vector containing the child cells (on
> which `is_artifical()` is allowed)? Because we would assume that child
> cells are active and therefore, our previous approach would work again. But
> this did not help either.
>
> If this question might be a bit to complex, I would also prepare a minimal
> example.
>
> Is there a going round to get a similar results as with
> `collect_periodic_faces`, i.e. a vector containing all refined periodic
> cells.
>
> Thanks for your support in advance.
>
> Best, Maurice
>
>
> --
> 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/8ba32635-dbf3-41ca-b2f3-b44760702e60n%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/CAOYDWbLO7u7oY%2B%3DjFwsY47ph-ObnPky%2BmUR52aiCpz-Rm0JkCw%40mail.gmail.com.


Re: [deal.II] Adding new obj target

2020-11-09 Thread Daniel Arndt
Zachary,

You also need to make sure that CMake actually sees that your new source
directory. In particular, you should add a line saying

ADD_SUBDIRECTORY(Test)

to source/CMakeLists.txt.

Best,
Daniel

Am Mo., 9. Nov. 2020 um 11:35 Uhr schrieb Zachary 42! <
zacharyloui...@gmail.com>:

> Hi folks,
>
> I am trying to add another include/source directory and subsequent obj to
> dealii for potential future contributions to dealii.  Though I am having
> linking errors because my new obj needs to link agains the lac_obj (need
> Trilinos and other interfaces).  I thought the ADD_DEPENDICIES in the
> source/CMakeLists.txt file is where this is taking care of but apparently
> not.  I am following the exact same CMakeLists.txt files as in the other
> source/dirs but I am still getting the undefined symbols error due to
> object targets not apparently linking together.
>
> [ 80%] Linking CXX shared library ../lib/libdealii.dylib
> Undefined symbols for architecture x86_64:
>   "dealii::PETScWrappers::SparseMatrix::SparseMatrix(int const&,
> bool)", referenced from:
>   test::Operator::Operator(int const&) in Operator.cc.o
>   test::Operator::Operator(int const&, std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&) in
> Operator.cc.o
> ld: symbol(s) not found for architecture x86_64
>
> So looks like the obj_lac needs to link with the obj_test and it doesn’t
> appear to be…
>
> Here is my source/Test/CMakeLists.txt file which builds fine:
>
> INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_BINARY_DIR})
>
> SET(_src
>   Operator.cc
>   )
>
> SET(_n_includes_per_unity_file 20)
>
> IF(DEAL_II_UNITY_BUILD)
>   LIST(SORT _unity_include_src)
> ENDIF()
>
> SETUP_SOURCE_LIST("${_unity_include_src}"
>   "${_separate_src}"
>   ${_n_includes_per_unity_file}
>   _src
>   )
>
> FILE(GLOB _header
>   ${CMAKE_SOURCE_DIR}/include/test/*.h
>   )
>
> DEAL_II_ADD_LIBRARY(obj_test OBJECT ${_src} ${_header})
>
> I didn’t change anything in the souce/CMakeLists.txt file.
>
> --
> 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/DE13C37A-F916-4295-AE97-685F856C5291%40gmail.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/CAOYDWb%2Bt10X7z8k%3DyWj2yxMRAhDmdvhTOi1%2B9We%2B%2BAu4%3D-w-iw%40mail.gmail.com.


Re: [deal.II] Re: CTest Build Error

2020-10-29 Thread Daniel Arndt
Zachary,

Did you actually build deal.II, i.e did you run make?

Best,
Daniel

Am Do., 29. Okt. 2020 um 10:39 Uhr schrieb Zachary Streeter <
zacharyloui...@gmail.com>:

> I'v tried on various computers so I think I'm missing a step.
>
> 1) $ cmake ..
> 2) $ make setup_tests
> and everything works, it seems, so far...
>
> 3) $ ctest -V -R "base/aligned_vector_01" ( and here is my output on a
> different computer )
>
> test 1181
> Start 1181: base/aligned_vector_01.debug
>
> 1181: Test command:
> /global/common/sw/cray/cnl7/haswell/cmake/3.14.4/gcc/8.2.0/2hef55n/bin/cmake
> "-DTRGT=base.aligned_vector_01.debug.diff"
> "-DTEST=base/aligned_vector_01.debug" "-DEXPECT=PASSED"
> "-DBINARY_DIR=/global/homes/z/zstreet/dealii/build/tests/base"
> "-DGUARD_FILE=/global/homes/z/zstreet/dealii/build/tests/base/aligned_vector_01.debug/interrupt_guard.cc"
> "-P"
> "/global/homes/z/zstreet/dealii/build/share/deal.II/scripts/run_test.cmake"
> 1181: Test timeout computed to be: 600
> 1181: gmake[3]: *** No rule to make target
> '/global/homes/z/zstreet/dealii/build/lib/libdeal_II.g.a', needed by
> 'aligned_vector_01.debug/aligned_vector_01.debug'.  Stop.
> 1181: gmake[2]: *** [CMakeFiles/Makefile2:22633:
> CMakeFiles/aligned_vector_01.debug.dir/all] Error 2
> 1181: gmake[1]: *** [CMakeFiles/Makefile2:24496:
> CMakeFiles/base.aligned_vector_01.debug.diff.dir/rule] Error 2
> 1181: gmake: *** [Makefile:10048: base.aligned_vector_01.debug.diff] Error
> 2
> 1181: Test base/aligned_vector_01.debug: BUILD
> 1181: ===   OUTPUT BEGIN
> ===
> 1181: base/aligned_vector_01.debug: BUILD failed. Output:
> 1181: Generating aligned_vector_01.debug/interrupt_guard.cc
> 1181: Scanning dependencies of target aligned_vector_01.debug
> 1181: Building CXX object
> CMakeFiles/aligned_vector_01.debug.dir/aligned_vector_01.cc.o
> 1181: Building CXX object
> CMakeFiles/aligned_vector_01.debug.dir/aligned_vector_01.debug/interrupt_guard.cc.o
> 1181:
> 1181:
> 1181: base/aligned_vector_01.debug: **BUILD failed***
> 1181:
> 1181: ===OUTPUT END
> ===
> 1181: Expected stage PASSED - aborting
> 1181: CMake Error at
> /global/homes/z/zstreet/dealii/build/share/deal.II/scripts/run_test.cmake:140
> (MESSAGE):
> 1181:   *** abort
> 1181:
> 1181:
> 1/2 Test #1181: base/aligned_vector_01.debug .***Failed   13.52 sec
>
>
> On Wednesday, October 28, 2020 at 5:34:56 PM UTC-5 Zachary Streeter wrote:
>
>> Hi everyone,
>>
>> I am getting a strange build error when trying to run through some simple
>> tests. I followed the website instructions but still this error occurs:
>>
>> 1269/8957 Testing: base/conditional_ostream.debug
>> 1269/8957 Test: base/conditional_ostream.debug
>> Command: "/opt/local/bin/cmake"
>> "-DTRGT=base.conditional_ostream.debug.diff"
>> "-DTEST=base/conditional_ostream.debug" "-DEXPECT=PASSED"
>> "-DBINARY_DIR=/Users/zachary/Documents/Coding/dealii/build/tests/base"
>> "-DGUARD_FILE=/Users/zach
>> ary/Documents/Coding/dealii/build/tests/base/conditional_ostream.debug/interrupt_guard.cc"
>> "-P"
>> "/Users/zachary/Documents/Coding/dealii/build/share/deal.II/scripts/run_test.cmake"
>>
>> Directory:
>> /Users/zachary/Documents/Coding/dealii/build/tests/base/conditional_ostream.debug
>>
>> "base/conditional_ostream.debug" start time: Oct 28 12:58 PDT
>> Output:
>> --
>> gmake[3]: *** No rule to make target
>> '/Users/zachary/Documents/Coding/dealii/build/lib/libdeal_II.g.9.3.0-pre.dylib',
>> needed by 'conditional_ostream.debug/conditional_ostream.debug'. Stop.
>> gmake[2]: *** [CMakeFiles/Makefile2:34261:
>> CMakeFiles/conditional_ostream.debug.dir/all] Error 2
>> gmake[1]: *** [CMakeFiles/Makefile2:25385:
>> CMakeFiles/base.conditional_ostream.debug.diff.dir/rule] Error 2
>> gmake: *** [Makefile:11601: base.conditional_ostream.debug.diff] Error 2
>> Test base/conditional_ostream.debug: BUILD
>> === OUTPUT BEGIN
>> ===
>> base/conditional_ostream.debug: BUILD failed. Output:
>> Generating conditional_ostream.debug/interrupt_guard.cc
>> Scanning dependencies of target conditional_ostream.debug
>> Building CXX object
>> CMakeFiles/conditional_ostream.debug.dir/conditional_ostream.cc.o
>> Building CXX object
>> CMakeFiles/conditional_ostream.debug.dir/conditional_ostream.debug/interrupt_guard.cc.o
>>
>>
>>
>> base/conditional_ostream.debug: ** BUILD failed ***
>>
>> The error is no rule make target for libdeal_II.g.9.3.0-pre.dylib needed
>> by the tests program.
>>
>> I am on a Mac; maybe I missed something.
>>
>> Cheers,
>>
>> Zachary
>
> --
> 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" 

Re: [deal.II] Periodic BC in parallel distributed homogenization problem

2020-10-21 Thread Daniel Arndt
Maurice,

Is there any reason that you don't use
DoFTools::make_periodicity_constraints() as shown in
https://www.dealii.org/current/doxygen/deal.II/step_45.html?

Best,
Daniel

Am Mi., 21. Okt. 2020 um 11:16 Uhr schrieb 'maurice rohracker' via deal.II
User Group :

> Dear all,
>
>
> For a project, I try to implement a parallel distributed homogenization
> problem with periodic BC. A serial version is already implemented.
>
> The feature of the periodic BC in the serial case is that it is not purely
> periodic, but periodic with some offset.
>
>
> Therefore the periodic boundary pairs are collected
> (`dealii::GridTools::collect_periodic_faces*(*
>
>  doFHandler, ...)`) and after that stored together with the DOF indices
> to handle the periodic BC by oneself afterwards.
>
>
> For the parallel implementation, I go through the following steps:
>
>1. gather periodic face pairs for all directions using
>`dealii::GridTools::collect_periodic_faces(triangulation, ...,
>periodic_vector)`
>2. add periodicity by `triangulation.add_periodicity(periodic_vector)`
>3. collect periodic boundary pairs using
>`dealii::GridTools::collect_periodic_faces*(*
>4.  doFHandler, ..., periodic_vector2)`
>5. store the pairs with the DOFs by looping over the `periodic_vector2`
>
>
>- to access the DOFs I tried the following
>
> `*for **(**const auto * :
>
>  periodic*_vector2)*
>
> *{*
>
>  (...)
>
>
>  // loop over the DOFs of the boundary periodic pair cells
>
>  *if **(*facePair.cell*[*0*]*->is_locally_owned*() *&& facePair.cell*[*1
> *]*->is_locally_owned*())*
>
> * {*
>
>  facePair.cell*[*0*]*->get_dof_indices*(*localDOFIndicesPlus*)*;
>
>  facePair.cell*[*1*]*->get_dof_indices*(*localDOFIndicesMinus*)*;
>
>  *}*
>
>  *else if **(*facePair.cell*[*0*]*->is_locally_owned*())*
>
> * {*
>
>  facePair.cell*[*0*]*->get_dof_indices*(*localDOFIndicesPlus*)*;
>
>  *(*facePair.cell*[*0*]*->periodic_neighbor*(*facePair.face_idx*[*0*]))*
> ->get_dof_indices*(*localDOFIndicesMinus*)*;
>
>  *}*
>
>  *else if **(*facePair.cell*[*1*]*->is_locally_owned*())*
>
> * {*
>
> * (*facePair.cell*[*1*]*->periodic_neighbor*(*facePair.face_idx*[*1*]))*
> ->get_dof_indices*(*localDOFIndicesPlus*)*;
>
>  facePair.cell*[*1*]*->get_dof_indices*(*localDOFIndicesMinus*)*;
>
>  *}*
>
>
> (...) // store plus and minus point of the boundary together with dof if
> the periodicity of plus and minus point is fulfilled
>
> }`
>
>
> Unfortunately, the resulting localDOFIndicesPlus/Minus of type `std::vector
> *<*dealii::types::global_dof_index*> *localDOFIndicesPlus*(*
>
>  nDOFsPerCell*)*;` only contain garbage values (very high numbers).
>
>
> My first question would be, is it possible to access the DOF indices of
> ghost cells, as I did?
>
> Is our procedure enough to ensure that the periodic boundary cells of a
> triangulation owned by one processor are ghost cells of the corresponding
> triangulation owned by another processor?
>
>
> Thanks in advance for your help. If there are any unclarities in my
> explanation, feel free to ask.
>
>
> Best, Maurice
>
> --
> 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/ce15100c-7daa-410b-bc91-6cd0288c9c3an%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/CAOYDWbLXwnPXVYx0ceacBfsOuXE%2BPsd%3Dv9EUV1Yzo6T8-p%3DGfw%40mail.gmail.com.


Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

2020-10-13 Thread Daniel Arndt
Xiang,

deal.II doesn't have functionality to create separate cells sharing a face
but only to join them. Hence, whatever input you provide to
Triangulation::create_triangulation() must have these faces already. GridIn
should work for that if the faces are disjoint in the input file.

Best,
Daniel

Am Di., 13. Okt. 2020 um 11:20 Uhr schrieb 孙翔 :

> Hi, Daniel,
>
> Thank you very much. So, if I want to disjoint the faces, how should I do
> using dealII or I need to disjoint them manually? If I manually disjoint
> them, should I duplicate the joint nodes and assign them with the new
> number, then assemble the adjacent element with the duplicated nodes?
> Please see the attached figure. I am not sure if Grid_in can read it.
>
> Best,
>
> Xiang
>
> On Monday, 12 October 2020 at 11:09:31 UTC-7 d.arnd...@gmail.com wrote:
>
>> Xiang,
>>
>> Adding to Bruno's response: If the interface you want to apply Dirichlet
>> boundary conditions to stays the same through the whole simulation, then
>> treating the corresponding faces as disjoint while creating your mesh might
>> be a better option.
>> Setting constraints yourself requires you to know how the degrees of
>> freedom map to function values (which depends on the finite element you are
>> using). FE_Q elements are nodal, though, so you can simply constrain the
>> degrees of freedom to the desired function value at the corresponding
>> support points.
>>
>> Best,
>> Daniel
>>
>>
>> Am Mo., 12. Okt. 2020 um 09:21 Uhr schrieb Bruno Turcksin <
>> bruno.t...@gmail.com>:
>>
>>> Xiang,
>>>
>>> You cannot apply a boundary condition on an internal face. You need to
>>> use the AffineConstraint
>>> 
>>> class to impose the constraints yourself. This is what we use internally to
>>> apply Dirichlet boundary condition.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>>
>>>
>>> On Monday, October 12, 2020 at 2:10:15 AM UTC-4 shya...@gmail.com wrote:
>>>
 Hi, I want to model injecting heat fluid into a tiny fracture which is
 inside a block. The fracture is modeled as an interface which is an
 internal face shared by two hex elements. Is it possible for us to apply
 the Dirichlet boundary condition on the interface? If not, how should I do
 it?

 Best,

 Xiang

>>> --
>>> The deal.II project is located at http://www.dealii.org/
>>> For mailing list/forum options, see
>>> https://groups.google.com/d/forum/dealii?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "deal.II User Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to dealii+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/dealii/3840f39f-e3ae-4d76-886b-c3658bcade13n%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/a837e332-a242-45b9-b79b-a23a8f37deb0n%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/CAOYDWb%2BVWhJtqWZ86T229jo0aUMnZgNqZDE9FDDCs5J_9dCj-A%40mail.gmail.com.


Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

2020-10-12 Thread Daniel Arndt
Xiang,

Adding to Bruno's response: If the interface you want to apply Dirichlet
boundary conditions to stays the same through the whole simulation, then
treating the corresponding faces as disjoint while creating your mesh might
be a better option.
Setting constraints yourself requires you to know how the degrees of
freedom map to function values (which depends on the finite element you are
using). FE_Q elements are nodal, though, so you can simply constrain the
degrees of freedom to the desired function value at the corresponding
support points.

Best,
Daniel


Am Mo., 12. Okt. 2020 um 09:21 Uhr schrieb Bruno Turcksin <
bruno.turck...@gmail.com>:

> Xiang,
>
> You cannot apply a boundary condition on an internal face. You need to use
> the AffineConstraint
> 
> class to impose the constraints yourself. This is what we use internally to
> apply Dirichlet boundary condition.
>
> Best,
>
> Bruno
>
>
>
> On Monday, October 12, 2020 at 2:10:15 AM UTC-4 shya...@gmail.com wrote:
>
>> Hi, I want to model injecting heat fluid into a tiny fracture which is
>> inside a block. The fracture is modeled as an interface which is an
>> internal face shared by two hex elements. Is it possible for us to apply
>> the Dirichlet boundary condition on the interface? If not, how should I do
>> it?
>>
>> Best,
>>
>> Xiang
>>
> --
> 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/3840f39f-e3ae-4d76-886b-c3658bcade13n%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/CAOYDWbK9x9i0CjYxuAK2Hu3dKHULXz07%2BOHDLv8yLJ7uLLX1bQ%40mail.gmail.com.


Re: [deal.II] Tools for parallel debugging

2020-10-11 Thread Daniel Arndt
Konrad,

have a look at
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-debug-mpi-programs.
For me, the "mpiexec -np n gdb ./executable" approach normally works fairly
well.

Best,
Daniel

Am So., 11. Okt. 2020 um 09:56 Uhr schrieb Konrad Simon <
ksimon1...@gmail.com>:

> Hi deal.ii community,
>
> I have a short question about tools (which probably also concerns many
> other people).
>
> I am using eclipse for C++ development and I frequently use the debugger.
> So far everything fine. Now I need to use parallel debugging tools for MPI
> but my eclipse crashes many times and/or is super slow.
>
> What tools are you using? Any recommendations or hints?
>
> Best,
> Konrad
>
> --
> 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/d89c4b39-a069-4825-b96b-741665e55095n%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/CAOYDWbJT%2B6QaCVyOBn3nk408AX0JX%2B_g8A28aZJefZBhKkz75Q%40mail.gmail.com.


Re: [deal.II] Making a pair of extracted data and cast into a set

2020-10-08 Thread Daniel Arndt
Behrooz,

Can you elaborate some more on what you are trying to achieve?
The (pseudo-)code you posted looks OK apart from vertices being declared in
the innermost loop.
You probably want it to be outside the loop over the vertices of a face.

The API for Point can be found at
https://www.dealii.org/current/doxygen/deal.II/classPoint.html. In
particular, it is derived from Tensor.

In the end, it should not be a problem to create a std::vector of storage
type Point (if you are interested in the position of vertices)
or unsigned int (if you are interested in the index of the vertices) and
push_back into it.

Best,
Daniel


Am Do., 8. Okt. 2020 um 04:48 Uhr schrieb Behrooz Karami <
be.kar...@gmail.com>:

> Hi everyone,
>
> I am trying to cast extracted vertex_indices into a set (or vector).
> Before that it is needed to make a pair of those indices (just doubling)
> and to cast the pairs into a set  for further manipulations.
>
> I get the vertex information mainly through following lines of code:
>
> for (auto cell : triangulation.active_cell_iterators())
>   for (unsigned int f=0; f::faces_per_cell;
> ++f)
> if (...)
> for (unsigned int v=0; v <
> GeometryInfo::vertices_per_face; ++v)
> {
> if (...)
> {
>  Point
> vertices[GeometryInfo::vertices_per_face];
>
> //vertices[v] =
> cell->face(f)->vertex(v);
> std::cout<<"  vertex_id:
> "vertex_index(v)< //std::cout<<"  coords: "<<
> cell->face(f)->vertex(v)< }
>}
>
> However I have not yet been able to construct the required data structure
> to get that.
> Specially the nature of Point is not yet clear to me. It looks to
> have some similarities with vectors.
>
> Though std::cout yields vertex IDs, I am not sure how to store them (as
> well as vertex coords., face IDs, etc) into a set or vector.
> Having a look on GeometryInfo, my new guess is that I probably need
> to loop over vertex_indices(), i.e.
> vertices[GeometryInfo::vertex_indices()].
>
> By the way could anyone kindly enlighten me about the Point and
> required steps to make a pair of and cast intended data into a set?
> Specially why Point is a preferred type (in the case of
> vertices) to other data types?
>
> Thanks very much,
> Behrooz
>
> --
> 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/b192e1e9-4905-4e40-9e32-17d8a4a3ee62n%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/CAOYDWb%2B%2BmCustRajVHPe79-k4_XohBLKxAsgaAp%3DsNw915a5iA%40mail.gmail.com.


Re: [deal.II] PETSC issue while trying to run step-18

2020-09-22 Thread Daniel Arndt
https://dealii.org/developer/readme.html#configuration-options says to call
cmake with -DPETSC_DIR=/path/to/petsc -DPETSC_ARCH=architecture.
I normally just set the environment variable PETSC_DIR and configure
deal.II with -DDEAL_II_WITH_PETSC=ON

Best,
Daniel

Am Di., 22. Sept. 2020 um 12:29 Uhr schrieb krishan...@gmail.com <
krishanu.se...@gmail.com>:

>
> Hello,
>
> I tried to run step-18 and initially received the following error message:
>
>  Error! This tutorial requires a deal.II library that was configured with
>   the following options:
>
>   DEAL_II_WITH_MPI = ON
>   DEAL_II_WITH_PETSC = ON
>   DEAL_II_PETSC_WITH_COMPLEX = OFF
>
>   However, the deal.II library found at
>   /home/krishanu/Google_Drive/dealii/dealii_920/library_dealii_920 was
>   configured with these options
>
>   DEAL_II_WITH_MPI = OFF
>   DEAL_II_WITH_PETSC = OFF
>   DEAL_II_PETSC_WITH_COMPLEX =
>
>   which conflict with the requirements.
>
> So, I used the following commands (from this link:
> https://www.dealii.org/current/external-libs/petsc.html) to install PETSC:
>
> tar xvzf petsc-x-y-z.tar.gz cd petsc-x-y-z
> export PETSC_DIR=`pwd`
> export PETSC_ARCH=x86_64
> ./config/configure.py --with-shared=1 --with-x=0 --with-mpi=1
> --download-hypre=1
> make
> make test
>
> Then used the following commands to build, configure and install deal.ii
>
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/path/to/install/dir ../deal.II
>
> But it seems that deal.ii did not auto detect PETSC and MPI as it showed
> the following among other configured features:
>
> Configured Features (DEAL_II_ALLOW_BUNDLED = ON,
> DEAL_II_ALLOW_AUTODETECTION = ON):
>
> #  ( DEAL_II_WITH_MPI = OFF )
> #  ( DEAL_II_WITH_PETSC = OFF )
>
> I am wondering what I might be missing here. Could anyone please help?
>
>
> --
> 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/cd2d891c-b80e-4502-b496-89378acd91c0n%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/CAOYDWbKOLYpHcu6MheA%2BW%3DPKneoip6aojq9o1-RsaY8MCSPWow%40mail.gmail.com.


Re: [deal.II] Using DataOut when dim != spacedim

2020-09-22 Thread Daniel Arndt
Malhar,

the template arguments for DataOut are dim and DoFHandlerType where
DoFHandlerType defaults to DoFHandler
since you are using a DoFHandler<2, 3> object you need to specify the
second template argument explicitly, i.e.

DataOut<2, DoFHandler<2,3>> data_out;

You could have a look at step-38.

Best,
Daniel

Am Di., 22. Sept. 2020 um 01:37 Uhr schrieb Malhar T. <
malhar.ti...@gmail.com>:

> Hello All,
> I hope you are doing well !
>
> I am working on a surface patch in 3D (dim=2 & spacedim=3 and developed
> using ChartManifold<2,3> by following code similar to step-53
> ) and I
> would like to output the results into a vtk file. I am mostly following
> tutorials, as I am not really great with C++. So, initially I used the
> class DataOut and tried to specify the geometry using attach_dof_handler.
>
> This is how its defined,
>
> Triangulation<2, 3> triangulation;
> DoFHandler<2, 3>dof_handler;
>
> And output_results function was written as
>
> {
> DataOut data_out;
> data_out.attach_dof_handler(dof_handler);
> }
>
> But I got the error
>
>
> error: cannot convert ‘const dealii::DoFHandler<2, 3>’ to ‘const 
> dealii::DoFHandler<2, 2>&’
> note:   initializing argument 1 of ‘void 
> dealii::DataOut_DoFData patch_space_dim>::attach_dof_handler(const DoFHandlerType&) [with 
> DoFHandlerType = dealii::DoFHandler<2, 2>; int patch_dim = 2; int 
> patch_space_dim = 2]’
>
> I tried searching in the forum and came to know about DataOutFaces
> (through this post
> ), and I
> also looked at the step-61
> 
> tutorial on its implementation, but I got the same error again. I have a
> feeling that I am not understanding something very trivial, thus, any
> pointers would be really helpful.
>
> Thank You.
>
>
> I tried searching in the forum and came to know about DataOutFaces
> (through this post)
> , and I
> also looked at the step-61
> 
> tutorial on its implementation, but I got the same error again. I have a
> feeling that I am not understanding something very trivial, any pointers
> would be helpful. Thank You.
>
> --
> 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/7e032f3f-2957-4235-9f32-df8858a2c575n%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/CAOYDWb%2Be3gw%2BaxNgw9ogx6CMvB0uzJM21pTEKRb7YP4-0807iw%40mail.gmail.com.


Re: [deal.II] HOW TO OUTPUT SYSTEM MATRIX IN A FILE

2020-07-29 Thread Daniel Arndt
Of course, there is also PETScWrappers::MatrixBase::print(
https://www.dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html#a7515e640202d1ad50bd9baa13c404cb1)
that should work.

Best,
Daniel

Am Mi., 29. Juli 2020 um 12:59 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 7/28/20 12:11 PM, 孙翔 wrote:
> > Hi, I followed step-17 and build a system matrix of which type
> > is PETScWrappers::MPI::SparseMatrix. I want to output it after
> assembling. How
> > should I do it? Thank you very much.
>
> If performance doesn't matter, just loop over all indices i and j and
> output
> the value of the matrix. If you're running in parallel, you need to
> restrict
> the loop over i to the locally owned range.
>
> Best
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/879a7ef3-7c13-8142-d970-773e3a57e470%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/CAOYDWb%2B7%3Dfk_oNi-fte9cpWKRO8MeapeWCogD%2B8RVEW17eqg7w%40mail.gmail.com.


Re: [deal.II] Point receivers

2020-07-26 Thread Daniel Arndt
Yuesu,

Have a look at FEFieldFunction (
https://www.dealii.org/current/doxygen/deal.II/classFunctions_1_1FEFieldFunction.html)
for the case that the interpolation points don't coincide with support
points for nodal elements.
Otherwise, you can use DoFTools::map_dofs_to_support_points (
https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a5c7b6729af729af6d7deb67885467a79)
and search fo the corresponding degree of freedom.

Best,
Daniel

Am So., 26. Juli 2020 um 16:58 Uhr schrieb yuesu jin :

> Dear all,
>   I am working on an elastic wave simulation code which needs to set up
> receivers on the surface boundaries to record the waveform.  In this case,
> how can I link the point coordinate with the dof handlers and extract
> values from the solution vector? Thank you!
> Best regards,
>
>
> --
> Yuesu Jin,
>
>
> --
> 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/CA%2B25a%3D%2BY%2BVVdKMEds6HRFdt%2BmrdMR4ZdWrwtdx3YQgHBfCpt5A%40mail.gmail.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/CAOYDWbKwHDTjaLCygGC84Zd-RK-Nwyxy8grjs-%3D8bckUb9w2%2Bw%40mail.gmail.com.


Re: [deal.II] Re: Memory loss in system solver

2020-07-24 Thread Daniel Arndt
Alberto,

Have you tried running valgrind (in parallel) on your code? Admittedly, I
expect quite a bit of false-positives from the MPI library but it should
still help.

Best,
Daniel

Am Fr., 24. Juli 2020 um 12:07 Uhr schrieb Alberto Salvadori <
alberto.salvad...@unibs.it>:

> Dear community,
>
> if I am not mistaking my analysis, it turned out that the memory loss is
> caused by this call:
>
> BiCG.solve (this->system_matrix, distributed_incremental_displacement,
> this->system_rhs, preconditioner);
>
> because if I turn it off the top command shows no change in the RES at all.
>
> Maybe this is of use. Thanks in advance.
>
> Alberto
>
> Il giorno venerdì 24 luglio 2020 alle 11:32:13 UTC+2 Alberto Salvadori ha
> scritto:
>
>> Dear community
>>
>> I have written the simple code below for solving a system using PETSc,
>> having defined
>>
>> Vector incremental_displacement;
>> Vector accumulated_displacement;
>>
>> in the class LargeStrainMechanicalProblem_OneField.
>>
>> It turns out that this code produces a memory loss, quite significant
>> since I am solving my system thousands of times, eventually inducing the
>> run to fail. I am not sure what is causing this issue and how to solve it,
>> maybe more experienced users than myself can catch the problem with a snap
>> of fingers.
>>
>> I have verified the issue on my mac (Catalina) as well as on linux ubuntu
>> (4.15.0), using deal.ii 9.1.1.
>> Apparently the issue reveals only when mpi is invoked with more than one
>> processor, whereas it does not emerge when running in serial or by mpirun
>> -np 1.
>>
>> Thanks in advance
>>
>> Alberto
>>
>> =
>>
>>
>>
>>
>> template 
>> unsigned int LargeStrainMechanicalProblem_OneField
>> ::
>> solve (
>> const unsigned penaltyAmplification
>> )
>>
>> //
>> // this simplified version of solve has been written to find out
>> // the source of memory leak in parallel
>> //
>>
>> {
>>
>> PETScWrappers::MPI::Vector distributed_incremental_displacement
>> (this>locally_owned_dofs,this->mpi_communicator);
>>
>> distributed_incremental_displacement = incremental_displacement;
>>
>> size_t
>> bicgstab_max_iterations = 2 ;
>>
>> double
>> tolerance = 1e-10 * this->system_rhs.l2_norm() ;
>>
>> unsigned solver_control_last_step;
>>
>> SolverControl bicgstab_solver_control ( bicgstab_max_iterations ,
>> tolerance );
>>
>> PETScWrappers::PreconditionJacobi preconditioner( this->system_matrix );
>>
>> this->pcout << " Bicgstab " << std::flush ;
>>
>> PETScWrappers::SolverBicgstab BiCG (bicgstab_solver_control,
>> this->mpi_communicator);
>>
>> BiCG.solve (this->system_matrix, distributed_incremental_displacement,
>> this->system_rhs, preconditioner);
>>
>> solver_control_last_step = bicgstab_solver_control.last_step();
>>
>> incremental_displacement = distributed_incremental_displacement;
>> accumulated_displacement += incremental_displacement;
>> this->hanging_node_constraints.distribute (accumulated_displacement);
>>
>> return solver_control_last_step;
>>
>> }
>>
>
>
> Informativa sulla Privacy: http://www.unibs.it/node/8155
>
> --
> 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/24389a5b-59ba-4f32-8c4b-06d23d0fe2ban%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/CAOYDWb%2BFzNpuJG5-TTjbNXTFZyzhMbaXAGoD7ENb%2BK2W_gbY0A%40mail.gmail.com.


Re: [deal.II] Cannot find local compiled petsc library

2020-07-24 Thread Daniel Arndt
Yuesun,

Apparently, CMake was able to find the file petscvariables, but not the
include directories or the library.
Can you search for "libpetsc.so" yourself? Our CMake find module tries to
find this library in {PETSC_DIR}/lib or {PETSC_DIR}/lib64.
See if you can adjust PETSC_DIR accordingly.

Best,
Daniel

Am Fr., 24. Juli 2020 um 01:18 Uhr schrieb yuesu jin :

> Dear all,
>   I am installing deal.ii with petsc on a cluster. After I compiled the
> petsc library (The arch folder name is arch-linux-c-debug) and gave a cmake
> argument -DPETSC_DIR=/home/yjin6/petsc
> cmake cannot find the petsc library .so file(It is in the folder), but it
> founds the version is 3.13.
> Could you tell me what's the possible reason why cmake cannot find the
> library?
> Best regards
> ***
> --- Include
> /home/yjin6/Deal.II/dealii-9.2.0/cmake/configure/configure_3_petsc.cmake
> -- PETSC_LIBRARY not found! Call:
> -- FIND_LIBRARY(PETSC_LIBRARY NAMES petsc libpetsc HINTS
> /home/yjin6/petsc /home/yjin6/petsc/ PATH_SUFFIXES lib lib64 lib)
> -- PETSC_INCLUDE_DIR_ARCH not found! Call:
> -- FIND_PATH(PETSC_INCLUDE_DIR_ARCH petscconf.h HINTS
> /home/yjin6/petsc /home/yjin6/petsc/ PATH_SUFFIXES petsc include
> include/petsc)
> -- Found PETSC_INCLUDE_DIR_COMMON
> -- Found PETSC_PETSCVARIABLES
> --   PETSC_VERSION: 3.13.3.0
> --   PETSC_LIBRARIES: *** Required variable "PETSC_LIBRARY" set to
> NOTFOUND ***
> --   PETSC_INCLUDE_DIRS: *** Required variable "PETSC_INCLUDE_DIR_ARCH"
> set to NOTFOUND ***
> --   PETSC_USER_INCLUDE_DIRS: *** Required variable
> "PETSC_INCLUDE_DIR_ARCH" set to NOTFOUND ***
> -- Could NOT find PETSC
> -- DEAL_II_WITH_PETSC has unmet external dependencies.
> --
> Yuesu Jin,
> Ph.D student,
> University of Houston,
> College of Natural Sciences and Mathematics,
> Department of Earth and Atmospheric Sciences,
> Houston, Texas 77204-5008
> 346-404-2062
>
> --
> 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/CA%2B25a%3DJVitawqmwmYZ4-9XC8tcmc4EkgXC3_gTy6hjAcLL3Dxg%40mail.gmail.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/CAOYDWb%2BPuHRk%3DWAtNcwt8PPm469pUSeLR1iiqTa3HZ2FmED_oA%40mail.gmail.com.


Re: [deal.II] Accessing nodal values of a FEM solution

2020-07-23 Thread Daniel Arndt
>
> We need to update function v based on solution u in the following loop.
>
> for ( x in vector_of_nodal_points )
>   v(x) = f(x, u(x))
>
> where v(x) and u(x) are the nodal point value for functions v and u,
> respectively, and f() is some function depending on function u as well as
> the location of the nodal point. So in this case, we need to access nodal
> point coordinates and nodal point values of the solution in the same loop.
>

You can just loop over all degrees of freedom and do

for (unsigned int i=0; ihttps://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-to-get-the-mapped-position-of-support-points-of-my-element).



> Well, the above function calculates the gradients of a finite element at
> the quadrature points of a cell, not at the nodal points of a cell.
> Such a need arises in the following situation.
>
> for ( x in vector_of_nodal_points )
>   v(x) = g(x, u(x), grad u(x))
>

You can do similarly,

Quadrature q(fe.get_unit_support_points());
FEValues fe_values (..., q, update_q_points);
for (const auto& cell)
  ...
  points = fe_values.get_quadrature_points();
  fe_values.get_function_values(values);
  fe_values.get_function_gradients(gradients);
  for (unsigned int i=0; ihttp://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/CAOYDWbL%2Brkbnqd0vbec33eDzSZdnVCzArZghU1fkU9uyhaXW1w%40mail.gmail.com.


Re: [deal.II] Location for Boundary Condition Application

2020-07-23 Thread Daniel Arndt
McKenzie,

I'm interested in applying a non-homogeneous Dirichlet boundary condition
> to a specific edge. However, I'm unsure how to identify or specify a
> particular edge or face to add the boundary condition to. Could you help
> clear this up for me?


What do you know about that particular edge? You can always ask faces or
edges, e.g., about their midpoints. Have a look at
https://www.dealii.org/current/doxygen/deal.II/step_6.html#Abettermesh.

Best,
Daniel

-- 
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/CAOYDWb%2B-_hretd8LToON2E15e%2B-3yX32etVXBKSiJS_4%2BYFu_g%40mail.gmail.com.


Re: [deal.II] Accessing nodal values of a FEM solution

2020-07-23 Thread Daniel Arndt
>
> However, I have two more related questions. BTW, I am a newbie in C++
> programming. So my questions may seem absurd.
>
>1. Now that we have a vector holding all nodal point coordinates, and
>another vector holding all nodal point values of the solution. How do we
>access every nodal point coordinates, and at the same time, the associated
>nodal point value within the same loop?
>
> Can you clarify in a short pseudocode example what you are trying to
achieve?

>
>1. In addition to nodal point values of a solution, are the partial
>derivatives (or gradient) of the solution at each nodal point available in
>deal.ii?
>
> That's basically what DataPostprocessor is doing. In general, you can loop
over all cells and calculate the derivatives locally. Have a look at
FEValuesBase::get_function_gradients (
https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ad1f4e0deb5d982e8172d82141c634a67
).

Best,
Daniel

-- 
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/CAOYDWbJmMnq-3Vz%2BKEtsdnoMhOxihuJvhhFrN9Ke8QjKiam1sA%40mail.gmail.com.


Re: [deal.II] Complex-valued distributed matrices in dealii

2020-07-23 Thread Daniel Arndt
Pascal,

The wrapped Trilinos matrices are based on Epetra which only supports
double AFAICT. That's why you can replace TrilinosScalar easily.
On the other hand, you should be able to compile PETSc with complex scalar
type and use that with MPI.

Best,
Daniel

Am Do., 23. Juli 2020 um 12:42 Uhr schrieb Pascal Kraft <
kraft.pas...@gmail.com>:

> Dear Deal.II devs and users,
>
> In the latest release a lot of (great) work has been done to make complex
> numbers more of a first-class citizen in deal, which has made my code a lot
> more readable. Currently, I am stuck with one problem, though. Are there
> any distributed datatypes for matrices that accept complex numbers?
>
> The dealii sparse matrix implementation is a template and allows complex
> numbers - however that implementation has no MPI functionality, which I
> need.
>
> The Petsc Sparse Matrix and Trilinos Sparse Matrix are no templates. In
> the types header I found the declaration of TrilinosScalar as double but
> changing it and recompiling dealii with the changed header threw an error.
>
> I have Trillions compiled with support for complex numbers and also
> searched through the LinearAlgebra documentation.
>
> I require GMRES as a solver (which should be possible, because the GMRES
> Versions all use a templated Vector which can take complex components) and
> MPI distribution of a sparse system. I have so far only seen FullMatrix to
> accept complex numbers.
>
> Can anyone give me a pointer on what is possible?
>
> Kind regards,
> Pascal Kraft
>
> --
> 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/4f4af1e0-4020-4dbf-aa9a-3a3fb7297d90o%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/CAOYDWb%2BZZn-X6ZROtzYVX6bR1Qe8FXdxcueL%3DPL7qOFFmVhDHA%40mail.gmail.com.


Re: [deal.II] ABOUT READING GMSH

2020-07-20 Thread Daniel Arndt
Xiang,

deal.II interprets physical tags as boundary ids when reading .msh files
using GridIn::read_msh (
https://www.dealii.org/current/doxygen/deal.II/classGridIn.html#a83872db02e04f52ac52d578912f6da5e
).
If your mesh consists of multiple parts in separate msh files you can
create triangulation for each of them and merge them using
GridGenerator::merge_triangulations (
https://www.dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html#a7cd88e7eacd46697dee80ad2b8438d54
).

Best,
Daniel

Am Mo., 20. Juli 2020 um 12:25 Uhr schrieb xs...@berkeley.edu <
xs...@berkeley.edu>:

> Hi, can Dealii read the inside boundary from .gmsh file, which can
> distinguish different parts of model geometry? If it can not, how can
> dealii import the model with multiple parts? Thanks a lot.
>
> Best,
>
> Xiang
>
> --
> 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/9b83d3f4-4728-4ca2-bd1a-1059baa76139n%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/CAOYDWbJzPY0EQuo_pVfD%2B%3DjRr0amzWCKCUu8vk8rn4dq87DX-A%40mail.gmail.com.


Re: [deal.II] Accessing nodal values of a FEM solution

2020-07-19 Thread Daniel Arndt
Is it possible to access nodal point values of a solution in deal.ii? And
> is it possible to revise nodal values of a solution pointwise?
>

Yes, of course, the elements of your solution vector correspond to degrees
of freedoms which are nodal values in your case.
You simply access them (both for read and write) via operator().
DoFTools::map_dofs_to_support_points (
https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a5514e4f59ea659f63953d62ca429eaff
)
might be useful if you need to know the support point for a given degree of
freedom.

The tutorial examples show only how to access values of the solution at the
> quadrature points within each cell.
>
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-to-get-the-mapped-position-of-support-points-of-my-element
might also be helpful.

Best,
Daniel

-- 
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/CAOYDWbJYo4QNnu6u__PX9CfnfDH-Ji5YyMSfLi5i%2B4CpH%3D6t6Q%40mail.gmail.com.


Re: [deal.II] Setting up dealii through Docker

2020-06-26 Thread Daniel Arndt
Bhavesh,

It's hard to tell if there is something going wrong and if so what it is
from just the information you provided.
If you inspect your container can you find the deal.II library, i.e. the
include files and the shared library?
If so, how did you try to invoke CMake when trying to build step-1? Do you
set any environment variables like DEAL_II_DIR?

Best,
Daniel

Am Do., 25. Juni 2020 um 18:51 Uhr schrieb Bhavesh Shrimali <
bhavesh.shrim...@gmail.com>:

> Hi dealii users,
>
> I wanted to get started with dealii (and in the long run hopefully use it
> for my research). Naturally, I sought the easiest way forward through
> docker. Since I use Singularity more often than docker (due to seamless
> transition to running on our HPC cluster) I put together a container here
> . It basically pulls the
> corresponding `tagged` image from DockerHub
>  and installs a bunch of
> other libraries that I use in my research.
>
> However when I try to execute step-1 as listed in the tutorials section
> , it seems
> that dealii isn't installed on the docker image (or maybe I am missing
> something)
>
> CMake Error at CMakeLists.txt:30 (MESSAGE):
>
>
>   *** Could not locate a (sufficiently recent) version of deal.II.  ***
>
>
>
>   You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to
> cmake
>
>   or set an environment variable "DEAL_II_DIR" that contains this path.
>
>
> -- Configuring incomplete, errors occurred!
>
>
>
>
> Does anyone know, what am I missing here ?
>
> Thanks in advance!
>
> --
> 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/d2840b63-7278-4519-a8dc-1282035dad2ao%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/CAOYDWbK8bKeeR8QKeCQBzFz8DvPsdnEfcNw8gJ6u_5P3%2BroOuA%40mail.gmail.com.


Re: [deal.II] Re: Deal.ii installation

2020-06-03 Thread Daniel Arndt
Prasad,

CMake ran successfully and the output looks fine. Some of the example steps
require certain dependencies which you just didn't activate.
Note, that you will not be able to use MPI with this configuration.

Best,
Daniel


Am Mi., 3. Juni 2020 um 05:21 Uhr schrieb Prasad Adhav <
prasada001...@gmail.com>:

> I am sorry to be a bother, but the last time I tried the suggestion
> without any success.
> cmake -DDEALII_WITH_MPI=OFF -DDEALII_WITH_TRILINOS=OFF
> -DDEAL_II_WITH_PETSC=OFF ..
>
> I had to shift to a different task.
>
> I have to come back to install deal.ii though. I thought of starting a
> from new.
> I want to run a coupled simulation using the preCICE library, where
> deal.ii will be used for FEM part.( hence I am trying to install v9.1.0).
>
> I am using Ubuntu 18.04 LTS.
> cmake version 3.10.2
>
> I first did
> cmake -DCMAKE_INSTALL_PREFIX=/home/prasad/bin/deal.II ../
>
> then I did
> cmake -DDEALII_WITH_MPI=OFF -DDEALII_WITH_TRILINOS=OFF 
> -DDEAL_II_WITH_PETSC=OFF
> ..
>
> The dealii_cmake.log has the output for my terminal.
> CMakeError.log and CmakeOutput.log are also attached.
>
> The immediate issues seen are
> -- Include
> /home/prasad/bin/dealii-9.1.0/cmake/configure/configure_muparser.cmake
> -- MUPARSER_LIBRARY not found! Call:
> -- FIND_LIBRARY(MUPARSER_LIBRARY NAMES muparser muparserd HINTS
> PATH_SUFFIXES lib lib64 lib)
> -- MUPARSER_INCLUDE_DIR not found! Call:
> -- FIND_PATH(MUPARSER_INCLUDE_DIR muParserDef.h HINTS PATH_SUFFIXES
> include)
> --   MUPARSER_LIBRARIES: *** Required variable "MUPARSER_LIBRARY" set to
> NOTFOUND ***
> --   MUPARSER_INCLUDE_DIRS: *** Required variable "MUPARSER_INCLUDE_DIR"
> set to NOTFOUND ***
> -- Could NOT find MUPARSER
> -- DEAL_II_WITH_MUPARSER has unmet external dependencies.
> -- DEAL_II_WITH_MUPARSER successfully set up with bundled packages.
>
>
> The further output shows, with examples with dependencies not satisfied.
> -- Configuring done. Proceed to target definitions now.
> -- Setting up bundled features
> -- Performing Test DEAL_II_HAVE_FLAG_flifetime_dse=1
> -- Performing Test DEAL_II_HAVE_FLAG_flifetime_dse=1 - Success
> -- Performing Test DEAL_II_HAVE_FLAG_Wimplicit_fallthrough=0
> -- Performing Test DEAL_II_HAVE_FLAG_Wimplicit_fallthrough=0 - Success
> -- Setting up bundled features - Done
> -- Setting up library
> -- Setting up library - Done
> -- Setting up project configuration
> -- Setting up project configuration - Done
> -- Setting up examples
> --   step-17 - dependencies not satisfied
> --   step-18 - dependencies not satisfied
> --   step-32 - dependencies not satisfied
> --   step-36 - dependencies not satisfied
> --   step-40 - dependencies not satisfied
> --   step-42 - dependencies not satisfied
> --   step-45 - dependencies not satisfied
> --   step-54 - dependencies not satisfied
> --   step-55 - dependencies not satisfied
> --   step-62 - dependencies not satisfied
> --   step-64 - dependencies not satisfied
> -- Setting up examples - Done
> -- Setting up quick_tests in DEBUG mode
> -- Setting up quick_tests in DEBUG mode - Done
> -- Setting up testsuite
> -- Setting up testsuite - Done
>
> Thank you in advance for your help and patience.
>
> Regards,
> Prasad ADHAV
>
> On Tue, Apr 28, 2020 at 7:09 PM Marc Fehling 
> wrote:
>
>> Hi Prasad!
>>
>> My guess now is the following: You have PETSc and Trilinos installed on
>> your device, which deal.II finds, but complains that PETSc has been
>> installed with a different MPI configuration as is available for deal.II.
>>
>> -- Include
>> /home/prasad/Downloads/dealii/cmake/configure/configure_3_petsc.cmake
>> -- Found PETSC_LIBRARY
>> -- Found PETSC_INCLUDE_DIR_ARCH
>> -- Found PETSC_INCLUDE_DIR_COMMON
>> -- PETSC_PETSCVARIABLES not found! Call:
>> -- FIND_FILE(PETSC_PETSCVARIABLES NAMES petscvariables HINTS
>> /usr/lib/petscdir/3.6.2//x86_64-linux-gnu-real /usr/lib/petscdir/3.6.2/
>> PATH_SUFFIXES conf lib/petsc/conf)
>> --   PETSC_VERSION: 3.7.7.0
>> --   PETSC_LIBRARIES: /usr/lib/x86_64-linux-gnu/libpetsc.so
>> --   PETSC_INCLUDE_DIRS: /usr/include/petsc;/usr/include/petsc
>> --   PETSC_USER_INCLUDE_DIRS: /usr/include/petsc;/usr/include/petsc
>> -- Found PETSC
>> -- Could not find a sufficient PETSc installation: PETSc has to be
>> configured with the same MPI configuration as deal.II.
>> -- DEAL_II_WITH_PETSC has unmet external dependencies.
>>
>> Later, we find:
>>
>> -- Include
>> /home/prasad/Downloads/dealii/cmake/configure/configure_p4est.cmake
>> -- DEAL_II_WITH_P4EST has unmet configuration requirements:
>> DEAL_II_WITH_MPI has to be set to "ON".
>> --
>> -- Include
>> /home/prasad/Downloads/dealii/cmake/configure/configure_scalapack.cmake
>> -- DEAL_II_WITH_SCALAPACK has unmet configuration requirements:
>> DEAL_II_WITH_MPI has to be set to "ON".
>> --
>> -- Include
>> /home/prasad/Downloads/dealii/cmake/configure/configure_slepc.cmake
>> -- DEAL_II_WITH_SLEPC has unmet configuration requirements:
>> DEAL_II_WITH_PETSC has to be set to "ON".
>>

Re: [deal.II] Step 44: imported 2d mesh fails to converge to solution

2020-04-16 Thread Daniel Arndt
James,

I do find it interesting that the two meshes were not imported with the 
> same boundary IDs. I guess in the future I should assume that all boundary 
> IDs are zero and reset them for each calculation? Also, is there a quick 
> reference guide for what each boundary ID means? I have not yet found such 
> a reference on the deal.ii website.
>

There is no global meaning for any boundary id. Every code can decide what 
to do for faces with a specific boundary id. Have a look, e.g., where 
interpolate_boundary_values is called and have a look at the first tutorial 
steps, in particular step-3.

Best,
Daniel

-- 
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/b2a92716-eb5b-435a-aa58-bd8b0373bd98%40googlegroups.com.


Re: [deal.II] Initial guidance/starting point for solving a non-linear diffusion equation with double neumann BCs

2020-03-12 Thread Daniel Arndt
Krishna,

Have a look at step-7 for Neumann boundary conditions, step-15 for
nonlinear problems and step-26 for time-dependent problems to get started.
Let us know if you have more specific questions.

Best,
Daniel

Am Do., 12. März 2020 um 17:38 Uhr schrieb Krishnakumar Gopalakrishnan <
krish...@vt.edu>:

> I need to solve the following non-linear diffusion equation on a unit 1D
> domain:
>
> du/dt = \nabla \dot ( D(u) \grad u)
>
> subject to Neumann bcs at both ends. D(u)*grad(u) = f(t) at x=0, and
> D(u)*grad(u) = 0 at x=1, with a constant initial condition u(x,0) = u0
>
> The difficulty with this problem is two fold
>
>- The diffusion coefficient D is a function of the field variable u,
>- Diffusion coefficient D(u) varies by 4 orders of magnitute between
>10^-12 and 10^-16
>
> Being 1D, the problem size is very small and I am thnking of just using
> direct solvers. However, I don't quite know how to start approaching this
> problem and how to begin the coding this in deal.ii.
>
> I'd appreciate any thoughts/help/suggestions/guidance from the deal.II
> community.
>
> Regards,
> Krishna
>
>
>
> --
> 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/3c0a13b9-1d59-443d-97bf-5a95440281d3%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/CAOYDWbK8fuCwiTQPjKO%2BaNhtLeAvCtXonskzS5%2BBha8CEkjw3w%40mail.gmail.com.


Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

2020-03-05 Thread Daniel Arndt
Magdalini,

The problem only appears with inhomogeneous boundary conditions, but
periodic boundary conditions don't set any inhomogeneity.

Best,
Daniel

Am Do., 5. März 2020 um 16:13 Uhr schrieb Magdalini Ntetsika <
ntets...@berkeley.edu>:

> Hi Wolfgang,
>
> thank you for the prompt reply. I see, I'll look up both. But I have a
> quick question: what if I have periodic boundary conditions all around my
> domain? It seems to be working in that case, even if the boundary values
> are nonzero, I get to have the correct system_rhs vector. I guess will need
> first to watch the topic on Dirichlet Boundary conditions to understand
> better, but it will be very helpful if I could get some feedback on that
> specific observation from you.
>
> Best,
> Magda
>
> On Thursday, March 5, 2020 at 9:41:11 AM UTC-8, Wolfgang Bangerth wrote:
>>
>> On 3/5/20 9:24 AM, Magdalini Ntetsika wrote:
>> >
>> > but I don't seem to get the same *system_rhs *when
>> > *assemble_system=false* as when *assemble_system=true*. To be more
>> > specific, it seems that there is something wrong with how
>> > constraints.distribute_local_to_global(local_rhs, local_dof_indices,
>> > system_rhs) creates the system_rhs from local_rhs and
>> > local_dofs_indices. I don't change anything about constraints etc
>> > throughout the time steps since I set those things up at the very
>> > beginning and then I just run several times without updating anything.
>> > Any idea about what the problem could be?
>>
>> Magdalini,
>> it's not in the function you point to, but in your understanding. In
>> order to compute the correct values of the right hand side when you have
>> non-zero constraints (e.g., when you have nonzer boundary values), the
>> function you call needs to have access to the matrix elements.
>>
>> The issue is a bit complicated to understand, but you may want to look
>> up the video lectures on the topic of Dirichlet boundary conditions.
>>
>> As for your case, take a look at step-26, which deals with exactly this
>> problem by building the matrix only once, but then using it for several
>> time steps.
>>
>> 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/a320a562-6800-4650-871f-83a5eff9b79a%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/CAOYDWbKXD1Oijy5YKX71b7vWeT7_%3Dzcu58gK_Es5BYBsHiZc-w%40mail.gmail.com.


Re: [deal.II] Scaling behavior of Matrix-Free test program

2020-03-02 Thread Daniel Arndt
Maxi,

it would likely be interesting to run the STREAM benchmark on these two
systems to see how much memory bandwidth you can hope to get.
I would not be too surprised if that still is the limiting factor for your
test.

Best,
Daniel

Am Mo., 2. März 2020 um 12:17 Uhr schrieb 'Maxi Miller' via deal.II User
Group :

> I wrote a small test program for solving a non-linear equation using the
> RK4-solver implemented in deal.II, and assembling the right hand side using
> the matrix-free framework (code is attached). Afterwards I wanted to check
> the scaling behavior, after it should serve as a base for a larger program.
> Therefore I run several tests both on the development machine (i7-6700)
> with 8 threads and the high-performance machine (E5-2560 v4
> )
> with 24 threads. Both machines were configured for using AVX-extensions in
> deal.II, and the program itself was compiled in release mode.
>
> When running the program in both configurations, I compared the time it
> took for taking the first step in time:
>
> Local machine:
> MPI-ThreadsTBB-ThreadsTime (s)
> 1 8  170
> 2 4  40
> 4 2  20
>
> HPC:
> MPI-ThreadsTBB-ThreadsTime (s)
> 1 24840
> 2 12887
> 4 6  424
> 8 3  41
> 12   2  28
> 24   1  14
>
> I do not fully understand that behavior: Why is the code so much slower on
> the E5 compared to the i7, except for 24 threads? Due to a different clock
> frequency, or newer structure (Broadwell vs Skylake)? Why is the transition
> from 1 MPI thread to 2 MPI threads on the i7 four times faster, but going
> from 2 MPI threads to 4 MPI threads only twice (which is expected)?
> Similarly for the E5: Going from 1 thread to 2 threads does not speed up
> the code at all. Going from two to four threads halves the execution time
> (as expected), but going from four to eight results in a factor of ten. The
> steps afterwards follow the expected pattern again.
>
> Are there any explanations for the observed behavior? And if not, what can
> I do for a deeper investigation?
>
> Thanks!
>
> --
> 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/01ac3d77-d9bf-4197-a9a9-1f220c0af696%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/CAOYDWbL1JHBma7sY1wEQ_76Ns%2B54fincvbY_MX66P6n3%2Bs4fgQ%40mail.gmail.com.


Re: [deal.II] Step-57

2020-03-02 Thread Daniel Arndt
Hussan,

Do you observe this problem with the unmodified step-57 or did you change
anything?
What does the full backtrace look like (running gdb)?

Best,
Daniel

Am Mo., 2. März 2020 um 09:42 Uhr schrieb hussan zeb :

> how can resolve this error in step-57,
> Scanning dependencies of target step-57
> [ 33%] Building CXX object CMakeFiles/step-57.dir/step-57.cc.o
> [ 66%] Linking CXX executable step-57
> [ 66%] Built target step-57
> [100%] Run step-57 with Debug configuration
> grid refinements: 0
> viscosity: 0.1
> Number of active cells: 432
> Number of degrees of freedom: 4188 (3696 + 492)
> FGMRES steps: 0
> The residual of initial guess is 0
>
>
> 
> Exception on processing:
>
> 
> An error occurred in line <534> of file
> 
> in function
> std::pair::active_cell_iterator,
> dealii::Point >
> dealii::GridTools::{anonymous}::find_active_cell_around_point_tolerance(const
> dealii::Mapping&, const MeshType&, const
> dealii::Point&, const std::vector&, double) [with int dim =
> 2; MeshType = dealii::DoFHandler; int spacedim = 2; typename MeshType spacedim>::active_cell_iterator =
> dealii::TriaActiveIterator 2>, false> >]
> The violated condition was:
> best_cell.first.state() == IteratorState::valid
> Additional information:
> The point <0.5 0.42> could not be found inside any of the subcells of
> a coarse grid cell.
> 
>
> Aborting!
> 
> CMakeFiles/run.dir/build.make:57: recipe for target 'CMakeFiles/run' failed
> make[3]: *** [CMakeFiles/run] Error 1
> CMakeFiles/Makefile2:195: recipe for target 'CMakeFiles/run.dir/all' failed
> make[2]: *** [CMakeFiles/run.dir/all] Error 2
> CMakeFiles/Makefile2:202: recipe for target 'CMakeFiles/run.dir/rule'
> failed
> make[1]: *** [CMakeFiles/run.dir/rule] Error 2
> Makefile:170: recipe for target 'run' failed
> make: *** [run] Error 2
> zeb@kutta:~/deal/examples/step-57> make run
>
> --
> 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/8a6dd884-c75b-4a05-a119-48e22ca0a3c1%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/CAOYDWbLsFxCfm041Ks0CCOxxbcMv2Spd0ncHfCNYQhJKu%3DJabA%40mail.gmail.com.


Re: [deal.II] Mesh refinement with periodic boundary conditions

2020-02-28 Thread Daniel Arndt
Andrew,

Still hard to say what the problem is. Which commit are you using?
We have quite a number of tests that make sure that adaptive grid
refinement also works with periodic boundary conditions.
Can you provide a full minimal example that shows the problem you need your
workaround for?

How are you assembling the linear system? Are you using MeshWorker,
MatrixFree or do you assemble matrices on your own using FEFaceValues?
Is your code working in serial and for global refinement?

Best,
Daniel


Am Fr., 28. Feb. 2020 um 08:29 Uhr schrieb Andrew Davis <
andrew@gmail.com>:

> I just say a slight problem and changed this line the declaration of
> periodicityVector to:
>
> std::vector Triangulation::cell_iterator>
> > periodicityVector;
>
> But I'm getting the same behavior.
>
> On Friday, February 28, 2020 at 8:08:19 AM UTC-5, Andrew Davis wrote:
>>
>> Yes, here is the code I used to tell the triangulation about the periodic
>> boundaries:
>>
>>   // create a mesh on [0,1] with colorized boundaries
>>   GridGenerator::hyper_cube(triangulation, 0.0, 1.0, true);
>>
>>   // collect the periodic boundary pairs
>>   std::vector> parallel::distributed::Triangulation::cell_iterator> >
>> periodicityVector;
>>   GridTools::collect_periodic_faces(triangulation, 0, 1, 0,
>> periodicityVector);
>>   GridTools::collect_periodic_faces(triangulation, 2, 3, 1,
>> periodicityVector);
>>
>>   triangulation.add_periodicity(periodicityVector);
>>
>>   // refine one less then maximum refinement level globally
>>   triangulation.refine_global(maxGridLevel-1);
>>
>> Perhaps I'm doing it wrong?
>>
>> On Thursday, February 27, 2020 at 10:47:09 PM UTC-5, Daniel Arndt wrote:
>>>
>>> Andrew,
>>>
>>> Did you tell the triangulation that it should take periodic boundaries
>>> into account? My best bet (with the information given) would be that you
>>> didn't call parallel::distributed::Triangulation::add_periodicity()
>>> <https://www.dealii.org/current/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html#aa7b797070e5443a18f03a4a7f0267453>
>>> as described in
>>> https://www.dealii.org/current/doxygen/deal.II/step_45.html.
>>>
>>> Best,
>>> Daniel
>>>
>>> Am Do., 27. Feb. 2020 um 17:45 Uhr schrieb Andrew Davis <
>>> andr...@gmail.com>:
>>>
>>>> HI all,
>>>>
>>>> I'm trying to implement a time-dependent convection equation using DG
>>>> elements with periodic boundary conditions on and adaptive mesh.
>>>>
>>>> However, when I try to adapt the mesh using periodic using this code:
>>>>
>>>>   // estimate the error in each cell
>>>>   Vector estimatedErrorPerCell(triangulation.n_active_cells());
>>>>   //KellyErrorEstimator::estimate(dofHandler,
>>>> QGauss(feSystem.degree + 1), {}, solution.block(0),
>>>> estimatedErrorPerCell);
>>>>   KellyErrorEstimator::estimate(dofHandler,
>>>> QGauss(feSystem.degree + 1), {}, solution, estimatedErrorPerCell);
>>>>
>>>>   // refine cells with the largest estimated error (80 per cent of the
>>>> error) and coarsens those cells with the smallest error (10 per cent of the
>>>> error)
>>>>   GridRefinement::refine_and_coarsen_fixed_fraction(triangulation,
>>>> estimatedErrorPerCell, 0.8, 0.1);
>>>>
>>>>   // to prevent the decrease in time step size limit the maximal
>>>> refinement depth of the meshlimit the maximal refinement depth of the mesh
>>>>   if( triangulation.n_levels()>maxGridLevel ) {
>>>> for( auto& cell :
>>>> triangulation.active_cell_iterators_on_level(maxGridLevel) ) {
>>>> cell->clear_refine_flag(); }
>>>>   }
>>>>
>>>>   // store previous and current solution on the coarser mesh
>>>>   std::vector > tempSolution(2);
>>>>   tempSolution[0] = oldSolution; tempSolution[1] = solution;
>>>>
>>>>   // transfer the solution vectors from the old mesh to the new one
>>>>   SolutionTransfer > transfer(dofHandler);
>>>>
>>>>   // prepare for the refinement---we have to prepare the transfer as
>>>> well
>>>>   *triangulation.prepare_**coarsening_and_refinement();* // for some
>>>> reason, this doesn't tell the cells across a periodic boundary that they
>>>> need to be refined
>>>>   transfer.prepare_for_coarsening_and_refinemen

Re: [deal.II] Mesh refinement with periodic boundary conditions

2020-02-27 Thread Daniel Arndt
Andrew,

Did you tell the triangulation that it should take periodic boundaries into
account? My best bet (with the information given) would be that you didn't
call parallel::distributed::Triangulation::add_periodicity()

as described in https://www.dealii.org/current/doxygen/deal.II/step_45.html.

Best,
Daniel

Am Do., 27. Feb. 2020 um 17:45 Uhr schrieb Andrew Davis <
andrew@gmail.com>:

> HI all,
>
> I'm trying to implement a time-dependent convection equation using DG
> elements with periodic boundary conditions on and adaptive mesh.
>
> However, when I try to adapt the mesh using periodic using this code:
>
>   // estimate the error in each cell
>   Vector estimatedErrorPerCell(triangulation.n_active_cells());
>   //KellyErrorEstimator::estimate(dofHandler,
> QGauss(feSystem.degree + 1), {}, solution.block(0),
> estimatedErrorPerCell);
>   KellyErrorEstimator::estimate(dofHandler,
> QGauss(feSystem.degree + 1), {}, solution, estimatedErrorPerCell);
>
>   // refine cells with the largest estimated error (80 per cent of the
> error) and coarsens those cells with the smallest error (10 per cent of the
> error)
>   GridRefinement::refine_and_coarsen_fixed_fraction(triangulation,
> estimatedErrorPerCell, 0.8, 0.1);
>
>   // to prevent the decrease in time step size limit the maximal
> refinement depth of the meshlimit the maximal refinement depth of the mesh
>   if( triangulation.n_levels()>maxGridLevel ) {
> for( auto& cell :
> triangulation.active_cell_iterators_on_level(maxGridLevel) ) {
> cell->clear_refine_flag(); }
>   }
>
>   // store previous and current solution on the coarser mesh
>   std::vector > tempSolution(2);
>   tempSolution[0] = oldSolution; tempSolution[1] = solution;
>
>   // transfer the solution vectors from the old mesh to the new one
>   SolutionTransfer > transfer(dofHandler);
>
>   // prepare for the refinement---we have to prepare the transfer as well
>   *triangulation.prepare_**coarsening_and_refinement();* // for some
> reason, this doesn't tell the cells across a periodic boundary that they
> need to be refined
>   transfer.prepare_for_coarsening_and_refinement(tempSolution);
>
>   // do the refinement and reset the DoFs
>   triangulation.execute_coarsening_and_refinement();
>   SetupSystem();
>
>   std::vector > temp(2);
>   ReinitializeVector(temp[0]); ReinitializeVector(temp[1]);
>   transfer.interpolate(tempSolution, temp);
>
>   oldSolution = temp[0]; solution = temp[1];
>
>   constraints.distribute(oldSolution);
>   constraints.distribute(solution);
>
> *I get this error:*
>
> 
> An error occurred in line <992> of file
>  in function
> void dealii::{anonymous}::update_periodic_face_map_recursively(const
> typename dealii::Triangulation::cell_iterator&, const
> typename dealii::Triangulation::cell_iterator&, unsigned
> int, unsigned int, const std::bitset<3>&, std::map dealii::Triangulation::cell_iterator, unsigned int>,
> std::pair spacedim>::cell_iterator, unsigned int>, std::bitset<3> > >&) [with int dim
> = 2; int spacedim = 2; typename dealii::Triangulation spacedim>::cell_iterator = dealii::TriaIterator
> >]
> The violated condition was:
> dim == 1 || std::abs(cell_1->level() - cell_2->level()) < 2
> Additional information:
> This exception -- which is used in many places in the library --
> usually indicates that some condition which the author of the code thought
> must be satisfied at a certain point in an algorithm, is not fulfilled. An
> example would be that the first part of an algorithm sorts elements of an
> array in ascending order, and a second part of the algorithm later
> encounters an element that is not larger than the previous one.
>
> There is usually not very much you can do if you encounter such an
> exception since it indicates an error in deal.II, not in your own program.
> Try to come up with the smallest possible program that still demonstrates
> the error and contact the deal.II mailing lists with it to obtain help.
>
> For some reason the refinement does not seem to know that the boundaries
> are periodic and that it should refine the cells on the other side of the
> domain. I tried changing the refinement step so that instead of just
> calling triangulation.prepare_coarsening_and_refinement();, I created my
> own function that mimics the distributed triangulation (calling the
> distributed version of enforce_mesh_balance_over_periodic_boundaries)
> that does the following:
>
> while( true ) {
> triangulation.prepare_coarsening_and_refinement();
> triangulation.update_periodic_face_map();
> bool changed =
> enforce_mesh_balance_over_periodic_boundaries(triangulation);
> if( !changed ) { break; }
>   }
>
> This fixed the error but I'm getting the strange behavior---it looks like
> the cell face fluxes are no longer being 

Re: [deal.II] Support for axisymmetric geometries

2020-02-21 Thread Daniel Arndt
Nick,

There is no built-in functionality in deal.II to support axisymmetric
problems. The best approach is probably reformulate your problem in
cylinder coordinates similarly as discussed in
https://groups.google.com/forum/#!searchin/dealii/rotational$20symmetry|sort:date/dealii/IPO7vDx0WnI/01J-KnEJBgAJ
.

Best,
Daniel

Am Fr., 21. Feb. 2020 um 14:07 Uhr schrieb Nicholas Deak <
nicholas_d...@alumni.brown.edu>:

> Hi all,
>
> I am trying to solve the Laplace problem for a 3D pin-to-pin plasma
> discharge with a voltage applied at one of the pins, so that we can take
> the solution and impose it on a 1D streamer simulation. I have attached a
> schematic showing the 3D configuration, as well as a 2D mesh that I rotated
> in gmsh to create the 3D mesh (given the problem's axisymmetric nature).
>
> The issue I'm having is that when I try to generate a hexahedra mesh in
> gmsh, I end up with a number tetrahedra, and a large number of elements in
> total (~60k) for my coarse grid. it seems like it may be easier to solve
> our problem on the 2D mesh, with axisymmetric BCs and source terms.
>
> To that end I was wondering - does deal.ii have any built in support for
> axisymmetric problems? I've looked through the examples available, but
> haven't seen anything that seems to address this issue directly. I'm
> guessing there is probably a relatively simple way to do this, but I am
> still fairly new to deal.ii so it wasn't clear to me what the best route
> would be. Any advice would be very much appreciated.
>
> Thanks,
> Nick
>
> --
> 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/3e7719c3-93dc-4d14-8342-117d8696ba98%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/CAOYDWbJRtUPGVjoweTv0HXO-M6ir5SqBrG4%3DC364s0JhCCcdZQ%40mail.gmail.com.


Re: [deal.II] Question on how MatrixTools::MatrixCreator sets the appropriate flags of FeValues?

2020-02-18 Thread Daniel Arndt
Krishna,

Adding to David's answer, mass matrix and laplace matrix are built for
multiple components separately, i.e. there is no coupling between them.

Best,
Daniel

Am Di., 18. Feb. 2020 um 10:17 Uhr schrieb David Wells :

> Hi Krishna,
>
> I'm not sure that I understand your question - those two functions
> create a mass matrix and a laplace corresponding to the given
> parameters (dof handler, mapping, quadrature, etc) - in the first case
> only shape values are needed and in the second only shape gradients.
> Hence the function knows which fields of UpdateFlags to set without
> the need for user input.
>
> > how do these interact when we have an FESystem?
>
> They still create the system mass and laplace matrices :)
>
> Thanks,
> David
>
> On Tue, Feb 18, 2020 at 8:17 AM Krishnakumar Gopalakrishnan
>  wrote:
> >
> > In the tutorials, Step-23 suddenly gets rid of the assemble_system()
> function and introduces MatrixTools::MatrixCreator::create_mass_matrix and
> MatrixTools::MatrixCreator::create_laplace_matrix
> >
> > However, there is no discussion whatsoever of how the appropriate update
> flags (bitfields) of the Fevalues object is set? Can someone help to
> explain the interface of these two aspects of the library? Additionally,
> how do these interact when we have an FeSystem?
> >
> > Krishna
> >
> > --
> > 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/dd6795cd-429c-42d4-95bc-2e63ad80b726%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/CABrTbYTXmaT3rscVuu3KsE%2BYB%2Btcebnk2HL99_NvHr60JKq_8w%40mail.gmail.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/CAOYDWbJsZXLOd3U6bqc_wCWuDsJ2HufG%3DxEnOUStmo89Rt8VSg%40mail.gmail.com.


Re: [deal.II] How to Make Test Functions Satisfy Certain Constraints

2020-02-17 Thread Daniel Arndt
Lex,

Just look at the first six tutorials at
https://www.dealii.org/current/doxygen/deal.II/Tutorial.html.

Best,
Daniel

Am So., 16. Feb. 2020 um 23:45 Uhr schrieb Lex Lee :

> Hello all,
>
>
> To numerically solve the governing equations I am studying now, I notice
> that the chosen three test functions should satisfy one of the boundary
> conditions. Namely, I need to set constraints for the test functions when
> developing the codes. I am wondering if I can do it in deal.ii. If so, can
> anyone give me some hints, I mean, study/reading material?
>
>
> Best,
>
> Lex Lee
>
> --
> 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/40fa19df-509d-4b78-a98c-db24ab1b2c66%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/CAOYDWb%2B%2B%2B%3DBxwrq8W-Tiog9ajUs%3DC85FkMif0e%3DW4wDAc4y7ww%40mail.gmail.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-10 Thread Daniel Arndt
Felipe,

The relevant error is at the end of the file:

Linking CXX executable cmTC_9dc5e
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/cmTC_9dc5e.dir/link.txt --verbose=1
/usr/bin/c++   -DDEAL_II_HAVE_USABLE_FLAGS_DEBUG -pedantic -fPIC -Wall
-Wextra -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch
-Woverloaded-virtual -Wno-deprecated-declarations -Wno-literal-suffix
-std=c++11 -Wno-parentheses -Wno-unused-local-typedefs -Og -ggdb
-Wa,--compress-debug-sections-rdynamic
CMakeFiles/cmTC_9dc5e.dir/src.cxx.o  -o cmTC_9dc5e  -rdynamic -fuse-ld=gold
pthread -ggdb -lm -ldl /usr/lib64/libz.so -lrt
c++: error: pthread: No such file or directory

This is the issue described in https://github.com/dealii/dealii/issues/9116
and fixed in https://github.com/dealii/dealii/pull/9117.

Best,
Daniel

Am Mo., 10. Feb. 2020 um 22:13 Uhr schrieb Felipe Orellana <
felipeorellanarovir...@gmail.com>:

>
>   Hello Dan,
>
>Thanks for your attention.
>
> I attach the CMakeError.log
>
> The first error is: c++: error: unrecognized command line option
> '-Wplacement-new'
>
>Maybe there is a chain sequence, so all sprouts from it..
>
> cheers many,
>
> Felipe
>
>
>
>
> On Mon, 10 Feb 2020 at 23:41, Daniel Arndt  wrote:
>
>>
>> So this is a strange bug. The problem is from the flag
>>> -Woverloaded-virtual With gcc 4.8 and 4.9 As you can see the flag
>>> alone works https://wandbox.org/permlink/GLbCK7qVqfScXrZp but if I add
>>> another flag it won't compile
>>> https://wandbox.org/permlink/4Lw7aNqGlJkik6SL If you have access to
>>> gcc 5 or later, I would advise you to use that instead. You can also
>>> try the latest version of deal.II maybe we don't use that flag
>>> anymore.
>>>
>>
>> The problem here are the additional quotes in the compiler arguments, see
>> https://godbolt.org/z/bwDjWy.
>>
>> Felipe, could you also send the file CMakeErrors.log?
>>
>> Best,
>> Daniel
>>
>> --
>> 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/CAOYDWb%2ByrLNsVfq7hcs%3D8inedF%2BoFhHYi9USJptYxE87Cv1P3g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/dealii/CAOYDWb%2ByrLNsVfq7hcs%3D8inedF%2BoFhHYi9USJptYxE87Cv1P3g%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/CABP9zGWpOFJQP38ypMmdPYCqsRFbVGnS-d1-VD3phYBfgVz1yw%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CABP9zGWpOFJQP38ypMmdPYCqsRFbVGnS-d1-VD3phYBfgVz1yw%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/CAOYDWbKukxhPHR_hWX%3DDD%2BcWyWOuHSPO%3DjdORY6XmVs5jt-Xug%40mail.gmail.com.


Re: [deal.II] Re: Problem installing Dealii-9.0.0

2020-02-10 Thread Daniel Arndt
> So this is a strange bug. The problem is from the flag
> -Woverloaded-virtual With gcc 4.8 and 4.9 As you can see the flag
> alone works https://wandbox.org/permlink/GLbCK7qVqfScXrZp but if I add
> another flag it won't compile
> https://wandbox.org/permlink/4Lw7aNqGlJkik6SL If you have access to
> gcc 5 or later, I would advise you to use that instead. You can also
> try the latest version of deal.II maybe we don't use that flag
> anymore.
>

The problem here are the additional quotes in the compiler arguments, see
https://godbolt.org/z/bwDjWy.

Felipe, could you also send the file CMakeErrors.log?

Best,
Daniel

-- 
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/CAOYDWb%2ByrLNsVfq7hcs%3D8inedF%2BoFhHYi9USJptYxE87Cv1P3g%40mail.gmail.com.


Re: [deal.II] Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

2020-02-08 Thread Daniel Arndt
Vachan,

3. With LAPACK, the story is different. I noticed that deal.II's version of
> FindLAPACK.cmake uses the system installed cmake's FindLAPACK.cmake. And
> then I came across this question on SO:
> https://stackoverflow.com/questions/54681204/cray-cc-wrapper-cmake-find-package-blas
> and subsequently to the link
> https://gitlab.kitware.com/cmake/cmake/merge_requests/3451. So on cray
> environments, cmake's version of FindLAPACK.cmake can detect LAPACK
> library only if cmake version is >=3.16. Our system has 3.5.2. Also, the
> LAPACK library is not standalone but a part of cray's libsci module and is
> present in the library sci_gnu_61_mpi_mp along with BLAS, SCALAPACK and
> others. How can I invoke cmake such that it recognises LAPACK library as a
> part of this whole library?
>

If only an old version is the problem, I would just go ahead and download
and compile a recent version myself. I never had any issues with that and
should be quite simple.

Best,
Daniel

-- 
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/CAOYDWbK9auxXEqfxD%3DB6H%2B4mF9%3DBHk1zGh8HnWcN-3pVMuBaGA%40mail.gmail.com.


Re: [deal.II] deal.II installation on cray XC50 giving MPI_VERSION=0.0

2020-02-06 Thread Daniel Arndt
Vachan,

You can probably tell better than any of us if this works. Just try. It
might quite well be that the compiler doesn't need any extra flags for MPI.
Also, it looks like the MPI version could not be detected. This implies
that the library doesn't use newer features but should still work. If you
know to which standard the MPI installation is conforming, you could try to
set it via

cmake -DMPI_VERSION=...

yourself.
If there any more problems, feel free to tell us.

Best,
Daniel

On Thu, Feb 6, 2020, 1:10 AM vachan potluri 
wrote:

> Hello,
>
> I am trying to install deal.II on a cray XC50 supercomputer.
>
> cmake -DCMAKE_INSTALL_PREFIX=~/bin/dealii-9.1.1 \
> -DPREFIX_PATH=/opt/cray/pe \
> -DCMAKE_CXX_COMPILER=/opt/cray/pe/craype/2.5.13/bin/CC \
> -DWITH_MPI=ON \
> -DWITH_PETSC=OFF -DPETSC_DIR=$PETSC_DIR -DPETSC_ARCH=$PETSC_ARCH \
> -DWITH_P4EST=ON -DP4EST_DIR=~/bin/p4est-2.2 \
> ~/source/dealii-9.1.1
>
> I have attached detailed.log and summary.log. Although the configuring
> exits without errors, I can see in detailed.log that MPI_VERSION was not
> detected correctly. The compilers were correctly detected. All other
> variables are just blanks. The relevant snippet of detailed.log is as
> follows:
>
> #DEAL_II_WITH_MPI set up with external dependencies
> #MPI_VERSION = 0.0
> #MPI_C_COMPILER = /opt/cray/pe/craype/2.5.13/bin/cc
> #MPI_CXX_COMPILER = /opt/cray/pe/craype/2.5.13/bin/CC
> #MPI_Fortran_COMPILER = /opt/cray/pe/craype/2.5.13/bin/ftn
> #MPI_CXX_FLAGS =
> #MPI_LINKER_FLAGS =
> #MPI_INCLUDE_DIRS =
> #MPI_USER_INCLUDE_DIRS =
> #MPI_LIBRARIES =
>
> Is this an issue? How to fix this? I had loaded cray-mpich module before
> invoking cmake and switched PrgEnv-cray with PrgEnv-gnu.
>
> --
> 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/71a50bd5-acf1-4cd5-b3a8-bcb0fd295399%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/CAOYDWb%2BvyVruFzjC4NCam%2BxF%2BcPmSEpMbh_MSenzcd6hf5qkMg%40mail.gmail.com.


Re: [deal.II] Question on KINSOL::SUNDIALS

2020-02-05 Thread Daniel Arndt
Rochan,

there is Algorithms::Newton that can be used to set up a Newton method and
there are multiple tutorial examples that deal with nonlinear problems.
Have a look at step-15, step-25, step-44 and in particular step-42.

Best,
Daniel

On Tue, Feb 4, 2020, 6:45 PM rru  wrote:

> Dear dealii developers,
>
> I have a quick question on non-linear solvers in dealii.
> As far as I could gather, the only option for a newton solver is the
> wrapper SUNDIALS::KINSOL, and for DAE the wrapper SUNDIALS::IDA. Is that
> correct ?
> In that event, is it possible to set up inequality constraints. In the
> documentation it is mentioned that the following "optional" functions can
> be supplied but syntax or description for them is not provided :
>
>- get_lower_than_zero_constrained_entries()
>- get_greater_than_zero_constrained_entries()
>- get_lower_equal_than_zero_constrained_entries()
>- get_greater_or_equal_than_zero_constrained_entries()
>
> Regards,
> Rochan
>
>
> --
> 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/8c34994d-1ef3-4930-83e6-dc25c3c873c9%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/CAOYDWbK9g19obM4RtpxaQHVGNMiKPcvdz84cA3Yrq0xEbPmUCQ%40mail.gmail.com.


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

2020-01-28 Thread Daniel Arndt
Feimi,

it's picking the wrong overload.

Utilities::MPI::sum(local_vector, mpi_communicator, local_vector);

works as well as

Utilities::MPI::sum(my_view, mpi_communicator, my_view);

Best,
Daniel



Am Di., 28. Jan. 2020 um 12:57 Uhr schrieb Feimi Yu :

> Hi Bruno,
>
> Thanks for your reply!
> That's not true. The input and output arrays may be the same as described
> in the documentation. The template instatiation error does not check
> whether they are the same, either.
> In addition, two different arrays give the same error.
>
> Feimi
>
> On Tuesday, January 28, 2020 at 12:09:38 PM UTC-5, Bruno Turcksin wrote:
>>
>> Feimi,
>>
>> You need to have two different ArrayView. It won't work with a single
>> ArrayView. The input one (values) need to be an ArrayView and
>> the output one (sum) an ArrayView.
>>
>> Best,
>>
>> Bruno
>>
>> On Tuesday, January 28, 2020 at 11:40:03 AM UTC-5, Feimi Yu wrote:
>>>
>>> I uploaded a minimal code to reproduce the problem I encountered.
>>>
>>> Thanks!
>>> Feimi
>>>
>>> On Monday, January 27, 2020 at 1:42:18 PM UTC-5, Feimi Yu wrote:

 Hi,

 I was trying to use the the function Utilities::MPI::sum
 
 (const ArrayView
 <
 const T > , const MPI_Comm _communicator, const ArrayView
 <
 T > )
 for an std::vector. I created an ArrayView to pack the vector
 and passed it into this function. However, the compiler keeps telling me:

 undefined reference to 'void
 dealii::Utilities::MPI::sum, dealii::ArrayView
 >(dealii::ArrayView const&, ompi_communicator_t* const&,
 dealii::ArrayView&)'

 I checked base/mpi.inst.in and cmake/config/template-arguments.in. Int
 type should be included in the instantiation list, but I could not figure
 out why this does not work for me.

 Thanks!
 Feimi

 --
> 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/e35102aa-3f62-4371-8cb6-474ea4c5fd69%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/CAOYDWbLAodVgEqNM%3DuAJW%3DQSam1JhsA2T-RXDVa--tfb7KX9mQ%40mail.gmail.com.


Re: [deal.II] Install Deal.ii-9.1.1 on windows using cmake and visual studio

2020-01-27 Thread Daniel Arndt
Amir,

Windows support is experimental and we only test for the latest versions.
According to
https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html CMake
3.16.3 should support "Visual Studio 16 2019" as generator.
The error in the attached file arises from `perl` not being present which
is required for building the documentation locally. If you just disable
that feature via
cmake -DDEAL_II_COMPONENT_DOCUMENTATION=OFF .
I would expect the error to vanish.

Best,
Daniel


Am So., 26. Jan. 2020 um 09:45 Uhr schrieb amir kiani <
amirkiani2...@gmail.com>:

> Dear all
> I am trying to install deal.ii-9.1.1 on windows 7.
> To do this, after installing visual studio 2019 and Cmake 3.16.3, I try to
> configure and generate deal.ii files with Cmake.First I try to follow
> instructions that are given in wiki by using cmd. but in cmd error "CMake
> Error: Could not create named generator Visual Studio 16 2019 Win64".
> then I decided to use the CMake interface. after specifying the location
> of the source and build, I clicked on configure. but a lot of problems are
> warned by CMake.
> I attached these errors to this question.
> I will be thankful anybody can help me.
>
> --
> 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/64030cde-384e-4252-b9f3-fac47203633b%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/CAOYDWbKJ-3kVCcuffXLdpzWyuRdV%3Dcg3LDyHyedXF9fpTiwZdg%40mail.gmail.com.


Re: [deal.II] IterativeInverse function appears to have disappeared between v8.5.0 and v9.0.0?

2020-01-20 Thread Daniel Arndt
Krishna,

[...]
> Can someone please point me in the right direction regarding the
> documentation of this class for the latest release of dealii?
>

Have a look at
https://www.dealii.org/current/doxygen/deal.II/changes_between_8_5_0_and_9_0_0.html,
item 70.

Best,
Daniel

-- 
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/CAOYDWbLvO07LaMabgRFmquW6d%2Bxvsi0eTQFVRnJsZ5cLx6wQhQ%40mail.gmail.com.


Re: [deal.II] Re: Application of inverse mass matrix in matrix-free context using cell_loop instead of scale()

2020-01-18 Thread Daniel Arndt
Maxi,

As usual, it is much easier to help if you provide a complete minimal
example and say how the result differs from what you expect.
Does it only scale certain vector entries? Are the results correct when
running with one MPI process?
How does your approach differ from
https://github.com/dealii/dealii/blob/b84270a1d4099292be5b3d43c2ea65f3ee005919/tests/matrix_free/pre_and_post_loops_01.cc#L100-L121
?

Best,
Daniel

Am Sa., 18. Jan. 2020 um 12:05 Uhr schrieb 'Maxi Miller' via deal.II User
Group :

> I tried implementing it as
> data.cell_loop(::local_apply_cell,
>this,
>dst,
>src,
>//true,
>[&](const unsigned int start_range, const unsigned
> int end_range){
> for(size_t i = start_range; i < end_range; ++i){
> dst.local_element(i) = 0;
> }
> },
> [&](const unsigned int start_range, const unsigned int end_range){
> for(unsigned int i = start_range; i < end_range; ++i){
> dst.local_element(i) = dst.local_element(i) *
> inv_mass_matrix.local_element(i);
> }
> });
>
> but the result was not correct. Thus, I assume I have to do something else?
> Thanks!
>
> Am Samstag, 18. Januar 2020 17:12:34 UTC+1 schrieb peterrum:
>>
>> Yes, like here
>> https://github.com/dealii/dealii/blob/b84270a1d4099292be5b3d43c2ea65f3ee005919/tests/matrix_free/pre_and_post_loops_01.cc#L100-L121
>>
>> On Saturday, 18 January 2020 12:57:24 UTC+1, Maxi Miller wrote:
>>>
>>> In step-48 the inverse mass matrix is applied by moving the inverse data
>>> into a vector and applying the function scale(), i.e. as in the following
>>> code:
>>> data.cell_loop(::local_apply_cell,
>>>this,
>>>dst,
>>>src,
>>>true);
>>> computing_times[0] += timer.wall_time();
>>> timer.restart();
>>>
>>>dst.scale(inv_mass_matrix);
>>>
>>>
>>>
>>> Now I would like to do the same, but use a cell_loop instead of scale().
>>> Thus, I created an additional function called
>>> "local_apply_inverse_mass_matrix" as
>>> template 
>>> void LaplaceOperator::
>>> local_apply_inverse_mass_matrix(
>>> const MatrixFree &   data,
>>> LinearAlgebra::distributed::Vector &  dst,
>>> const LinearAlgebra::distributed::Vector ,
>>> const std::pair & cell_range
>>> ) const
>>> {
>>> (void) data;
>>> (void) cell_range;
>>> dst = src;
>>> dst.scale(inv_mass_matrix);
>>> }
>>>
>>> When running that code, though, using
>>> LinearAlgebra::distributed::Vector tmp(src);
>>>
>>> data.initialize_dof_vector(tmp);
>>> data.initialize_dof_vector(dst);
>>> data.cell_loop(::local_apply_cell,
>>>this,
>>>tmp,
>>>src,
>>>true);
>>> computing_times[0] += timer.wall_time();
>>> timer.restart();
>>>
>>> data.cell_loop(::local_apply_inverse_mass_matrix
>>> ,
>>>this,
>>>dst,
>>>tmp,
>>>true);
>>> computing_times[1] += timer.wall_time();
>>>
>>> computing_times[3] += 1.;
>>>
>>>
>>> I get the error
>>> An error occurred in line <3338> of file >> matrix_free/matrix_free.h> in function
>>> void dealii::internal::VectorDataExchange>> VectorizedArrayType>::compress_start(unsigned int, VectorType&) [with
>>> VectorType = dealii::LinearAlgebra::distributed::Vector;
>>> typename std::enable_if<(dealii::internal::has_compress_start>> >::value && dealii::internal::has_exchange_on_subset::value
>>> ), VectorType>::type*  = 0; int dim = 2; Number = double;
>>> VectorizedArrayType = dealii::VectorizedArray]
>>> The violated condition was:
>>> vec.has_ghost_elements() == false
>>> Additional information:
>>> You are trying to use functionality in deal.II that is currently not
>>> implemented. In many cases, this indicates that there simply didn't
>>> appear much of a need for it, or that the author of the original code did
>>> not have the time to implement a particular case. If you hit this
>>> exception, it is therefore worth the time to look into the code to find out
>>> whether you may be able to implement the missing functionality. If you do,
>>> please consider providing a patch to the deal.II development sources (see
>>> the deal.II website on how to contribute).
>>>
>>> Stacktrace:
>>> ---
>>> #0  ./MF_FES_RK4-Test: void dealii::internal::VectorDataExchange<2,
>>> double, dealii::VectorizedArray
>>> >::compress_start>> dealii::MemorySpace::Host>,
>>> (dealii::LinearAlgebra::distributed::Vector>> dealii::MemorySpace::Host>*)0>(unsigned int,
>>> 

Re: [deal.II] Using solution on from one FE problem as a boundary condition for another

2020-01-14 Thread Daniel Arndt
Ernesto,

Imposing strong boundary conditions should not be overly difficult in this
case.
Just as Wolgang said you should have a look at
interpolate_boundary_values() and replace the Function object evaluations
on each cell by the function values given through
a FEValues object initialized for your first solution. Assuming that you
are using interpolatory ansatz functions, this interpolation has to happen
at the support points of your target finite element.
In particular, these support points should be the quadrature points for the
FEValues object.

Best,
Daniel

Am Di., 14. Jan. 2020 um 01:50 Uhr schrieb Ernesto Ismail <
ernesto.ism...@gmail.com>:

> Dear Prof. Bangerth,
>
> Thank you for your reply.
>
> I would ideally have liked to impose the boundary conditions strongly but
> it looks like doing so will not be straight-forward. I will do some
> investigations into applying the boundary conditions weakly and attempt
> that first.
>
> One approach I had tried was to use Lobatto quadrature and use a
> quadrature point history data structure to transfer the solution at the
> boundary. The problem with this approach was that the differing element
> types lead to some strange behaviours along the boundary.
>
> Thanks again,
> Ernesto
>
> On Thursday, 9 January 2020 23:43:27 UTC+2, Wolfgang Bangerth wrote:
>>
>>
>> Ernesto,
>>
>> > I am currently working with a staggered coupled system where I am
>> solving
>> > several finite element problems in sequence. Up until now my boundary
>> > conditions have been fairly straightforward and I've been able to get
>> > meaningful results from my work.
>> >
>> > The finite element schemes I use for each step are fairly different,
>> with some
>> > being discontinuous and of varying orders.
>> >
>> > I am now in a position where I need to use the solution of one of my
>> steps as
>> > the boundary condition for the next (I actually need to combine two of
>> them
>> > with a simple arithmetic function, but baby steps for now). I presume I
>> need
>> > to use some sort of projection to achieve this, but I'm not exactly
>> sure how
>> > to go about it. I thought to try and use the project_boundary_values()
>> > function to do what I need, but I am unsure how I would structure
>> > the boundary_functions argument.
>>
>> Do you need to enforce these boundary conditions strongly? If you can
>> enforce
>> them weakly, then the solution of one problem only enters the weak form
>> of
>> another problem (in that case through a boundary integral) and that is
>> really
>> not very different from the way we do this in other problems where we
>> have
>> multiple DoFHandlers -- e.g., in step-31. (Though my usual advice still
>> holds
>> true that I think everything becomes simpler if you pack everything into
>> one
>> DoFHandler).
>>
>> It gets more complicated if you want to impose strong boundary
>> conditions.
>> You've already found the FEFieldFunction function, but it's complicated
>> and
>> slow. A simpler way would be if you looked at the implementation of the
>> interpolate_boundary_values() function and identified where it is asking
>> the
>> Function object for its values. That's the place where you'd need to
>> somehow
>> combine your existing solutions into something else and turn that into a
>> constraint.
>>
>> 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/832bb83a-7e04-4243-9524-64db1bfc9345%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/CAOYDWbKY2%3D%2BBdWX4mh7guYEROFPT7mX8QR%3D4ED4KWymi_cD7Aw%40mail.gmail.com.


Re: [deal.II] Is it bug?

2019-12-13 Thread Daniel Arndt
Navneet, what happens if you run your program in gdb or some other debugger?

Am Fr., 13. Dez. 2019 um 13:02 Uhr schrieb navneet roshan <
navneetrosh...@gmail.com>:

> Hi Daniel,
>
> Thank you for the quick response, If I change line number 190 in the code,
> to 1 from 4. I am getting following error but no further information even
> in the debug mode.
>
>
> make[3]: *** [CMakeFiles/run.dir/build.make:58: CMakeFiles/run]
> Segmentation fault (core dumped)
> make[2]: *** [CMakeFiles/Makefile2:265: CMakeFiles/run.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:272: CMakeFiles/run.dir/rule] Error 2
> make: *** [Makefile:196: run] Error 2
>
> Navneet
>
> On Fri, Dec 13, 2019 at 11:00 PM Daniel Arndt 
> wrote:
>
>> Navneet,
>>
>> What is the error you are observing?
>>
>> Best,
>> Daniel
>>
>> Am Fr., 13. Dez. 2019 um 11:44 Uhr schrieb navneet roshan <
>> navneetrosh...@gmail.com>:
>>
>>> Dear Deal.II community,
>>>
>>> I have been using deal.ii for more than a year. I am solving the
>>> reaction-diffusion problem, I am getting a bizarre runtime error in the
>>> parallel solver. I am using PETSc CG solver. The error appeared after
>>> parallelization.  After 3-4 days of debugging, I found the error appears
>>> only if I am using '*repetition*' 
>>> (GridGenerator::subdivided_hyper_rectangle(triangulation,repetitions,
>>> a, b,false)) in the rectangular (
>>> GridGenerator::subdivided_hyper_rectangle) domain mesh creation. I am
>>> attaching a  minimal code showing the issue(minimal_diff_code.cc).
>>>
>>>  I am calling it bizarre because the code runs perfectly with few
>>> combinations of *'repetitions' *and Global mesh Refinement numbers, but
>>> fails with some other combinations. A table(error_Table.pdf) is attached
>>> showing how the error depends on the number of *repetitions* and 
>>> *global_refinement,
>>> *and sometimes also on the number of* processes* used*. *I have tested
>>> it in deal.ii 8.5.1 and 9.0.0 also.
>>>
>>> I will be thankful if someone could look into this.
>>>
>>> Thank you
>>> Navneet
>>>
>>>
>>> --
>>> 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/CAK9McD15f4B4e94-pFfdj84HmWAOhe0Btd41Hi0uBAozE4ma9A%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/dealii/CAK9McD15f4B4e94-pFfdj84HmWAOhe0Btd41Hi0uBAozE4ma9A%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/CAOYDWbKhrrKQ3GqwiyVuOTAAxSaugAb%3Du0%3DFsFXb8n7M%3DuiBzA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/dealii/CAOYDWbKhrrKQ3GqwiyVuOTAAxSaugAb%3Du0%3DFsFXb8n7M%3DuiBzA%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/CAK9McD1%3D6tNDTjaR3OYiggEE-MHkLp6st9bmeXPqhvXEhLkUWw%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAK9McD1%3D6tNDTjaR3OYiggEE-MHkLp6st9bmeXPqhvXEhLkUWw%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/CAOYDWbK-WRv5O6WvTERw1x%2Bda8P1NH4CwVtB0aW7BS5rjJnLAA%40mail.gmail.com.


Re: [deal.II] Is it bug?

2019-12-13 Thread Daniel Arndt
Navneet,

What is the error you are observing?

Best,
Daniel

Am Fr., 13. Dez. 2019 um 11:44 Uhr schrieb navneet roshan <
navneetrosh...@gmail.com>:

> Dear Deal.II community,
>
> I have been using deal.ii for more than a year. I am solving the
> reaction-diffusion problem, I am getting a bizarre runtime error in the
> parallel solver. I am using PETSc CG solver. The error appeared after
> parallelization.  After 3-4 days of debugging, I found the error appears
> only if I am using '*repetition*' 
> (GridGenerator::subdivided_hyper_rectangle(triangulation,repetitions,
> a, b,false)) in the rectangular (GridGenerator::subdivided_hyper_rectangle)
> domain mesh creation. I am attaching a  minimal code showing the
> issue(minimal_diff_code.cc).
>
>  I am calling it bizarre because the code runs perfectly with few
> combinations of *'repetitions' *and Global mesh Refinement numbers, but
> fails with some other combinations. A table(error_Table.pdf) is attached
> showing how the error depends on the number of *repetitions* and 
> *global_refinement,
> *and sometimes also on the number of* processes* used*. *I have tested it
> in deal.ii 8.5.1 and 9.0.0 also.
>
> I will be thankful if someone could look into this.
>
> Thank you
> Navneet
>
>
> --
> 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/CAK9McD15f4B4e94-pFfdj84HmWAOhe0Btd41Hi0uBAozE4ma9A%40mail.gmail.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/CAOYDWbKhrrKQ3GqwiyVuOTAAxSaugAb%3Du0%3DFsFXb8n7M%3DuiBzA%40mail.gmail.com.


Re: [deal.II] Re: FE_Q

2019-11-29 Thread Daniel Arndt
Oli,

what is your question? Please elaborate and we are happy to help. You might
want to have a look at
"Getting started and posting guidelines for new users" at
https://groups.google.com/forum/#!topic/dealii/GRZMUTLIm2I.

Best,
Daniel

Am Fr., 29. Nov. 2019 um 14:26 Uhr schrieb Oliver Br :

> Hi Daniel,
> Thank you for your answer. My question is about step3 in which:
> Triangulation<2>
> <https://www.dealii.org/current/doxygen/deal.II/classTriangulation.html>
> triangulation;
> FE_Q<2>
> <https://www.dealii.org/current/doxygen/deal.II/classFE__Q.html>
> fe;
> Best,
> Oli
>
> On Thursday, November 28, 2019 at 7:43:37 PM UTC-5, Daniel Arndt wrote:
>>
>> Oli,
>>
>> you need to specify a polynomial degree you want to use. If you have a
>> look at step-2 (
>> https://www.dealii.org/current/doxygen/deal.II/step_2.html),
>> you see that it has a line saying
>>
>> const FE_Q<2>
>> <https://www.dealii.org/current/doxygen/deal.II/classFE__Q.html>
>> finite_element(1);
>>
>> to create a linear finite element.
>>
>> Best,
>> Daniel
>>
> --
> 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/10c07b05-d200-4c81-8ddc-4a5489bf3095%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/10c07b05-d200-4c81-8ddc-4a5489bf3095%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/CAOYDWbKk7TAo5Pwe1u50BFugEs2i8TS2qt07a3WXz6doTgcB_g%40mail.gmail.com.


[deal.II] Re: FE_Q

2019-11-28 Thread Daniel Arndt
Oli,

you need to specify a polynomial degree you want to use. If you have a look 
at step-2 (https://www.dealii.org/current/doxygen/deal.II/step_2.html),
you see that it has a line saying

const FE_Q<2> 
 
finite_element(1);

to create a linear finite element.

Best,
Daniel

-- 
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/fda008e3-2bc5-4278-a0b5-787cf7b3991f%40googlegroups.com.


Re: [deal.II] Install dealii failed in Supercomputer center

2019-11-28 Thread Daniel Arndt
The error you are seeing is related to
https://github.com/dealii/dealii/pull/7767/commits/48954cca022288b739fb598b2be76cf15c5d28be.
We haven't seen this problem before. You should be able to just remove the
exception specifier as a workaround, i.e.
change the respective code to

FECollection(FECollection &&) = default;

Use a newer compiler version should help as well.
One other thing I noticed, is that you are using
-DDEAL_II_CXX_FLAGS=-std=c++14 and get multiple C++ standard flags because
of that.
You should just use -DDEAL_II_WITH_CXX_14=ON instead (or just omit it if
you don't explicitly need it).

Best,
Daniel


Am Do., 28. Nov. 2019 um 08:00 Uhr schrieb llf m :

> error occurs in make install
>
> [ 39%] Generating vector_tools_project_qpmf.inst
> [ 39%] Generating vector_tools_rhs.inst
> [ 39%] Built target obj_numerics_inst
> Scanning dependencies of target obj_numerics_release
> [ 39%] Building CXX object
> source/numerics/CMakeFiles/obj_numerics_release.dir/data_out.cc.o
> icpc: command line warning #10121: overriding '-std=c++11' with
> '-std=c++14'
> In file included from
> /BIGDATA1/dealii-9.1.1/source/numerics/data_out.cc(665):
> /BIGDATA1/dealii-9.1.1/include/deal.II/hp/fe_collection.h(145): error: the
> declared exception specific
> ation is incompatible with the generated one
> FECollection(FECollection &&) noexcept(
>   ^
>
> 在 2019年11月28日星期四 UTC+8下午7:19:28,llf m写道:
>>
>> Dear Daniel,
>> Yes, your are right, and after clean the build directory and change the
>> gcc version the 2) errors disappear but other errors appear:
>>
>> In file included from
>> /BIGDATA1/dealii-9.1.1/source/numerics/data_out.cc(665):
>> /BIGDATA1/dealii-9.1.1/include/deal.II/hp/fe_collection.h(145
>> <http://deal.ii/hp/fe_collection.h(145>): error: the declared exception
>> specific
>> ation is incompatible with the generated one
>> FECollection(FECollection &&) noexcept(
>>   ^
>>
>> In file included from
>> /BIGDATA1/dealii-9.1.1/source/numerics/data_out.cc(665):
>> /BIGDATA1/dealii-9.1.1/include/deal.II/hp/fe_collection.h(145
>> <http://deal.ii/hp/fe_collection.h(145>): error: the declared exception
>> specific
>> ation is incompatible with the generated one
>> FECollection(FECollection &&) noexcept(
>>   ^
>>
>> compilation aborted for
>> /BIGDATA1/dealii-9.1.1/source/numerics/data_out.cc (code 2)
>> make[2]: *** [source/numerics/CMakeFiles/obj_numerics_
>> release.dir/data_out.cc.o] Error 2
>> make[1]: *** [source/numerics/CMakeFiles/obj_numerics_release.dir/all]
>> Error 2
>> make: *** [all] Error 2
>>
>> and  I change the compile option to:
>> cmake .. -DDEAL_II_WITH_MPI=ON -DDEAL_II_WITH_BLAS=ON
>> -DBLAS_DIR=/BIGDATA1/app/blas/3.5.0-icc-15.0.1 -DDEAL_II_WITH_LAPACK=ON
>> -DLAPACK_DIR=/BIGDATA1/app/lapack/3.5.0-icc-15.0.1 -DDEAL_II_WITH_HDF5=ON
>> -DHDF5_DIR=/BIGDATA1/app/hdf5/1.8.17-icc-15.0.1-parallel
>> -DDEAL_II_WITH_NETCDF=ON
>> -DNETCDF_DIR=/BIGDATA1/app/netcdf/4.4.1-icc-15.0.1-parallel
>> -DNETCDF_INCLUDE_DIR=/BIGDATA1/app/netcdf/4.4.1-icc-15.0.1-parallel/include
>> -DDEAL_II_WITH_PETSC=ON
>> -DPETSC_DIR=/BIGDATA1/app/petsc/3.6.4-icc-15.0.1-gcc-4.9.2
>> -DPETSC_ARCH=arch-linux2-c-opt
>> -DBOOST_DIR=/BIGDATA1/app/boost/1.59.0-icc-15.0.1-mpich-3.2.1
>> -DARPACK_DIR=/BIGDATA1/app/arpack/96-icc-15.0.1/ARPACK
>> -DDEAL_II_WITH_ARPACK=ON -DMETIS_DIR=/BIGDATA1/app/METIS/5.1.0-icc-15.0.1
>> -DDEAL_II_WITH_METIS=ON
>> -DMUPARSER_DIR=/BIGDATA1/app/muparser/2.2.5-icc-15.0.1
>> -DDEAL_II_WITH_MUPARSER=ON -DP4EST_DIR=/BIGDATA1/app/p4est/2.2-icc-15.0.1
>> -DDEAL_II_WITH_P4EST=ON -DDEAL_II_WITH_SLEPC=ON
>> -DSLEPC_DIR=/BIGDATA1/app/SLEPc/3.6.1-icc-15.0.1-gcc-4.9.2
>> -DDEAL_II_WITH_TRILINOS=ON
>> -DTRILINOS_DIR=/BIGDATA1/app/trilinos/12.10.1-icc-15.0.1
>> -DDEAL_II_WITH_OPENCASCADE=OFF -DCMAKE_INSTALL_PREFIX=/BIGDATA1/app/
>> deal.II/9.1.1-icc-15.0.1 <http://deal.ii/9.1.1-icc-15.0.1> 
>> -DCMAKE_CXX_COMPILER=icpc
>> -DCMAKE_C_COMPILER=icc -DCMAKE_Fortran_COMPILER=ifort
>> -DDEAL_II_CXX_FLAGS=-std=c++14 -DDEAL_II_WITH_64BIT_INDICES=ON
>>
>> the make error likes:
>>
>> [image: 04bccbfcdacdad3e9dd34d062980a1ff (1).png]
>>
>> If you need more information or more suggestions please tell me .
>> Best,
>> m.
>> 在 2019年11月28日星期四 UTC+8上午12:38:25,Daniel Arndt写道:
>>>
>>> m,
>>>
>>> Did you start again from a clean build directory?
>>> The errors you are reporting in 2) are in fact just feature checks and
>>> should not cause configuring to fail. Does CMake complete s

Re: [deal.II] Problem with FESystem and VectorTools::project_boundary_values_curl_conforming_l2 in 3d

2019-10-29 Thread Daniel Arndt
Winni,

Would you mind creating a pull request for the first issue you are
reporting?

Best,
Daniel

Am Di., 29. Okt. 2019 um 13:06 Uhr schrieb winnifried <
woll...@mathematik.tu-darmstadt.de>:

> Dear all,
>
> I encountered the following issue while trying to solve a Maxwell
> eigenvalue problem in dealii v 9.1.1.
>
> When using an FESystem<3> containing one FENedelec and other elements and
> trying to set boundary values
> via
>
> VectorTools::project_boundary_values_curl_conforming_l2
>
> where the argument of first_vector_component is set to the starting
> component of the FENedelec.
> The problem has two parts, the first is solved the second is not and input
> is appreciated.
>
> Part 1 (solved):
> When the FESystem contains two FENedelec of different degree.
>
> Running the attached code (main.cc) ends in debug mode with the
> error
>
> The violated condition was:
> associated_edge_dofs == degree + 1
> Additional information:
> Error: Unexpected number of 3D edge DoFs
>
> triggered by line 31 (main.cc).
>
> The error is caused by the fact, that in vector_tools.templates.h the
> degree is calculated using
>
> fe.degree - 1
>
> which for FESystem is the wrong value as it is the maximum degree and not
> the degree of the selected element.
> It seems to me, that a fix for this is to use
>
> fe.base_element(base_indices.first).degree - 1;
>
> a few lines later once the user indicated base_element is known.
> Once this is done, in debug mode in the attached example line 31 still
> gives an error since
> in VectorTools::compute_face_projection_curl_conforming_l2 a 0-by-0 matrix
> for the face dofs is to be inverted.
> I am not sure why this pops up as it did not appear with the original
> version using only FENedelec of lowest order.
>
> Anyways this seems to be easy to fix. A patch for vector_tools.templates.h
> (in dealii v9.1.1) is attached
> - it is not tested that the computed result is correct, only that this
> fixes the wrongly chosen degree and produces no errors.
>
> Part 2 (input needed):
> Unfortunately this did not solve the original problem in full. If the
> FESystem does not only contain FENedelec, but another FE_Q
> and after applying the patch the original error "Unexpected number of 3D
> edge DoFs"
> still pops up in line 42 of the attached example, this time not because
> the wrong degree is selected, but because the
>
> if(((dynamic_cast *>() !=
> nullptr) ...
>
> statement in line 5440 of the patched vector_tools.templates.h is never
> true in this case.
> Any input on why this might happen is appreciated - in particular whether
> the assumptions made on the ordering of the
> dofs is correct for such FESystems.
>
> Thanks
> Winni
>
> --
> 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/1eea5fd0-6acb-40e1-b55d-43d94d8fe22d%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/CAOYDWb%2B2Y39cHOS9cKQ3b-3zNHEhNyC_xc9Qp9srKsqHD6Z5ng%40mail.gmail.com.


Re: [deal.II] Bug:Chebyshev preconditioner of 0th degree

2019-10-12 Thread Daniel Arndt
MIchaĺ,

The documentation in the developer version or the current version (
https://www.dealii.org/developer/doxygen/deal.II/classPreconditionChebyshev.html)
says:
"[...] Note that if the degree variable is set to one, the Chebyshev
iteration corresponds to a Jacobi preconditioner (or the underlying
preconditioner type) with relaxation parameter according to the specified
smoothing range. [...]"
and the assertion is at line 2211 only in the developer version. The text
you are referring to can be found in version 9.0.0.

Best,
Daniel


Am Sa., 12. Okt. 2019 um 08:06 Uhr schrieb Michał Wichrowski <
mtwichrow...@gmail.com>:

> Dear all,
> The documentation of Chebyshev precondition says that:
>
> "Note that if the degree variable is set to *zero*, the Chebyshev
> iteration corresponds to a Jacobi preconditioner"
>
> while actually setting degree to 0 triggers Assertion at line 2211 of
> precondition.h. Moreover, the PreconditionChebyshev works well with
> degree=0 in release mode, so I think removing assetion will resolve the
> problem.
>
> If Chebyshev preconditioner is not intended to be used with 0th degree
> this should be added to documentation (and documentation in current form is
> missleading)
>
> Best,
> MIchaĺ
>
> --
> 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/052f0208-e7b2-41aa-8876-c0df06ca4a92%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/CAOYDWbKQb%3Dj3UXci9B9-xY5GLm_LkbAGEZ_Lz85e8yu1WkirKA%40mail.gmail.com.


Re: [deal.II] Query regarding DoFTools::dof_indices_with_subdomain_association()

2019-10-09 Thread Daniel Arndt
Vachan,

[...]
>
However, the documentation of the former function states
>
> Note that this function is of questionable use for DoFHandler objects
>> built on parallel::distributed::Triangulation since in that case ownership
>> of individual degrees of freedom by MPI processes is controlled by the DoF
>> handler object, not based on some geometric algorithm in conjunction with
>> subdomain id. In particular, the degrees of freedom identified by the
>> functions in this namespace as associated with a subdomain are not the same
>> the DoFHandler class identifies as those it owns.
>
>
> What is the meaning of the second line? I suppose this has something to do
> with the FiniteElement type of the dof handler. Does this mean to say that
> irrespective of whether the FiniteElement has dofs on cell faces or not,
> this function approves a dof if it is geometrically residing on a face?
> This behaviour is actually what I want because although FE_DGQ element
> doesn't attach any dofs to cell faces, I want to get dof indices of the
> dofs (geometrically) lying on the face.
>

DoFTools::dof_indices_with_subdomain_association returns the degrees of
freedom of all the cells that have the given subdomain id. For
parallel::distributed::Triangulation objects the subdomain id is the the
MPI rank and this is the only valid input.
In this case, the function simply returns all the degrees of freedom on
locally owned cells. If a finite element defines degrees of freedoms that
are associated with a face, these degrees of freedom are part of all the
IndexSet objects in case the face is located on the interface between two
subdomains. For a parallel::distributed::Triangulation object, these are
the degrees of freedom on the faces to ghosted cells.

FE_DGQ doesn't define any face degrees of freedom. All its degrees of
freedom are defined to be inside of a cell. You could still ask for the
unit support points and figure out which of them are geometrically on a
given face.
However, note that as soon as gradients are involved all the degrees of
freedom contribute to values on faces.

Best,
Daniel

-- 
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/CAOYDWbLMDhoL4frLmb50yuLxOgoJnMMwmHh74Yp1uhkv%2B7Z_3Q%40mail.gmail.com.


Re: [deal.II] Implementing variable thermal diffusivity in Step-26

2019-10-07 Thread Daniel Arndt
Muhammad,

Dear Colleagues,
>I am working on thermal analysis where deal.ii
> Step-26 is being considered. In my case the thermal diffusivity
> (Coefficient being multiplied with Laplace Matrix) is temperature dependent
> and hence varying in every cell (or node). That is why I want to make the
> current Step-26 code flexible to cater this feature.
> I have two questions regarding this:
>
> *1) *Instead of directly creating the global Mass and Laplace matrices, I
> am making the cell_matrix as well as the cell_rhs as per following simple
> code (where to keep it simple, so far source term and diffusivity values
> are not yet present) :
> [...]
> The issue is that it is taking very long time to run 
> *VectorTools::point_value(dof_handler_temperature,
> old_solution_thermal, cell_temperature->vertex(j),
> temperature_old_solution_spatial_point); *function for evaluating the 
> *temperature_old_solution_spatial_point.
> *But the results match with the original Step-26 code.
> However as an efficient alternative, I tried to use the
> *temperature_old_solution_qpoint* in cell_rhs instead of
> *temperature_old_solution_spatial_point* which is very fast to compute
> but gives me the correct solution only at first time step after that the
> difference between this *new *and the *old solution* (from original
> Step-26 code) starts increasing i.e. new modified code solution kind of
> lags behind the original code (old) solution as per shared in the result
> snap shots in attachment.
>
> Any suggestion to improve the efficiency of current approach or any
> correction (in case I am mistaking or missing something) would be more than
> welcomed.
>

Yes, VectorTools::point_value is very slow because it searches in the whole
mesh each time it is called. Assuming that you use the same DoFHandler for
assembling the system_matrix and the old_solution_thermal, i.e.
dof_handler_temperature,
you should use FEValues::get_function_values()
https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#a357b422e374f2f2207af3512093f3907
instead. This function gives you the function values evaluated at every
quadrature point.
Currently, you are asking for the value at the vertices of the cell
instead. This can only possibly work if the number of vertices and the
number of degrees of freedom per cell coincide, i.e. for FE_Q(1) elements.
Using FEValues::get_function_values() you also don't need the loop with
running index j for assembling the right-hand side term.


> 2) Rather than making and assembling the local cell matrix and cell rhs,
> Is it more efficient and flexible way in deal.ii to directly modify the
> global Laplace matrix and system rhs in Step-26 for variable diffusivity
> coefficients at different corresponding dof entries?(Hopefully the
> dynamic sparsity pattern and preconditioning etc. might not disturb the
> indexing of dofs in this case)
>

No, just modify assembling the local matrix to take the coefficient into
account.

Best,
Daniel

-- 
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/CAOYDWb%2BjD9KGb116ggqYFYnNAm7OXhHK-h%3D%3DZ0fYCKxMCUN3QQ%40mail.gmail.com.


Re: [deal.II] Merging meshes and empty triangulation

2019-10-05 Thread Daniel Arndt
Erik,

Can you share your code and your mesh with us?

Best,
Daniel

Am Sa., 5. Okt. 2019 um 20:30 Uhr schrieb Erik Fujiyama <
erikfujiy...@gmail.com>:

> Hello, I think I'm having a similar problem to the OP. I searched a lot,
> but that's the closest that I could find. I'm trying to work with some
> meshes from gmsh, so I used the gridin functions to read them.
>
>   Triangulation triangulation;
>   GridIn gridin;
>   gridin.attach_triangulation(triangulation);
>   std::ifstream f("plate4");
>   gridin.read_msh(f);
>
> The mesh was generated with the physical lines and physical surfaces as
> mentioned in step 49.
>
> I even tested if it was actually reading by printing the number of active
> elements, and it is.
>
> However, when I'm going to distribute the dofs, it gives this message
>
> An error occurred in line <999> of file
>  in function
> void dealii::DoFHandler::distribute_dofs(const
> dealii::FiniteElement&) [with int dim = 2; int spacedim = 2]
> The violated condition was:
> tria->n_levels() > 0
> Additional information:
> The Triangulation you are using is empty!
>
>
> There's some problem that for some reason the information is lost in the
> next function when I call
>
>   dof_handler.distribute_dofs (fe);
>
> I double checked, and the DoF_handler is already associated with the
> triangulation
>
> fe (FE_Q(order), dim),
>   dof_handler (triangulation),
>
> It is specially confusing to me, because if I generate a grid with the
> grid generator, it works perfectly fine.
>
> Respectfully
> E.
>
> Em sábado, 31 de agosto de 2013 07:16:10 UTC-3, Wolfgang Bangerth escreveu:
>>
>>
>> > void CellProb::make_grid ()
>> > {
>> >   Triangulation<2> tria1;
>> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria1, 0.25, 1.0);
>> >
>> >  Triangulation<2> tria3;
>> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria3, 0.25, 1.0);
>> >GridTools::shift (Point<2>(0,-2), tria3);
>> >   Triangulation<2> triangulation2;
>> >   GridGenerator::merge_triangulations (tria1, tria3, triangulation2);
>> >
>> >   mesh_info(triangulation2, "grid-2.eps");
>> >   std::cout << "Number of active cells: "
>> >  << triangulation.n_active_cells()
>> >  << std::endl;
>> >  std::cout << "Total number of cells: "
>> >  << triangulation.n_cells()
>> >  << std::endl;
>> >
>> > }
>> > but I get the following report:
>> >  Remaking Makefile.dep
>> > ==debug= cell.cc  ->  cell.g.o
>> >  Linking cell
>> >  Running cell
>> > terminate called after throwing an instance of
>> > 'dealii::internal::Triangulation::ExcGridHasInvalidCell'
>> >what():  
>> > An error occurred in line <1672> of file
>> >  in
>> function
>> >  static void
>> >
>> dealii::internal::Triangulation::Implementation::create_triangulation(const
>> > std::vector,
>> > std::allocator>> &, const
>> > std::vector, std::allocator>>
>> &, const
>> > dealii::SubCellData &, dealii::Triangulation<2, spacedim> &) [with
>> spacedim = 2]
>> > The violated condition was:
>> >  needed_lines.find(std::make_pair(line_vertices.second,
>> > line_vertices.first)) == needed_lines.end()
>> > The name and call sequence of the exception was:
>> >  ExcGridHasInvalidCell(cell)
>> > Additional Information:
>> > Something went wrong when making cell 9. Read the docs and the source
>> code for
>> > more information.
>> > 
>>
>> I can reproduce this. Can you please open a bug report with the issue
>> tracker,
>> including your small testcase that shows the problem?
>>
>>
>> > My second question:
>> > I tried grid_2 (from tutorial 49) with the simple version of Poisson's
>> > equation and I get the following:
>> >  Remaking Makefile.dep
>> > ==debug= cell.cc  ->  cell.g.o
>> >  Linking cell
>> >  Running cell
>> > Mesh info:
>> >   dimension: 2
>> >   no. of cells: 224
>> >   boundary indicators: 0(88 times)
>> >   written to grid-2.eps
>> > Number of active cells: 224
>> > Total number of cells: 294
>> > 
>> > An error occurred in line <230> of file
>> >
>> 
>>
>> > in function
>> >  static unsigned int
>> >
>> dealii::internal::DoFHandler::Policy::Implementation::distribute_dofs(unsigned
>>
>> > int, unsigned int, dealii::DoFHandler &) [with dim = 2,
>> > spacedim = 2]
>> > The violated condition was:
>> >  tria.n_levels() > 0
>> > The name and call sequence of the exception was:
>> >  ExcMessage("Empty triangulation")
>> > Additional Information:
>> > Empty triangulation
>> > Stacktrace:
>> > ---
>> > #0  /usr/local_rwth/sw/deal.II/deal.II-7.3.0/lib/libdeal_II.g.so.7.3.0:
>> > unsigned int
>> >
>> 

Re: [deal.II] Error during refinement of a parallel distibuted quarter hyperball

2019-10-05 Thread Daniel Arndt
Stefan,

I am getting

Abort: Expected '(int) edge_trees - (int) ta->elem_count':
'p8est_find_edge_transform_internal (conn, itree, iedge, ei,
conn->edge_to_tree + ettae, conn->edge_to_edge + ettae, edge_trees)'
Abort: /home/darndt/Sources/p4est-2.2/src/p8est_connectivity.c:
Abort
[lap115343:18334] *** Process received signal ***
[lap115343:18334] Signal: Aborted (6)
[lap115343:18334] Signal code:  (-6)
[lap115343:18334] [ 0]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7ff7d31b2f20]
[lap115343:18334] [ 1]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7ff7d31b2e97]
[lap115343:18334] [ 2]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7ff7d31b4801]
[lap115343:18334] [ 3] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort_verbose+0x0)[0x7ff7da6a1070]
[lap115343:18334] [ 4] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort+0xd)[0x7ff7da6a0e5b]
[lap115343:18334] [ 5] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort_verbosef+0x0)[0x7ff7da6a1104]
[lap115343:18334] [ 6] /home/darndt/p4est-2.2/DEBUG/lib/libp4est-2.2.so
(p8est_find_edge_transform+0x1f4)[0x7ff7da9604b9]
[lap115343:18334] [ 7] /home/darndt/p4est-2.2/DEBUG/lib/libp4est-2.2.so
(p8est_connectivity_is_valid+0x6a0)[0x7ff7da9547ed]
[lap115343:18334] [ 8]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii8parallel11distributed13TriangulationILi3ELi3EE31copy_new_triangulation_to_p4estESt17integral_constantIiLi3EE+0x3db)[0x7ff7e57cf53b]
[lap115343:18334] [ 9]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii8parallel11distributed13TriangulationILi3ELi3EE20create_triangulationERKSt6vectorINS_5PointILi3EdEESaIS6_EERKS4_INS_8CellDataILi3EEESaISC_EERKNS_11SubCellDataE+0x27)[0x7ff7e57edad7]
[lap115343:18334] [10]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii13GridGenerator18quarter_hyper_ballILi3EEEvRNS_13TriangulationIXT_EXT_EEERKNS_5PointIXT_EdEEd+0x647)[0x7ff7e4e20f47]
[lap115343:18334] [11] ./mwe(main+0x6c)[0x406ecc]
[lap115343:18334] [12]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7ff7d3195b97]
[lap115343:18334] [13] ./mwe(_start+0x2a)[0x406d9a]
[lap115343:18334] *** End of error message ***

when running your code. This might be related to
https://github.com/dealii/dealii/issues/7428. Would you mind opening an
issue for this at https://github.com/dealii/dealii/issues?

Best,
Daniel

Am Fr., 4. Okt. 2019 um 13:12 Uhr schrieb Stefan Käßmair <
stefan.kaessm...@gmail.com>:

> Dear all,
>
> during the refinement of a quarter hyper ball in 3D in debug mode, I
> receive the following error when running on a single core (mpirun -np 1):
>
>
>
>
> *An error occurred in line <2764> of file
>  in functionvoid
> dealii::parallel::distributed::Triangulation spacedim>::copy_local_forest_to_triangulation() [with int dim = 3; int
> spacedim = 3]The violated condition was: static_cast int>(parallel_forest->local_num_quadrants) == total_local_cells*
>
> When running on multiple cores I hit another error message (probably
> because there are no ghosts when using only one core):
>
>
>
>
> *An error occurred in line <2670> of file
>  in functionvoid
> dealii::parallel::distributed::Triangulation spacedim>::copy_local_forest_to_triangulation() [with int dim = 3; int
> spacedim = 3]The violated condition was: num_ghosts ==
> parallel_ghost->ghosts.elem_cou*nt
>
> Currently I am using deal.II 9.0.1.
> This is the relevant part of the code (a full MWE is attached):
>
> const unsigned int dim = 3;
>
> parallel::distributed::Triangulation tria (
>   mpi_communicator,
>   typename
> Triangulation::MeshSmoothing(Triangulation::smoothing_on_refinement),
>
> parallel::distributed::Triangulation::default_setting);
>
> GridGenerator::quarter_hyper_ball(tria);
>
> for (unsigned int i_refinement = 0; i_refinement < 6;
> ++i_refinement)
> {
> auto cell = tria.begin_active();
> auto endc = tria.end();
>
> for (; cell!=endc; ++cell)
> if(cell->is_locally_owned() && cell->at_boundary())
> cell->set_refine_flag ();
>
> tria.prepare_coarsening_and_refinement ();
> tria.execute_coarsening_and_refinement ();
> }
>
> Is there something wrong with my code? Or maybe with my installation (can
> anyone confirm the error)?
> The code works in 2D but crashes in 3D. When the number of refinement
> cycles is reduced to 4 instead of 6, it also works.
> Out of curiosity, I've tried using GridGenerator::hyper_cube instead of
> the hyper_ball, there the code works just fine in 2D and 3D.
>
> I would really appreciate if anyone can help me with this.
>
> Kind regards,
> Stefan
>
> --
> 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 

Re: [deal.II] Re: Installation error, unable to configure with p4est

2019-10-05 Thread Daniel Arndt
Vachan,

[...]
> However,
> make test
> for p4est failed with the following message
> There are not enough slots available in the system to satisfy the 10 slots
> that were requested by the application:
>   ./p4est.debug
>
> Either request fewer slots for your application, or make more slots
> available
> for use.
> It is true that my PC has only 4 slots (8 with hyper threading). So can I
> ignore this error?
>

Yes, you can likely ignore the error. If you really want to run this
quicktest, you can change
make_quicktest("p4est" ${_mybuild} 10)
to
make_quicktest("p4est" ${_mybuild} 4)
in tests/quick_tests/CMakeLists.txt.

Best,
Daniel

-- 
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/CAOYDWbKQ%3DEJNnHEH8jg_bU9TWLR%3DPU2kJo5CsmJN9G%3DDRj%2BQVg%40mail.gmail.com.


Re: [deal.II] Re: Move vertices in P::D::Triangulation

2019-10-05 Thread Daniel Arndt
huyanzhou,

in the documentation , it's said in the case of mesh with moved vertices is
> refined a few step later, should do as follows:
> 1. save the offset applied to every vertex,
> 2. call communicate_locally_moved_vertices function
> 3. apply the opposite offset
> 4. call communicate_local refining or coarsening the meshly_moved_vertices
> function
> 5.  refining or coarsening the mesh
>
> i don't quite understand the 5 step.
> 1. what's the meaning of offset here? is it the move vector for every
> vectices in this step, or the whole move vector which will make the mesh
> return to original mesh?
>

The offset is the total move vector that will make the mesh return to its
original state. Only the mesh without any displacements has valid positions
for all the cells (including artificial ones).

2. we add the opposite offset , does this means we need apply the offset
> again after  refining or coarsening ?
>

Yes. The offset vector should be transferred to the new mesh via
SolutionTransfer. Then you can apply it again.

An alternative to moving the vertices is using MappingFEField or
MappingQEulerian.

Best,
Daniel

-- 
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/CAOYDWbKVHdywuJOfhCKjHP3Tib8%3DX-tdgvCxt-75Q5UX0psXsQ%40mail.gmail.com.


Re: [deal.II] some question about the move mesh function

2019-10-05 Thread Daniel Arndt
huyanzhou,

I try to use the communicate_locally_moved_vertices, it fixes the departure
> of mesh belongs to different mesh . but there still remains some problem
>
[...]
> you can see that the mesh is consistent on the boundry, but not smooth in
> the inner mesh ,there are some shallow hole  on the surface
>
Can you explain more precisely what doesn't work as expected? Is this a
problem you only see when running with multiple MPI processes?
What is the "inner mesh" for you? Do you refer to faces with children? Can
you point out which vertices you think are set wrongly?


> my code is as follows
>
[...]
>

It seems that your idea is to first move vertices according to some
displacement function and then to "correct" hanging vertices to be placed
inside the neighboring face.
That looks OK for standard orientation but might be problematic otherwise.
You should be able to achieve the same effect when you only apply hanging
node constraints to your
displacement vector.

Best,
Daniel

-- 
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/CAOYDWbJA%2BTTTMhPrFg6pomh9KS1rF85mbuHa-9GK%2B%3Dkpr8hOew%40mail.gmail.com.


Re: [deal.II] installation fails with intel/19.0.5

2019-09-30 Thread Daniel Arndt
Victor,


But I’m still not finishing the cmake.
>
> So there is a ton of
> ...
> What do those mean? Are they fatal or is that only cmake discovering
> what’s available and what not?
>

No, these are not fatal. We just check for the dependencies to enable.
Again, what is the full output when running CMake? Does it create a
Makefile you can run via 'make'?

Best,
Daniel

-- 
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/CAOYDWbJdQ8%2BEbCREUCJ8VXgCoZP3qYatkvg%3DQ%2BT5PU%3DufwYufg%40mail.gmail.com.


Re: [deal.II] installation fails with intel/19.0.5

2019-09-27 Thread Daniel Arndt
Victor,

does running CMake or can't you compile after configuring? I don't
immediately see anything suspicious in CMakeError.log.
What is the output when running when `cmake` or, if the former works, what
is the output when trying to compile?

Best,
Daniel

Am Fr., 27. Sept. 2019 um 16:31 Uhr schrieb Victor Eijkhout <
eijkh...@tacc.utexas.edu>:

> CMakeError.log attached.
>
> --
> 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/e282fbb9-cde8-4a83-b1c7-ca7727f19dc3%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/CAOYDWbJ3PeAuHKMOJ%2BM8HVz-Mh19bp_icPzUE%3DtaSS9_PV%3DUNQ%40mail.gmail.com.


Re: [deal.II] Problem warning in eclipse: invalid argument for the distance function

2019-09-17 Thread Daniel Arndt
Brian,

The warnings you are seeing come from a static analyzer in Eclipse and not
from the compiler. It seems like Eclipse does not have full access to the
source code
or doesn't understand it correctly. E.g., passing a non-const variable to a
function that doesn't modify its parameter, is never a problem.

It is certainly helpful to have a look if these warnings are sensible or
not. In this case, I would ignore them though. On the other hand, I would
listen to compiler warnings.

Best,
Daniel

-- 
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/CAOYDWbL5qjn6baPKRPBicfW36XGq-z7AL_%3DqCScNpzVkF6k8iQ%40mail.gmail.com.


Re: [deal.II] step 64 run problem

2019-09-06 Thread Daniel Arndt
Jinhyun,

I cannot reproduce that problem using nvcc-9.0 and deal.II 9.1.1. What
version are you using? Does the code work if you remove that assertion in
the library?

Best,
Daniel

Am Fr., 6. Sept. 2019 um 01:52 Uhr schrieb Jinhyun Choo <
jinhyun.c...@gmail.com>:

> Hello,
>
> I've just complied deal.ii with CUDA and tried to run Step 64.
> Unfortunately, however, I got an error as soon as I ran it. I wonder what
> would be reason(s) for this error: is it due to CUDA? Thank you in advance.
>
> Best,
> Jinhyun
>
>
> --
> 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/3b2bfe7c-05d4-4c4b-bdbd-a5f1dd9a5a7c%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/CAOYDWbLsfONq_k%3DazK2dS24eEaBX6HgbumN%3DddsRpSJ9SpF7-A%40mail.gmail.com.


Re: [deal.II] Getting RHS values at nodes with DBC

2019-09-03 Thread Daniel Arndt
Giorgos,

You can find a discussion for how constraints are handled in deal.II in
https://www.dealii.org/developer/doxygen/deal.II/group__constraints.html.

Thank you for your feedback.
> I'll try to explain what I try to calculate with the help of a standard
> FEM textbook:
>
> [...]
>
> In the book the global system is partitioned so that the first row
> contains the known U1 dofs and the second row the unknown the dofs U2.
> They solve the system for the U2 and then they calculate F1.
>

In short: we normally don't condense the linear system but use a diagonal
matrix for the constrained rows instead (and modify the right-hand side
accordingly).


> I think that the F1 vector  contains, among others, the fluxes from the
> imposed BCs.
>
In case you only have Dirichlet boundary conditions, K11 is diagonal, K12
is zero and F1 contains the (possibly scaled) Dirichlet boundary values.

Could you clarify in mathematical terms what you mean by "fluxes"? Maybe,
we are just using different terms fo the same thing.

In case you are interested in n\cdot In u at the boundary, you can use
FEValues::get_function_gradients() and FEValues::get_normal_vectors() with
a quadrature formel that contains
the points you are interested in on a cell in reference coordinates. This
is the approach VectorTools::point_gradient() is using for returning the
gradient for a single point in real coordinates.

Best,
Daniel

-- 
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/CAOYDWb%2B0Vj_LTboMTc2Rqo0%2BMLc7VQpNK0QfZFgeqabk_f7qbg%40mail.gmail.com.


Re: [deal.II] Solving a TrilinosWrappers::BlockSparseMatrix using Trilinos iterative solver (step-57)

2019-08-29 Thread Daniel Arndt
Bruno,

I am currently trying to work on a "HPC-ready with Trilinos" version of
> step-57 for steady-state solution of the Navier-Stokes equation since I am
> curious about compairing it to our stabilized solver. I think that it
> could give much better results for steady-state.
> The approach detailed in step-57  uses Block matrices instead of regular
> matrices since it preconditions the pressure block differently than the
> momentum block.
> From my understanding, this requires eventually the solution of a
> BlockSparseMatrix. However, looking at the documentation for
> TrilinosWrappers::SolverBase, I see that there are no call to solve that
> can take as an argument a BlockSparseMatrix, they all take a regular
> matrix. Consequently, I am not sure how I should proceed. Is this something
> that is lacking in current implementation or there is a work around that I
> am unaware of?
>
> What I am trying to do initially is to port step-57 (
> https://www.dealii.org/current/doxygen/deal.II/step_57.html) to use
> Trilinos for the linear algebra. Consequently, what would be changing from
> step-57 is mostly related to changes in the BlockSchurPreconditioner class
> of step-57. Hope that is clear :).
>

You can just use the deal.II solvers instead. Have a look, e.g., at step-32.

Best,
Daniel

-- 
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/CAOYDWbJjsh_5cWYg6i3qBzaMVb71KxNrKpsergzSeMj8eHJZYg%40mail.gmail.com.


Re: [deal.II] Implement 'w.n = u.n' as a boundary condition, where 'u' is a vector valued FE function/solution from a phase/PDE and 'n' is the unit outward normal in a distributed setting

2019-08-29 Thread Daniel Arndt
Bhanu,

I have looked at 'VectorTools::compute_nonzero_normal_flux_constraints'.
> But what I have here to compute the 'inhomogeneity' is not a closed form
> function, but a discrete FE solution computed from another PDE(in my case
> Stokes). The 'u' in 'w.n = u.n' is a 'LA::MPI::Vector' FE solution vector.
> Can you please suggest?
>

But the code you need is really similar in the end, see
https://github.com/dealii/dealii/blob/master/include/deal.II/numerics/vector_tools.templates.h#L6976
for the implementation. You would only have to replace using function_map
by evaluating your finite element vector on a given cell.
The code you are proposing in your first message looks reasonable on first
sight, but is restricted to FE_Q(1) elements and always constraining the
first component doesn't look sensible. I would rather go for the component
for which the normal is largest.
Of course, you need to be careful when averaging the constraints at cell
boundaries. This is included in the implementation of
VectorTools::compute_nonzero_normal_flux again. In particular, look at the
DoFToNormalsMap object.

Best,
Daniel

-- 
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/CAOYDWbKrFwNJhUGB1ss72snZcvjmTnAPLiA17Wk4%3D1EiXoX%2B1g%40mail.gmail.com.


[deal.II] Re: triangulation.add_periodicity takes an enormous amount of time

2019-08-28 Thread Daniel Arndt
Andreas,

I am trying to read from a mesh file and impose periodic boundary 
> condition. This works out very well for small geometries in three spatial 
> dimensions. However, if the read meshes tend to have more elements, the 
> amount of time needed to create the mesh rises drastically. The time is 
> spent within the routine triangulation.add_periodicity. Thus, I have 
> created a minimal code example where cubes of side lengths 5, 20, and 50 
> are created. For each cube, the periodic face pairs are identified and 
> collected. Afterwards, triangulation.add_periodicity is executed and the 
> needed time is measured using the Timer class. The output of the attached 
> code example looks as follows:
>
> Starting Constructor with side length = 5
> Periodic faces collected: Size of periodicity_vector = 75
> Start triangulation.add_periodicity(periodicity_vector); after 0.018097 
> seconds
>  Done triangulation.add_periodicity(periodicity_vector); after 3.0626 
> seconds
>
> Starting Constructor with side length = 20
> Periodic faces collected: Size of periodicity_vector = 1200
> Start triangulation.add_periodicity(periodicity_vector); after 2.10931 
> seconds
>  Done triangulation.add_periodicity(periodicity_vector); after 15749 
> seconds
>
> Starting Constructor with side length = 50
> Periodic faces collected: Size of periodicity_vector = 7500
> Start triangulation.add_periodicity(periodicity_vector); after 298.734 
> seconds
>

Were you running in Debug or Release mode? I only tried Release mode and 
the timings weren't that terrible. I observed a runtime like three times 
larger in that function than for creating the mesh for up to 100 elements 
per side.
Still, there are some oppurtunities for improvement, see 
https://github.com/dealii/dealii/pull/8665. With these changes, creating 
the mesh and adding periodicity takes roughly about the same time.

Apart from that, it is much better to have a coarse mesh with few cells and 
refine a few times than starting with a rather fine coarse mesh (if you can 
do that).

Best,
Daniel

-- 
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/2982487e-6e33-4f49-b4e2-a4cc93229d61%40googlegroups.com.


Re: [deal.II] Implement 'w.n = u.n' as a boundary condition, where 'u' is a vector valued FE function/solution from a phase/PDE and 'n' is the unit outward normal in a distributed setting

2019-08-28 Thread Daniel Arndt
Bhanu,

Please suggest me in implementing 'w.n = u.n' as a boundary condition where
> 'u' is Stokes solution with 'FESystem fe_stokes(FE_Q(degree+1),
> dim, FE_Q(degree), 1)' and 'w' for mesh velocity with 'FESystem
> fe_move(FE_Q(degree), dim)'. As I have taken 'degree=1', 'fe_move' has
> unit support only at geometric vertices. I want to know if there is a
> direct way to get outward unit normal at a boundary vertex which is average
> of normals of faces that share this vertex(The faces are flat as I have not
> assigned any MapingQ). If this is not possible/straight_forward, the
> normal at a quadrature point on the face from which I visit this vertex the
> first time is good enough.
> [...]
>

Have a look at VectorTools::compute_nonzero_normal_flux_constraints (
https://www.dealii.org/current/doxygen/deal.II/group__constraints.html#gacb97b6eb5113d649d4daee0867dc82ac
).

Best,
Daniel

-- 
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/CAOYDWbK212WjrKR3dL%3Dq-LSP_FjTYt%3DQ9RmJkfPVRqGfykSRFA%40mail.gmail.com.


Re: [deal.II] How to set material id with MPI

2019-08-23 Thread Daniel Arndt
KIen,

Hi colleagues,
> I have a question for parallel::distributed::Triangulation
> When 2 cells share 1 edge, but they are living in 2 different MPI
> processes, how can I choose only 1 cell containing the common edge from
> them.
> I think I have to set material id for the cell in the first process, and
> then tell the other one do not set it.
> However, I don't know how to send the cell iterator in MPI communication.
>

Just set the material id on both processes. That is much simpler and likely
faster.

Best,
Daniel

-- 
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/CAOYDWbL_JMF7VsRp-AiQraqth8X7MXjTim807LEtfC%3Dyiicp_A%40mail.gmail.com.


Re: [deal.II] getting components of Blockvector

2019-08-22 Thread Daniel Arndt
Gabriel,

[...]
> u_x.reinit(n_dofs_in_one_direction);
> *FEValues fe_values(fe,
> quadrature_formula, update_values);*
> *std::vector>  velocity_values(n_q_points);*
> *const FEValuesExtractors::Vector   velocities(0);*
>
> *for (const auto  : dof_handler.active_cell_iterators())*
> * {*
> *  fe_values.reinit(cell);*
> *  fe_values[velocities].get_function_values(solution,
> velocity_values);*
>
> *[...]*
>
> *}*
>
> With this procedure I get the vector of Tensors velocity_values, which
> contains the velocity-values of "solution" in every direction at the
> quadratue points. So now I an easily get the values of velocity_values in
> the x-direction at the quadrature points. But how do I get the values of
> u_x at the dofs?
>
> Does somebody have an idea how to fix this, or a better way to do handle
> this?
>

You can use
fe.system_to_component_index(i).first;
to obtain the component of the local degree with number i, see
https://www.dealii.org/current/doxygen/deal.II/step_8.html#ElasticProblemassemble_system
.

Best,
Daniel

-- 
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/CAOYDWbJBw8LSCkjPtcQCJWgA89bdkpekUhD1CA1%2Bm4HxQZHr4Q%40mail.gmail.com.


Re: [deal.II] Distributing objects on cluster nodes according to distributed triangulation (MPI)

2019-08-22 Thread Daniel Arndt
Konrad,

I have a little conceptual question. Maybe it is dumb but I am new to MPI...
>
> Say I have a triangulation of type
> *parallel::distributed::Triangulation* that gets distributed over N
> nodes on a cluster. Each active cell should own (or point to) an object
> that makes up a (modified non-polynomial) finite element basis. That means
> the object is not so simple in that it contains objects itself (e.g., a
> triangulation, several vectors etc).
>
> How can I distribute a set of these basis objects (after creating the
> distributed triangulation) so that each active cell and its corresponding
> basis object are on the same cluster node?
>
> Is there something like a distributed STL-like container whose elements I
> can initialize on different cluster nodes (for example by querying
> *cell->is_locally_owned()*) when looping over the triangulation?
>

You could create an std::map using CellId (
https://www.dealii.org/developer/doxygen/deal.II/classCellId.html) as key
if you need to identify cells uniquely globally.

Best,
Daniel

-- 
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/CAOYDWb%2Bh5%3D86AX%3DV45piGy1nMCCxA4d8erBaPshHUjW6JZsBPw%40mail.gmail.com.


[deal.II] Re: Question about constraints

2019-08-21 Thread Daniel Arndt
Yuesu,

  I am learning step-7 which has the same class AffineConstraints class, in 
> step6, we use the member function ::distribute_local_to_global to put the 
> local matrix and rhs into global matrix and rhs, but in step-7, we still 
> use system_matrix.add and then use the constraint.condense on system_matrix 
> and system_rhs. Do those two procedure have the same effect? 
>

You can find a discussion at 
https://www.dealii.org/9.0.1/doxygen/deal.II/group__constraints.html. In 
short: Yes, they have the same purpose, but different advantages and 
disadvantages. In general, we recommend using distribute_local_to_global 
over condensation.

Best,
Daniel

-- 
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/a9e938ad-06b6-49e1-9e99-91bafd4e8fc4%40googlegroups.com.


Re: [deal.II] MGTransferBlockMatrixFree< dim, Number > ::clear rrmoves number of blocks

2019-08-12 Thread Daniel Arndt
Michal,

[...]
> Moreover the default contructor (without parameters) does not work (error
> in compilation - deleted function). Using it could be useful for DG.  I
> would suggest:
> 1) adding constuctor with number of blocks
> 2) adding function that sets number of blocks
>

So you want to a separate function that calls the current interface with
default constructed MGConstraindedDoFs objects?
We are happy to have a look and discuss if you create a pull request for
this.

Thanks, for reporting the problem with the default constructor. I will have
a look.

Best,
Daniel

-- 
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/CAOYDWbKVYqR79dbdW-tbgi1kR3C6Enbp0GshdJA2ju8oJJwvTw%40mail.gmail.com.


Re: [deal.II] undefined symbol: mkl_blas_dsyrk

2019-08-11 Thread Daniel Arndt
Yuesu,

Hello Daniel,
>   Thank you very much! I make a new folder to save the compile file for 
> cmake, and I used the command
> *cmake -DCMAKE_INSTALL_PREFIX=${HOME}**/deal.II 
> home/yjin6/Deal.II/dealii-9.0.1* (substituted with my directory),
> but cmake gave error warning. I substitute it with 
> *cmake -DCMAKE_INSTALL_PREFIX=/**path/to/install/dir 
> home/yjin6/Deal.II/dealii-9.0.1*
> Cmake gives the message that:
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/yjin6/Deal.II/dealii
>

This implies that /home/yjin6/Deal.II/dealii is your build directory not 
your installation directory.

cmake -DCMAKE_INSTALL_PREFIX=/home/yjin6/deal.II 
/home/yjin6/Deal.II/dealii-9.0.1

would result in the installation directory to be /home/yjin6/deal.II and 
the build directory to be /home/yjin6/Deal.II/dealii-9.0.1

Best,
Daniel

-- 
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/ce88e2ea-8a86-4926-ab85-7760382bff04%40googlegroups.com.


Re: [deal.II] undefined symbol: mkl_blas_dsyrk

2019-08-11 Thread Daniel Arndt


> Thank you for your timely reply!
>  I changed the installation direction according to the README document and 
> redirected it to the deal.ii-9.0.1 source code. 
>
 
It seems that you still set the installation directory to a non-existent 
path. If you want to install in your home directory calling

cmake -DCMAKE_INSTALL_PREFIX=${HOME}/deal.II DEAL_II_SOURCE_DIR 


in your build directory should work (you need to replace DEAL_II_SOURCE_DIR 
with the actual path to the deal.II source directory).

Best,
Daniel

-- 
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/fa4a34b5-70c9-4a8a-accb-dfc96cab1e53%40googlegroups.com.


Re: [deal.II] petsc & trilinos blocksparsematrix reinit with zero locally owned components

2019-07-30 Thread Daniel Arndt
Richard,

[...]
> The very last part (reinit) is working only iff every processor owns parts
> of fluid AND solid domain (which is so far not ensured).
> This behaviour can be seen running exactly the same problem with mpirun -n
> 2 or -n 3, which is attached.
>
> THE QUESTION IS NOW:
> How may one reinit the blocks in a BlockSparseMatrix, if not every
> subdomain has locally_owned_dofs in all blocks?
> Or what is the point I am missing here?
>
> I added a chunk of code at the end, that shows, that the
> block(block_row,block_col).reinit(...) fails, if the locally_owned indexset
> is empty.
>

This assertion was removed in https://github.com/dealii/dealii/pull/6106.
Either use a recent release or simply remove it in your copy of the deal.II
source files.

Best,
Daniel

-- 
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/CAOYDWbJhT0hB%3DT0r8qBXZ5QAp4%3DqpYugwRZzwaAhTZF7F3S1pg%40mail.gmail.com.


Re: [deal.II] Error on runnig the examples

2019-07-29 Thread Daniel Arndt
Javad,

I installed Dealii-9.1.1 successfully. So, I wanted to run step-1 and
> followed the command lines based on README instruction. But, I have faced
> an error that you can see as follow:
>
> root@Lenovo-PC:~/math/dealii-9.1.1/examples/step-1# cmake
> -DDEAL_II_DIR=/root/bin/dealii-9.1.1/ .
> [...]
> root@Lenovo-PC:~/math/dealii-9.1.1/examples/step-1# make
> Scanning dependencies of target step-1
> [ 50%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
> make[2]: *** No rule to make target
> '/root/math/dealii-9.1.1/lib/libdeal_II.g.so.9.1.1', needed by 'step-1'.
> Stop.
> [...]
>

It looks like /root/math/dealii-9.1.1/lib/libdeal_II.g.so.9.1.1 is not
accessible. Does this file exist? Is it readable?
Anyway, you should just install deal.II anew and make sure that the file
exists in the installation directory.

Best,
Daniel

-- 
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/CAOYDWbLyykSzZ7bPx09ZJMxPNOuu0spQXFwwz_zW7rFegBwW3Q%40mail.gmail.com.


Re: [deal.II] Access old solution(s) in MatrixFreeOperators::Base::apply_add()

2019-07-26 Thread Daniel Arndt
Maxi,

[...] I tried adding a class member and initializing it during
> setup_system(), but when accessing it via read_dof_values(), I had a layout
> mismatch, resulting in
> The violated condition was:
> vec.partitioners_are_compatible(*dof_info.vector_partitioner)
> Additional information:
> The parallel layout of the given vector is not compatible with the
> parallel partitioning in MatrixFree. Use MatrixFree::initialize_dof_vector
> to get a compatible vector.
>
> Did you initialize its layout via MatrixFree::initialize_dof_vector() 
in fact?

Best,
Daniel

-- 
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/CAOYDWb%2BK9Paz74CyGRrfQrR_c%3DxCBSa%2B6Nn4wVfS2pdaSc_dLA%40mail.gmail.com.


Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

2019-07-26 Thread Daniel Arndt

Franco,

If you forget about the static_cast in the error message just above 
>> you can actually see what happens: 
>> The violated condition was: 
>> global_matrix.m() == global_vector.size() 
>>
>>
>
> I am lost in this, I have made some stupid error here but I don't see how. 
> I am posting the code here:
>
>  https://gist.github.com/fmilicchio/2dac430d7c071f98b4f66d79d2101b04
>
> As far as I can tell, I've initialized every sparsity pattern, matrix, and 
> vector as they were with Trilinos, but I am surely seeing the code I 
> intended to write, not the code I have actually written.
>

You are not initializing the stokes vectors appropriately. Running in a 
debugger should have told you that there was a problem with the size of 
stokes_rhs. In fact, 

stokes_solution.reinit(n_u+n_p)

creates a vector with n_u+n_p empty blocks. You want to do something like

std::vector block_sizes(2);
block_sizes[0] = n_u;
block_sizes[1] = n_p;
stokes_solution.reinit(block_sizes);

instead. Then, you also need to have a look how to initialize the sparsity 
pattern for the stokes_preconditioner correctly (if you want to use that 
matrix at all).

Best,
Daniel

-- 
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/de31075a-c077-4ca5-b95e-84c0b5dfebd3%40googlegroups.com.


Re: [deal.II] Different solution with different software

2019-07-25 Thread Daniel Arndt
Felix,

Jean-Paul's answer might already have solved your problem. Anyway:

I'm not sure to understand how to manufacture a solution for my problem. I
> have read step 7 a few times and I understand but for a coupled system like
> mine, I don't see how to do it.
> Should I choose a solution with u and v that already respect the
> icompressibility equation ?
>
Yes.

Should I keep the same phi or change it for another one ?
>
If you want to see that you represent the solution exactly, you might want
to adapt the polynomial degree of your ansatz space to match the one of phi.


> Should I keep the same boundary conditions (everything = 0) on the sides ?
>
Yes.

Best,
Daniel

-- 
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/CAOYDWbLBA_SUwQ0cLVT7%2Bf%2BuMduFVF_E4GsCKoAp%2BxxUE4vy0w%40mail.gmail.com.


Re: [deal.II] VMult-function in the MatrixFree-Framework

2019-07-24 Thread Daniel Arndt

>
> Is there then a way to use LinearOperator as Input for a preconditioner? 
> Else I still have to form the full system matrix (which I would like to 
> avoid).
>

Most precoditioners require access to individual matrx entries. If the 
class you derive from linear operator provides a suitable interface, you 
can use it in a preconditioner.
Building suitable preconditioners compatible with matrix-free methods is 
non-trivial. The default choice would be PreconditionChebyshev.

Best,
Daniel

-- 
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/0d388f81-f924-4d58-b0f2-5225dfc81327%40googlegroups.com.


Re: [deal.II] VMult-function in the MatrixFree-Framework

2019-07-24 Thread Daniel Arndt

>
> On the other hand, would it be sufficient to unroll the 
>>> residual-calculation, i.e. if the residual is F(u) = nabla^2 u + f, to 
>>> write (in the cell-loop): (nabla^2(u + eps*src) + f - nabla^2u - 
>>> f)/epsilon? Or would that lead to wrong results?
>>>
>>  
>> It is sufficient to only change compute_diagonal() to use the MatrixFree 
>> framework. Passing multiple vectors at once might be a little bit more 
>> difficult to implement.
>>
> Could you elaborate on that further (changing the diagonal value)?  
>

Oh, that was a typo. I meant that you only have to implement 
calculate_residual and can leave the rest of you LinearOperator as is.

Best,
Daniel

-- 
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/3cb726f0-edbe-4557-bf3d-d929c0038ca5%40googlegroups.com.


Re: [deal.II] VMult-function in the MatrixFree-Framework

2019-07-23 Thread Daniel Arndt
Maxi,

No, that code is the vmult-call I am using in my LinearOperator (and is
> used directly in my solve()-call). The calculate_residual()-function is
> similar to the function in step-15, with the difference, that I do not
> provide alpha, but the vector, and return the calculated residual value.
>

So this is where your cell loop currently lives and that can be represented
by a matrix-vector product. :-)


> Thus, as far as I could understand, I have to do the following in the
> matrix-free cell loop:
>
>- Calculate residual of the current solution
>- Calculate residual of the current solution + epsilon * src
>- Calculate dst, and return it
>
> On the other hand, would it be sufficient to unroll the
> residual-calculation, i.e. if the residual is F(u) = nabla^2 u + f, to
> write (in the cell-loop): (nabla^2(u + eps*src) + f - nabla^2u -
> f)/epsilon? Or would that lead to wrong results?
>

It is sufficient to only change compute_diagonal() to use the MatrixFree
framework. Passing multiple vectors at once might be a little bit more
difficult to implement.

Currently, you residual seems to depend linearly on u. In that case, the
difference does not depend on u at all.

Best,
Daniel

-- 
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/CAOYDWb%2BCH%2BNRgR2_ni%2Bxm%3DE60JP-L255ie7etKCzKMhXH0qvBw%40mail.gmail.com.


Re: [deal.II] Step-40 fails with "PETSc preconditioner should have anassociated matrix set to be used in solver"

2019-07-23 Thread Daniel Arndt
Pandey,


>
> [...]
> 
> An error occurred in line <88> of file
>  in
> function
> void dealii::PETScWrappers::SolverBase::solve(const
> dealii::PETScWrappers::MatrixBase&, dealii::PETScWrappers::VectorBase&,
> const dealii::PETScWrappers::VectorBase&, const
> dealii::PETScWrappers::PreconditionerBase&)
> The violated condition was:
> B != nullptr
> Additional information:
> *PETSc preconditioner should have anassociated matrix set to be used
> in solver.*
> 
>

This error message is really unexpected if you are running a non-modified
version of step-40. Did you change anything?
It seems that you are running in Release mode. Do you see the same error
message in Debug mode as well or would the code stop
to run earlier?

Best,
Daniel

-- 
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/CAOYDWb%2Bw13VuxNk%3DPPsUuyO0KzeP3RAU2HsU-Rgbo0qoE%2BeSiA%40mail.gmail.com.


Re: [deal.II] VMult-function in the MatrixFree-Framework

2019-07-23 Thread Daniel Arndt
> My aim is to implement the jacobian approximation, i.e. (if F(u) = 0 is
> the function to solve) I wanted to implement
> dst = (F(current_solution + epsilon * src) - F(current_solution))/epsilon.
> In my LinearOperator, my code is
> LinearOperator jacobian_operator;
> jacobian_operator.vmult = [&](LinearAlgebraTrilinos::MPI::Vector ,
> const LinearAlgebraTrilinos::MPI::Vector ){
> local_src = src;
> extended_src = src;
> local_solution = present_solution;
>
> double epsilon = 1e-6;
> if(local_src.l2_norm() != 0){
> epsilon = sqrt((1 + local_solution.l2_norm()) * 1e-16) / local_src
> .l2_norm();
> };
> forward_eps_solution = present_solution;
> backward_eps_solution = present_solution;
>
> extended_src *= epsilon;
> forward_eps_solution += extended_src;
> backward_eps_solution -= extended_src;
>
> compute_residual(backward_eps_solution, cur_residual);
> compute_residual(forward_eps_solution, eps_residual);
> eps_residual -= cur_residual;
> eps_residual /= (2 * epsilon);
> dst.reinit(locally_owned_dofs,
>mpi_communicator);
> dst = eps_residual;
> };
>
> Is the same/similar possible for the matrix-free-approach?
>
Sure, you can always write a wrapper around the actual vmult call (which I
assume is happening in compute_residual()).

Best,
Daniel

-- 
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/CAOYDWbJARv-ibt7EJjk9t3fVgHv3BQi1LNALPc9_m2hSwEAgBg%40mail.gmail.com.


Re: [deal.II] VMult-function in the MatrixFree-Framework

2019-07-23 Thread Daniel Arndt
>
>- When using the LinearOperator, the function vmult() is used when
>solving the system with a GMRES-solver (or similar). Does the same hold up
>for the MatrixFree-framework?
>
> Yes.

>
>- If the above is correct: In each GMRES-iteration I have to calculate
>the residual of my equation, once for the current solution and once for the
>current solution + a small step. At the moment I calculate the residual by
>summing the terms into my residual vector, and then distributing the values
>while setting the boundary condition to 0. If I understand it correctly,
>that happens as soon as I call phi.distribute_local_to_global(dst), with
>phi a FEEvaluation-element.
>
> Yes.

>
>- This means that I first have to assemble the residual vector, then
>distribute it, and then can use the vmult-function. Is that correct, or do
>I have to use another approach?
>
> Isn't assembling and distributing already what `vmult` is supposed to do?
Can you elaborate on what you are doing in each GMRES iteration?

Best,
Daniel

-- 
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/CAOYDWbLm%3D8p%3DY33AonJE837Q%2BxKibmBBRiN2e-6iexVu7r1UMw%40mail.gmail.com.


Re: [deal.II] Different solution with different software

2019-07-23 Thread Daniel Arndt
Felix,


> Is the rate of convergence as expected?
>>
>
> I believe so. I did a linear regression of the convergence graphs in
> logscale and got a value of :
> -7.6 for the speed : I believe it corresponds to the -8 from second order
> finete element in 2D
> -3.2 for the pressure : I beliebe it corresponds to the -4 from the first
> order finite element in 2D
>
> Good!


>
>> If u = v = 0 in your test case, there might still be a problem with these
>> equations.
>>
>
> I'm not sur to understand what you are saying here. Can you elaborate why
> you think there is a problem in my equations ?
>

If the reference solution is 0, you can't see if you are missing a constant
factor in your equation even when the rate of convergence looks correct.


>
>
>> Since the ansatz space on non-affine mapped geometries is not polynomial
>> anymore, I would also try a cartesian mesh for the case that the solution
>> is contained
>> in your ansatz space.
>>
>
> I don't really understand what you mean by ansatz space although I have
> looked it up on google. Do you suggest that I try the X=0 solution on a
> square mesh ?
>

Yes, but then you also have to be careful with the boundary conditions. If
you have an analytical solution with homogeneous Dirichlet boundary
conditions for \phi,
I would definitely try that first.

The ansatz space is the space spanned by the basis functions you are using
for your solution variables. In case the mapping from the reference cell to
the
real cell is affine and you use polynomial base functions (on the reference
element), the ansatz space is polynomial as well. Then, it is easier to
manufacture
a solution that is contained in the ansatz space.

Best,
Daniel

-- 
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/CAOYDWb%2BJz7DUmMGdN3YkbdubHsOEws91D_cT6REMfGL5LJRGXg%40mail.gmail.com.


[deal.II] Re: Different solution with different software

2019-07-19 Thread Daniel Arndt
Felix,

the usual approach for verifying your code is the method of manufactured 
solution. Choose functions that are elements of your ansatz space for all 
solution variables
(possibly chaningyour grid to a cartesian one) and compute the 
corresponding right-hand side. Check that the error vanishes.
If that works, choose smooth functions not part of your ansatz space and 
check the rate of convergence when refining your mesh.
You may also want to have a look at 
https://www.dealii.org/8.5.0/doxygen/deal.II/step_7.html for this.

Best,
Daniel

-- 
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/eca2f947-b72f-4385-bba4-1c7e7b7baede%40googlegroups.com.


Re: [deal.II] How to set material id with MPI

2019-07-17 Thread Daniel Arndt
Kien,

It is impossible for us to tell what is going wrong with this little
information. Please provide us with some more details.
What does the part of the code that is responsible for setting the material
id look like?
Are you trying to set the material id on all cells or only on the locally
owned (or locally relevant) ones?
How do you notice that the code produces wrong results?

Best,
Daniel

-- 
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/CAOYDWb%2BBmn9AogoR8SW_Da9vT6dOLSkA6Zv2Kc_2gOYD_7PaWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Re: Compatibility of Petsc with step 18

2019-07-17 Thread Daniel Arndt
Ramprasad,

Did you also recompile, i.e. run 'make', afterwards? Can you also show us 
the file 'detailed.log' in your build directory and the the file 
'base/config.h' in your installation directory?

Best,
Daniel

-- 
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/827f9523-4b62-4557-ae4f-af916a39d7af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Compatibility of Petsc with step 18

2019-07-16 Thread Daniel Arndt
Ramprasad,

Let's first rule out some simple problems. Which version of deal.II are you 
using? Did you compile deal.II with MPI and PETSc support?
We only define the namecpacePETScWrappers when DEAL_II_WITH_PETSC=ON. Can 
you provide us with the content of the detailed.log file in your build 
directory?

Best,
Daniel

-- 
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/1b94eabe-7cd4-4b79-8ffb-207234fb026c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Error while implementing FEFieldFunction to calculate the gradient of velocity on the bottom line of backward facing step flow 2D

2019-07-15 Thread Daniel Arndt
Rajeshwari,

The purpose of FEFieldFunction is that you don't have to loop through the 
cells yourself, but that you can just ask for the value at any given point 
(in global coordinates) as long as the cell
the point is contained in is not artifical. Internally, 
FEFieldFunction::gradient_list() calls 
FEFieldFunction::compute_point_locations() which also fails if there is a 
point contained in artifical cell.
Because of that and since the points you are trying to evaluate your 
solution at are the same for all processes, it is to be expected that your 
code throws an exception.

If I were you, I would call 
GridTools::distributed_compute_point_locations_try_all(https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#a5a845642f4d205352931267b58055d62)
first to get the set of points which are contained in locally owned or 
ghosted cells and then pass this subset to FEFieldFunction::gradient_list().
Of course, this means that some information 
GridTools::distributed_compute_point_locations_try_all() provides are not 
used and recomputed inside FEFieldFunction::gradient_list().

In case this turns to be too costly, you could replicate the implementation 
of the latter function to use 
GridTools::distributed_compute_point_locations_try_all() directly instead. 
Then, you could also make use of the fact that all the points you are 
interested in are located at the boundary.

I would definitely try if the first approach is sufficient first, though.

Best,
Daniel

-- 
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/2a88bc91-c032-4276-b257-5902c0327c4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Implicit stepping methods from the TimeStepping-namespace for large sparse matrices

2019-07-15 Thread Daniel Arndt
Maxi,

The interface for TimeStepping::evolve_one_time_step is:

virtual double
  evolve_one_time_step(
  std::vector>
  & F,
  std::vector> _inverse,
  double t,
  double delta_t,
  VectorType & y);

and does not depend on UMFPACK at all. You just need to provide a
function-type object that can be used for evaluating the inverse of the
Jacobians and the right-hand side.
You might also want to have a look at the test base/time_stepping_01 (
https://github.com/dealii/dealii/blob/master/tests/base/time_stepping_01.cc
).

Best,
Daniel


Am Mo., 15. Juli 2019 um 15:04 Uhr schrieb 'Maxi Miller' via deal.II User
Group :

> As far as I understand all implicit time-stepping methods in the
> TimeStepping-namespace take a function which invert the jacobian matrix and
> the mass matrix (combined). This is done using a sparse solver (UMFPACK).
> Is it that still possible for a larger system (10kk DoFs), or do I have to
> resort to other methods, after inverting the sparse matrix will result in a
> dense matrix (which likely will overflow my memory)?
>
> --
> 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/ccfe4a75-775d-471b-b69e-4a886c2e443d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/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/CAOYDWbL-X8%2BfUwArTHGow-%3D13vVrZGQPYD5W%3DmQCSppQwx4XNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Error while implementing FEFieldFunction to calculate the gradient of velocity on the bottom line of backward facing step flow 2D

2019-07-15 Thread Daniel Arndt
Rajeshwari,

We need a little bit more information to be able to help you.
- Which version of the library are you using?
- What does the mesh you are using look like?
- Do you see this problem also when running in serial or only in parallel?

It would also help to reduce your test case to a size as small as possible
if you want to share it with us.

Best,
Daniel


Am Mo., 15. Juli 2019 um 13:06 Uhr schrieb Rajeshwari Kamble <
rajeshwarikambl...@gmail.com>:

> Hi,
> I am using the gradient_list function to calculate the velocity gradient
> in x direction on the bottom wall of backward facing step and trying to
> output it using the table handler.
> But I am getting an exception of points not found in the coarse grid. The
> points vector and the gradient vector size is 288.
>
>
> Exception on processing:
>
> 
> An error occurred in line <4343> of file
>  in function
> std::tuple spacedim>::active_cell_iterator, std::allocator dealii::Triangulation::active_cell_iterator> >,
> std::vector,
> std::allocator > >,
> std::allocator,
> std::allocator > > > >,
> std::vector >,
> std::allocator > > >
> > dealii::GridTools::compute_point_locations(const
> dealii::GridTools::Cache&, const
> std::vector >&, const typename
> dealii::Triangulation::active_cell_iterator&) [with int dim
> = 2; int spacedim = 2; typename dealii::Triangulation spacedim>::active_cell_iterator =
> dealii::TriaActiveIterator >; typename
> dealii::Triangulation::active_cell_iterator =
> dealii::TriaActiveIterator >]
> The violated condition was:
> std::get<3>(cqmp).size() == 0
> Additional information:
> The point <0 0> could not be found inside any of the subcells of a
> coarse grid cell.
> 
> An error occurred in line <4343> of file
>  in function
> std::tuple spacedim>::active_cell_iterator, std::allocator dealii::Triangulation::active_cell_iterator> >,
> std::vector,
> std::allocator > >,
> std::allocator,
> std::allocator > > > >,
> std::vector >,
> std::allocator > > >
> > dealii::GridTools::compute_point_locations(const
> dealii::GridTools::Cache&, const
> std::vector >&, const typename
> dealii::Triangulation::active_cell_iterator&) [with int dim
> = 2; int spacedim = 2; typename dealii::Triangulation spacedim>::active_cell_iterator =
> dealii::TriaActiveIterator >; typename
> dealii::Triangulation::active_cell_iterator =
> dealii::TriaActiveIterator >]
> The violated condition was:
> std::get<3>(cqmp).size() == 0
> Additional information:
> The point <17 0> could not be found inside any of the subcells of a
> coarse grid cell.
>
> PS: I am newer to using deal ii and I checked the discussion on the question  
>  Usage of FEFieldFunction.vector_value_list on a 
> parallel::distributed::Triangulation posted earlier but still not able to
> find the mistake.
>
> --
> 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/73791db1-68b0-4f49-832b-5896b7563876%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/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/CAOYDWb%2BSUCbhb012wPZ04z_%3Dir5pTgi8bCjRAzKkCbT1h-ShJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Matrix-Vector-multiplication on deal.II-grid

2019-07-12 Thread Daniel Arndt
Maxi,

can you clarify the operator evaluation you want to perform in mathematical 
terms (maybe as an integral)?

Best,
Daniel

-- 
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/435ca58b-e682-45fa-b817-98458471e19d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Deal.II-Installation on Cluster fails

2019-07-11 Thread Daniel Arndt
Maxi,

Can you just try again with a recent commit?

Best,
Daniel

-- 
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/7ec613be-2752-4358-a0ae-e10a18f0449a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Porting tutorials to PETSc from Trilinos

2019-07-11 Thread Daniel Arndt
Franco,
 

> [...]
> As I didn't find a 1:1 correspondence between the two namespaces, I've 
> resorted to remove Trilinos classes as best as I could, for instance, 
> TrilinosWrappers::BlockSparseMatrix exists but in PETSc there is only 
> PETScWrappers::MPI::BlockSparseMatrix that I know of. And the two seem to 
> be not exactly equivalent.
>

step-40 tries to allow switching between Trilinos and PETSc as easy as 
possible by using the deal.II/lac/generic_linear_algebra.h header and the 
defining the LA::MPI namespace.
 

> [...]
> std::shared_ptr Amg_preconditioner;
>
 
This looks inappropriate. Probably it should rather be 
PETScWrappers::PreconditionBoomerAMG;

Best,
Daniel

-- 
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/bdb2c6c2-c7d2-4ab6-bed6-9941740297df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] constraining dofs across distributed mesh

2019-07-10 Thread Daniel Arndt


> [...]
> It works in the serial case. However, it doesn't work when I use multiple 
> MPI processes. For my actual mesh, it breaks when n_processes >= 5. 
> Basically I have to make sure that dof 41 is included in the relevant dofs 
> of all the processes. How to I do that? I think this type of constraint is 
> different than a periodic boundary condition and I could not find a 
> dedicated function that takes care of it.
>
No, there is no function for that. It would of course be pretty simple if 
you just knew the value all these dofsshould be set to, but I assume that's 
not the case.

I didn't mean to say that you have to modify the locally relevant dofs, 
i.e. the IndexSet you obtain from DoFtools::locally_relevant_dofs, but tha 
tyou need to use an extended IndexSet in all the places you would normally 
use that IndexSet.
There is IndexSet::add_index that you can use to add entries to an existing 
IndexSet object.

Best,
Daniel

-- 
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/ba25e22c-428b-4073-b0a6-f485b4fba92f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] constraining dofs across distributed mesh

2019-07-10 Thread Daniel Arndt
Reza,

What exactly do you mean by "link all the dofs of all the nodes along an
edge of the body together"?
>From the error message above, I assume that you want to identify certain
degrees of freedom via a ConstraintMatrix (or AffineConstraints) object.
That is basically what DoFTools::make_periodicity_constraints is doing as
well. Are you trying to do something similar?
In any way, you need to make sure that the ConstraintMatrix (or
AffineConstraints) object can store all the degrees of freedom you want to
constrain.
This is normally the set of locally relevant degrees and freedoms and the
reason why you normally do

constraints.reinit

(locally_relevant_dofs);

In your case, you need to make sure that you extend this IndexSet by the
degrees of freedom you want to constrain. Furthermore, all processes need
to know about all
the constraints related to these constraints. There is
AffineConstraints::is_consistent_in_parallel (
https://www.dealii.org/current/doxygen/deal.II/classAffineConstraints.html#ad5fb8d3ca686a76ba33eb82d7f52b5fd
)
that checks that this is the case. Of course, you need to pass the modified
IndexSet there as well instead of just the locally relevant dofs.

Best,
Daniel


Am Mi., 10. Juli 2019 um 20:48 Uhr schrieb Reza Rastak <
reza.ras...@gmail.com>:

> Hi,
>
>
> I like to link all the dofs of all the nodes along an edge of the body
> together. So I find the first dof (dof i) located on the edge and then I
> try to link all the dofs on that edge (except i) to dof i. It does not work
> if I have sufficiently large number of processes where that edge is chopped
> by different MPI processes. I know why it does not work, but I don't know
> any methods that can provide my desired dof constraints. Anyone has
> attempted to solve something similar?
>
>
> This is the error that I get with 8 MPI processes.
>
> 
>
> An error occurred in line <1607> of file
> 
> in function
>
> void
> dealii::ConstraintMatrix::add_entry(dealii::ConstraintMatrix::size_type,
> dealii::ConstraintMatrix::size_type, double)
>
> The violated condition was:
>
> !local_lines.size() || local_lines.is_element(column)
>
> Additional information:
>
> The index set given to this constraint matrix indicates constraints
> using degree of freedom 580 should not be stored by this object, but a
> constraint for degree of freedom 736 uses it.
>
> 
>
>
> Regards,
>
>
> Reza
>
>
> --
> 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/31e7aedd-b087-41d4-a412-0e211bcb27bd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/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/CAOYDWb%2Be-4Xi1ESmUb64USo3RarK%3DVmhvPYof6yqcidnPqcv5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Equivalent option for local_range() for Trilinos vectors

2019-07-10 Thread Daniel Arndt
Vivek,

just remove the line
if (i->first >= range.first && i->first < range.second)
VectorTools::interpolate_boundary_values should only set values for locally
active degrees of freedom anyway.
As long as the values are consistent between different processes, this
should work just fine.

Best,
Daniel


Am Mi., 10. Juli 2019 um 20:02 Uhr schrieb Vivek Kumar <
vivekkr1...@gmail.com>:

> Hi all,
>
> I had a legacy code were PETScWrappers::MPI::Vectors were used to for
> parallel computing. For very large problems, I was told to move to
> Trilinos. It was fairly easy to do so for most part of the code but I am
> stuck in the implementation of boundary values. Currently the boundary
> values are implemented as follows:
>
> template
> void ElasticityEquation::apply_boundary_conditions(const double time,
> const double velocity)
> {
> // Begin timer
> TimerOutput::Scope t(computing_timer, "Apply Boundary Condition");
>
> boundary_values.clear();
> VectorTools::interpolate_boundary_values
> (dof_handler,2,ZeroFunction(dim),boundary_values);
>
> VectorTools::interpolate_boundary_values
> (dof_handler,3,BoundaryValues(time, velocity) , boundary_values);
> // The range of owned dofs
> std::pair range = solution.local_range();
>
> // Set the boundary conditions
> for (typename std::map::const_iterator i =
> boundary_values.begin(); i != boundary_values.end(); ++i){
> if (i->first >= range.first && i->first < range.second){
> completely_distributed_solution(i->first) = i->second;
> }
> }
>
> completely_distributed_solution.compress(VectorOperation::insert);
>
> hanging_constraints.distribute( completely_distributed_solution);
>
> solution = completely_distributed_solution;
> }
>
>
> This used to work fine with PETSc but not with Trilinos. The issue seems
> to be the fact the Trilinos does not arrange the vector contiguous ranges
> of elements (
> https://www.dealii.org/current/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html#abcc22742227d63950cb0995223e6ee32)
> . Is there a standard workaround?
>
> Thanks
> Vivek
>
> --
> 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/73ea3ef9-b5f8-461d-81c0-e43c0b4d8fbb%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/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/CAOYDWbK98dz_690UiyRpPdT77Lo%3D_%3Djb2Rr8ydfr-Nqy6dMBRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Output subset of cells

2019-07-05 Thread Daniel Arndt
Alexander,

have a look at
https://www.dealii.org/developer/doxygen/deal.II/classDataOut.html#afdefbb966f2053f4c4fc52293d2339ce
.
You just need to overload DataOut::next_cell().

Best,
Daniel

Am Fr., 5. Juli 2019 um 10:34 Uhr schrieb Alexander :

> I am starting to hit a space/memory boundary since my VTU output becomes >
> 100 GB. Partial mitigation to this would be to output (DataOut) only some
> cells in VTU, which are of interest. In my applications, I can easily
> ignore at least half of cells.
>
> Is there a possibility to do that within the existing interface?
>
> Best
> Alexander
>
>
> --
> 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/0464e017-bada-410b-a1af-ea51637d7eee%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/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/CAOYDWbKfx6KV4a9W5ZqS9RURUu3S1fZb4vmVM-yYRrAq_2k8hw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Error estimation using a function of your solution vector

2019-07-03 Thread Daniel Arndt
Bruno

Hello everyone,
> I was wondering what was the simplest way to carry out error estimation
> using a function of your solution vector. For example, to carry out mesh
> adaptation using  a Kelly Error estimator but using the vorticity as the
> input variable instead of the velocity vector.
> Is there a way to do it in a similar fashion as the way we can
> post-process with DataPostprocessorScalar or
> DataPostprocessorVector? (which is what we use for the vorticity and
> the q-criterion post-processing)
>
DataPostprocessor computes values in certain evaluation points that are not
(necessarily) related to any given finite element space.
On the other hand, KellyerrorEstimator expects a finite element vector.
What you need to do is to represent the vorticity in some finite element
space.
You would typically either interpolate or project with respect to this new
space.

Best,
Daniel

-- 
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/CAOYDWb%2BrTm-c_KA09m%3Dt0CCRHagavw-41YmibkL7OOPTEPsrLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Storing additional information at the DOF unrelated to the system you are solving

2019-07-01 Thread Daniel Arndt
Bruno.

Let's say I solve a first equation for Velocity, and I would like to use 
> this velocity in another equation for advection-diffusion of say 
> Temperature.
> I would first set-up my DOF and FE system for my velocity equation and 
> solve it and set-up by DOF and FE system for my Temperature.
> However, how would I be able to set up an additional space to store my 
> velocity at the nodes that are related to my Temperature FESystem without 
> introducing additional unknown in my  temperature equations (Since velocity 
> is known after all) and without assuming that both my temperature and 
> velocity equation are numbered in the same exact fashion? 
>

For assemling a bilinear form you typically don't nees the support points 
of the ansatz functions but their evaluations in the quadrature points.
In your case, I would simply use two DoFHandler objects (one for each 
system of equations) and loop over both of them for the temperature 
equations.
https://www.dealii.org/current/doxygen/deal.II/step_31.html#BoussinesqFlowProblemassemble_temperature_system
 
might be helpful.

Best,
Daniel

-- 
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/11aacb53-a652-446d-867c-ef3e1b440c6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   4   >