Re: [deal.II] Use of std::map boundary_values object instead of constraint object in step-40 tutorail

[Wolfgang Bangerth]

Wasim,

I am working on a problem very similar to the Laplace equation solved in 
step-3. I have made some changes to step-3 as I need to. Now, I want to solve 
this problem in parallel. I looked at step-40, which solves the Laplace 
equation in parallel. However, it uses a constraints object to apply BCs. 
Right now, I don't have any hanging nodes to handle, so I used a std::map 
object to apply BCs. I first copy all the local contributions to the global 
matrix and then apply the BCs.
  While going through the documentation of step-40,  I read that *"Copying 
local contributions into the global matrix must include distributing 
constraints and boundary values. In other words, we cannot (as we did in 
step-6 
) first copy every local contribution into the global matrix and only in a later step take care of hanging node constraints and boundary values."*

*
*


This text turns out to no longer be correct. It refers to a method step-6 used 
to use, but no longer does. I've fixed this here:

https://github.com/dealii/dealii/pull/14801/files


If my understanding is correct, then I think the following line of code does 
this job in step-40:

*constraints.distribute_local_to_global(cell_matrix,cell_rhs,local_dof_indices,*
**
*system_matrix,system_rhs);*
My doubt is whether it is possible to do this(*Copying local contributions 
into the global matrix and distributing boundary values.*) with the std::map 
object or do I need to use a constraint object even though I don't have any 
hanging nodes to handle.


It requires an AffineConstraints object, just like the current state of step-6 
and step-40 do.


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/9f945654-d4a1-8467-3a8f-c13d60269f2d%40colostate.edu.

Re: [deal.II] Convergence failure in step 0.

['yy.wayne' via deal.II User Group]

I'll do some further test. Your advice on locating NaN error really helps 
me. Thank you Wolfgang :)

Best,
Wayne
在2023年2月15日星期三 UTC+8 12:17:44 写道：

> On 2/14/23 19:04, 'yy.wayne' via deal.II User Group wrote:
> > 
> > Yes the diagonal could be negative when k rises. Will Chebyshev 
> preconditioner 
> > smoother converge
> > when there are negative entries?
>
> I have no idea :-)
>
>
> > In my case k hasn't rise so large that diagonal entries is negative. The 
> > negative entries shows up only
> > when compute_normal_flux constraints is applied. I think 
> > AffineConstraints::distribute_local_to_global 
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FclassAffineConstraints.html%23a373fbdacd8c486e675b8d2bff8943192%3A~%3Atext%3DThus%2C%2520if%2520a%2520degree%2Cin%2520the%2520global%2520matrix.=05%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd2ecd8f014fc4c51b63308db0ef8fd28%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C638120234786119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c2TyCwiADwVWxKmtOEDrujHEkVC%2F8QPR5k7gIip3OoQ%3D=0
> >
> > is the cause since in matrix-based assemble, this function add a 
> positive 
> > value on the constrained
> > dofs while matrix-free does not. Therefore the diagonals are different 
> between 
> > matrix-free and matrix-based.
>
> That's possible. I don't know enough about the matrix-free framework to 
> tell 
> one way or the other, but maybe some of my colleagues here will know.
>
> 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/7c40c32c-5802-4911-9143-1971a158c81dn%40googlegroups.com.

Re: [deal.II] Convergence failure in step 0.

[Wolfgang Bangerth]

On 2/14/23 19:04, 'yy.wayne' via deal.II User Group wrote:


Yes the diagonal could be negative when k rises. Will Chebyshev preconditioner 
smoother converge

when there are negative entries?


I have no idea :-)


In my case k hasn't rise so large that diagonal entries is negative. The 
negative entries shows up only
when compute_normal_flux constraints is applied. I think 
AffineConstraints::distribute_local_to_global 

is the cause since in matrix-based assemble, this function add a positive 
value on the constrained
dofs while matrix-free does not. Therefore the diagonals are different between 
matrix-free and matrix-based.


That's possible. I don't know enough about the matrix-free framework to tell 
one way or the other, but maybe some of my colleagues here will know.


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/92c9d94b-6637-8d4a-e883-f47e2fc8d0ec%40colostate.edu.

Re: [deal.II] Re: dealii and hdf5 compile problem

[Praveen C]

I had hdf+mpi installed by spack, so I commented out the check in deal.II in 
the file

cmake/configure/configure_50_hdf5.cmake



MACRO(FEATURE_HDF5_FIND_EXTERNAL var)
  FIND_PACKAGE(HDF5)

  IF(HDF5_FOUND)
    SET(${var} TRUE)

#   IF(NOT HDF5_IS_PARALLEL)
#     MESSAGE(STATUS "Insufficient hdf5 installation found: "
#       "hdf5 has to be configured with MPI support."
#       )
#     SET(HDF5_ADDITIONAL_ERROR_STRING
#       "Insufficient hdf5 installation found!\n"
#       "hdf5 has to be configured with MPI support.\n"
#       )
#     SET(${var} FALSE)
#   ENDIF()

    CHECK_MPI_INTERFACE(HDF5 ${var})
  ENDIF()
ENDMACRO()

best
praveen
On 14 Feb 2023 at 8:03 PM +0530, Ester Comellas , 
wrote:
> Hi All,
>
> Praveen, I'm getting this exact same error message when I try to compile my 
> deal.II code. It's been a while since your post... do your recall how you 
> solved it?
>
> I recently reinstalled deal.II via spack after upgrading macOS to Ventura 
> 13.2. This is my error message:
> Consolidate compiler generated dependencies of target TuringPatterns
> [ 50%] Linking CXX executable TuringPatterns
> ld: library not found for -lhdf5-shared
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[2]: *** [TuringPatterns] Error 1
> make[1]: *** [CMakeFiles/TuringPatterns.dir/all] Error 2
> make: *** [all] Error 2
>
> And the detailed.log shows:
>      # DEAL_II_WITH_HDF5 set up with external dependencies
>      # HDF5_VERSION = 1.10.7
>      # HDF5_DIR = 
> /Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.0_spack/hdf5-1$
>      # HDF5_INCLUDE_DIRS = 
> /Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.0_spa$
>      # HDF5_USER_INCLUDE_DIRS = 
> /Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.$
>      # HDF5_LIBRARIES = hdf5-shared
>
> The file "macro_find_package.cmake" Praveen mentioned in his original post 
> doesn't exist in my installation. I don't know why spack didn't install the 
> preferred version of hdf5 (1.12.2). I'm wondering whether I should install 
> the preferred version or the most recent version (1.13.2) of hdf5 and try 
> reinstalling deal.II? Could this solve the problem? Any suggestions would be 
> really welcome. Thanks!
>
> Best,
> Ester
>
> > El dia dimecres, 17 d’agost de 2022 a les 10:19:40 UTC+2, Praveen C va 
> > escriure:
> > > The detailed.log shows this
> > >
> > > #        DEAL_II_WITH_HDF5 set up with external dependencies
> > > #            HDF5_VERSION = 1.12.2
> > > #            HDF5_DIR = 
> > > /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/apple-clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/cmake
> > > #            HDF5_INCLUDE_DIRS = 
> > > /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/apple-    
> > > clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/include
> > > #            HDF5_USER_INCLUDE_DIRS = 
> > > /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/     
> > > apple-clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/include
> > > #            HDF5_LIBRARIES = hdf5-shared
> > >
> > > and last line above seems wrong.
> > >
> > > Thanks
> > > praveen
> > >
> > > > On 17-Aug-2022, at 11:49 AM, Praveen C  wrote:
> > > >
> > > > Hello
> > > >
> > > > I am compiling dea...@9.4.0 myself using dependent packages installed 
> > > > via spack.
> > > >
> > > > I am facing the issue reported here
> > > >
> > > > https://github.com/spack/spack/issues/32023
> > > >
> > > > and is fixed here
> > > >
> > > > https://github.com/spack/spack/pull/32079
> > > >
> > > > This fix seems to remove the file
> > > >
> > > > cmake/macros/macro_find_package.cmake
> > > > I removed it and was able to compile dealii. But when I compile an 
> > > > example, I get this error
> > > >
> > > > Consolidate compiler generated dependencies of target step-1
> > > > [ 50%] Linking CXX executable step-1
> > > > ld: library not found for -lhdf5-shared
> > > > clang: error: linker command failed with exit code 1 (use -v to see 
> > > > invocation)
> > > > make[2]: *** [step-1] Error 1
> > > > make[1]: *** [CMakeFiles/step-1.dir/all] Error 2
> > > > make: *** [all] Error 2
> > > >
> > > > Thanks for any help.
> > > > Best
> > > > praveen
> > >
> --
> 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/ae92d984-ea52-4a5e-8609-4123deff23b2n%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 

Re: [deal.II] Convergence failure in step 0.

['yy.wayne' via deal.II User Group]

Hi Wolfgang,

Yes the diagonal could be negative when k rises. Will Chebyshev 
preconditioner smoother converge
when there are negative entries?

In my case k hasn't rise so large that diagonal entries is negative. The 
negative entries shows up only
when compute_normal_flux constraints is applied. I think 
AffineConstraints::distribute_local_to_global 

is the cause since in matrix-based assemble, this function add a positive 
value on the constrained 
dofs while matrix-free does not. Therefore the diagonals are different 
between matrix-free and matrix-based.

Best,
Wayne

在2023年2月15日星期三 UTC+8 00:39:41 写道：

> On 2/14/23 07:15, 'yy.wayne' via deal.II User Group wrote:
> > The weak problem I'm solving is   +  - 
> > k^2 = RHS, which is vector Maxwell wave equation (for nodal basis).
> > [...]
> > 1) Is it reasonable the diagonal computed by MatrixFree operator with 
> > compute_normal_flux() has negative entries?
>
> The diagonal entries of the matrix, for this bilinear form, are 
> integrals of the form
>
> A_ii = \int (curl phi_i)*(curl phi_i) + (div phi_i)*(div phi_i)
> - k^2 phi_i * phi_i
>
> In other words, A_ii is a sum of squares, but one of the squares is 
> negative. If k is small, the sum may still be positive, but for sure if 
> k is large, the diagonal entries of A will be negative.
>
> 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/0067be90-8710-4184-a33d-48c7c5fbdc3an%40googlegroups.com.

[deal.II] Use of std::map boundary_values object instead of constraint object in step-40 tutorail

[Wasim Niyaz Munshi ce21d400]

Hello everyone.
I am working on a problem very similar to the Laplace equation solved in 
step-3. I have made some changes to step-3 as I need to. Now, I want to 
solve this problem in parallel. I looked at step-40, which solves the 
Laplace equation in parallel. However, it uses a constraints object to 
apply BCs. Right now, I don't have any hanging nodes to handle, so I used a 
std::map object to apply BCs. I first copy all the local contributions to 
the global matrix and then apply the BCs.
 While going through the documentation of step-40,  I read that *"Copying 
local contributions into the global matrix must include distributing 
constraints and boundary values. In other words, we cannot (as we did in 
step-6 ) first 
copy every local contribution into the global matrix and only in a later 
step take care of hanging node constraints and boundary values."*

If my understanding is correct, then I think the following line of code 
does this job in step-40:
*constraints.distribute_local_to_global(cell_matrix,cell_rhs,local_dof_indices,*
* system_matrix,system_rhs);*
My doubt is whether it is possible to do this(*Copying local contributions 
into the global matrix and distributing boundary values.*) with the 
std::map object or do I need to use a constraint object even though I don't 
have any hanging nodes to handle.

Thanks and regards
Wasim

-- 
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/76972977-2325-4cc3-9822-560e520ba99bn%40googlegroups.com.

Re: [deal.II] Convergence failure in step 0.

[Wolfgang Bangerth]

On 2/14/23 07:15, 'yy.wayne' via deal.II User Group wrote:
The weak problem I'm solving is   +  - 
k^2 = RHS, which is vector Maxwell wave equation (for nodal basis).

[...]
1) Is it reasonable the diagonal computed by MatrixFree operator with 
compute_normal_flux() has negative entries?


The diagonal entries of the matrix, for this bilinear form, are 
integrals of the form


  A_ii = \int (curl phi_i)*(curl phi_i) + (div phi_i)*(div phi_i)
  - k^2 phi_i * phi_i

In other words, A_ii is a sum of squares, but one of the squares is 
negative. If k is small, the sum may still be positive, but for sure if 
k is large, the diagonal entries of A will be negative.


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/cccf476e-3347-721e-eeab-e1be59589ea3%40colostate.edu.

Re: [deal.II] Re: Creating a plot in dealii

[Wasim Niyaz Munshi ce21d400]

Thank you very much. It was indeed the easiest way to do it.

Regards

Wasim Niyaz
Research scholar
CE Dept.
IITM

On Mon, 13 Feb, 2023, 7:22 pm Bruno Turcksin, 
wrote:

> Hello,
>
> DataOut is made to add data to a mesh. It cannot be used to do what you
> want. The easiest way to do what you want is to write the vectors to a file
> using print() and then do the plot using matlab or python.
>
> Best,
>
> Bruno
>
> On Saturday, February 11, 2023 at 9:27:06 AM UTC-5
> ce21...@smail.iitm.ac.in wrote:
>
>> Hello everyone. I have 2 Vector vectors A and B of the same
>> size,n. I want to plot A vs B (A along x and B along y). I was trying
>> something like this:
>>  DataOut<1,Vector > data_out;
>>   data_out.add_data_vector (A, "A");
>>   data_out.add_data_vector (B, "B");
>>
>>   // Write the Gnuplot file
>>   data_out.build_patches ();
>>   data_out.write_gnuplot (deallog.get_file_stream());
>>  but it gives these errors:
>> error: type/value mismatch at argument 2 in template parameter list for
>> ‘template class dealii::DataOut’
>>  expected a constant of type ‘int’, got ‘dealii::Vector’
>>
>>
>> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/CJH-Z37kLco/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/3a96404f-f7fc-4aa2-83e9-0f35cf8889f6n%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/CAM8ps5C6hPW60_zsmaTCk2M%2B8dstZQDJjrM%3DtgUZY8NmvgWuPg%40mail.gmail.com.

[deal.II] Re: dealii and hdf5 compile problem

[Ester Comellas]

Hi All,

Praveen, I'm getting this exact same error message when I try to compile my 
deal.II code. It's been a while since your post... do your recall how you 
solved it?  

I recently reinstalled deal.II via spack after upgrading macOS to Ventura 
13.2. This is my error message:

 *Consolidate compiler generated dependencies of target TuringPatterns*
  [ 50%] *Linking CXX executable TuringPatterns*
 ld: library not found for -lhdf5-shared
 clang: *error: **linker command failed with exit code 1 (use -v to see 
invocation)*
 make[2]: *** [TuringPatterns] Error 1
 make[1]: *** [CMakeFiles/TuringPatterns.dir/all] Error 2
 make: *** [all] Error 2

And the detailed.log shows:
 # DEAL_II_WITH_HDF5 set up with external dependencies 
 # HDF5_VERSION = 1.10.7 
 # HDF5_DIR = 
/Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.0_spack/hdf5-1$
 

 # HDF5_INCLUDE_DIRS = 
/Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.0_spa$ 

 # HDF5_USER_INCLUDE_DIRS = 
/Users/ecomellas/spack/opt/spack/darwin-ventura-skylake/apple-clang-14.0.$ 
 # HDF5_LIBRARIES = hdf5-shared

The file "macro_find_package.cmake" Praveen mentioned in his original post 
doesn't exist in my installation. I don't know why spack didn't install the 
preferred version of hdf5 (1.12.2). I'm wondering whether I should install 
the preferred version or the most recent version (1.13.2) of hdf5 and try 
reinstalling deal.II? Could this solve the problem? Any suggestions would 
be really welcome. Thanks!

Best,
Ester

El dia dimecres, 17 d’agost de 2022 a les 10:19:40 UTC+2, Praveen C va 
escriure:

> The detailed.log shows this
>
> #DEAL_II_WITH_HDF5 set up with external dependencies
> #HDF5_VERSION = 1.12.2
> #HDF5_DIR = 
> /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/apple-clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/cmake
> #HDF5_INCLUDE_DIRS = 
> /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/apple-
> clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/include
> #HDF5_USER_INCLUDE_DIRS = 
> /Users/praveen/Applications/spack/opt/spack/darwin-monterey-m1/ 
> apple-clang-13.1.6/hdf5-1.12.2-gxrwbuzg3xom562obmqaqtu5forevio5/include
> #HDF5_LIBRARIES = hdf5-shared
>
> and last line above seems wrong.
>
> Thanks
> praveen
>
> On 17-Aug-2022, at 11:49 AM, Praveen C  wrote:
>
> Hello
>
> I am compiling dea...@9.4.0 myself using dependent packages installed via 
> spack.
>
> I am facing the issue reported here
>
> https://github.com/spack/spack/issues/32023
>
> and is fixed here
>
> https://github.com/spack/spack/pull/32079
>
> This fix seems to remove the file
>
> cmake/macros/macro_find_package.cmake
>
> I removed it and was able to compile dealii. But when I compile an 
> example, I get this error
>
> *Consolidate compiler generated dependencies of target step-1*
> [ 50%] *Linking CXX executable step-1*
> ld: library not found for -lhdf5-shared
> clang: *error: **linker command failed with exit code 1 (use -v to see 
> invocation)*
> make[2]: *** [step-1] Error 1
> make[1]: *** [CMakeFiles/step-1.dir/all] Error 2
> make: *** [all] Error 2
>
> Thanks for any help.
> Best
> praveen
>
>
>

-- 
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/ae92d984-ea52-4a5e-8609-4123deff23b2n%40googlegroups.com.

Re: [deal.II] Installing an older version with candi

[Timo Heister]

The deal.II version can be chosen in candi.cfg. This will only work to
a certain point (dependencies will be too new for deal.II to work
properly), so a safer bet is to go to an older version of candi (by
using git checkout of one of the older dealii-* branches).

On Tue, Feb 14, 2023 at 7:17 AM Alberto SALVADORI
 wrote:
>
> Sorted out. Sorry to bother. Alberto Alberto Salvadori  Dipartimento di 
> Ingegneria Meccanica e Industriale (DIMI)  Universita` di Brescia, via Branze 
> 43, 25123 Brescia  Italy  tel 030 3715426 e-mail:  alberto. salvadori@ unibs. 
> it ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> Use caution when opening links or attachments if you do not recognize the 
> sender.
>
> ZjQcmQRYFpfptBannerEnd
> Sorted out. Sorry to bother.
> Alberto
>
> Alberto Salvadori
>  Dipartimento di Ingegneria Meccanica e Industriale (DIMI)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3715426
>
> e-mail:
>  alberto.salvad...@unibs.it
> web-page:
>  http://m4lab.unibs.it/faculty.html
>
>
>
> On Tue, Feb 14, 2023 at 1:09 PM Alberto Salvadori 
>  wrote:
>>
>> Dear community
>>
>> I would like to install the dealii version 9.2.0 via candi. I noticed the 
>> file VERSION and assumed that replacing "9.4.2-r2" with "9.2.0" would work. 
>> Apparently it is not effective, candi is still unpacking in the directory 
>> deal.ii-v9.4.2. Can anyone address me to solve the issue?
>>
>> Many thanks!
>>
>> Alberto
>>
>>
>> Informativa sulla Privacy: https://www.unibs.it/it/node/1452
>>
>> --
>> 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/4074cb43-9656-476b-ad5e-9b34fc73dc32n%40googlegroups.com.
>
>
>
> Informativa sulla Privacy: https://www.unibs.it/it/node/1452
>
> --
> 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/CABcATpdqu-7CZ%2B5GLrPYGWJACUCBtPSVXhWMHoUTeoTA6tzvVw%40mail.gmail.com.



-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAMRj59Es20w4GTWkWRwzfDa54UBp0MduqyCTbAQ5%2B2cqkjNyuQ%40mail.gmail.com.

Re: [deal.II] Installing an older version with candi

[Alberto SALVADORI]

Sorted out. Sorry to bother.
Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3715426

e-mail:
 alberto.salvad...@unibs.it
web-page:
 http://m4lab.unibs.it/faculty.html



On Tue, Feb 14, 2023 at 1:09 PM Alberto Salvadori <
alberto.salvad...@unibs.it> wrote:

> Dear community
>
> I would like to install the dealii version 9.2.0 via candi. I noticed the
> file VERSION and assumed that replacing "9.4.2-r2" with "9.2.0" would work.
> Apparently it is not effective, candi is still unpacking in the directory
> deal.ii-v9.4.2. Can anyone address me to solve the issue?
>
> Many thanks!
>
> Alberto
>
>
> Informativa sulla Privacy: https://www.unibs.it/it/node/1452
>
> --
> 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/4074cb43-9656-476b-ad5e-9b34fc73dc32n%40googlegroups.com
> 
> .
>

-- 


Informativa sulla Privacy: https://www.unibs.it/it/node/1452 


-- 
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/CABcATpdqu-7CZ%2B5GLrPYGWJACUCBtPSVXhWMHoUTeoTA6tzvVw%40mail.gmail.com.

[deal.II] Installing an older version with candi

[Alberto Salvadori]

Dear community

I would like to install the dealii version 9.2.0 via candi. I noticed the 
file VERSION and assumed that replacing "9.4.2-r2" with "9.2.0" would work. 
Apparently it is not effective, candi is still unpacking in the directory 
deal.ii-v9.4.2. Can anyone address me to solve the issue?

Many thanks!

Alberto

-- 


Informativa sulla Privacy: https://www.unibs.it/it/node/1452 


-- 
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/4074cb43-9656-476b-ad5e-9b34fc73dc32n%40googlegroups.com.

Re: [deal.II] Convergence failure in step 0.

['yy.wayne' via deal.II User Group]

Thanks for your reply Martin.

The reason my Chebyshev preconditioner breaks is the (inverse) diagonal 
vector I get from MatrixFree operator contains negative entries. 
In my corresponding matrix-based code with exactly same geometry and 
boundary condition, the matrix diagonal has no negaive entries.

I apply a "compute_nonzero_tangential_flux_constraints_on_level" function 
similar to the normal_flux one. The geometry of this problem is a shell. 
When that BC is applied on outer boundary there's no negative entries, but 
the error comes when applied on inner boundary. I'm still debugging to see 
where the error comes from.

I got a quesiton that do FEEvaluation auto deal with constraints? It seems 
a matrixfree_operator.vmult solution 
equals matrixbased_matrix.vmult + AffineConstraints.distribute.

Best
Wayne

在2023年2月14日星期二 UTC+8 15:33:18 写道：

> To extend over what Wolfgang said, the most likely causes for failure with 
> the Chebyshev preconditioner are:
>
> - the vector supplying the matrix diagonal (via the field 
> AdditionalData::preconditioner) contains Inf or NaN entries, which in turn 
> result from either a ill-formed differential operator or a bug in the code 
> computing the diagonal, or
>
> - a coarse level holding only constrained degrees of freedom, which are 
> not treated properly so that the SolverCG making an eigenvalue estimate 
> needs to work with an unsolvable linear system (right hand side not in the 
> image of the matrix).
>
> For the first case, you would check the diagonal on each level and the 
> code leading to that, in the second the treatment of constraints.
>
> Best,
> Martin
> On 14.02.23 06:33, 'yy.wayne' via deal.II User Group wrote:
>
> Thank you Wolfgang. I didin't dive much into the Chebyshev preconditioner 
> because I'm not familiar with it.  
> I assume it's because the CG solver inside Chebyshev preconditioner didn't 
> converge or what.
> But as you stated, if NaN should only get from NaN elements and divided by 
> zero, then I may find the error. 
> I'll follow your debug suggestion.   
>
> Best
> Wayne
>
> 在2023年2月14日星期二 UTC+8 12:48:42 写道：
>
>>
>> > It's strange that the iteration breaks at step 0. If I try right 
>> > preconditioning, it breaks at step 1 with nan. Besides, if there is 
>> only on 
>> > multigrid level, the problem is solved correctly with 1 iteration, so 
>> matrices 
>> > should be correct. The coarse solution is good enough for smoothing. 
>> > 
>> > The question is, in which case may a CG or GMRES solver breaks at step 
>> 0 with nan? 
>>
>> NaN errors, like segmentation faults, are relatively easy to find because 
>> you 
>> know that every NaN you get is wrong. So you check that the matrix and 
>> right 
>> hand side and solution vector you give to the solver don't have any NaNs. 
>> If 
>> they don't, and you get NaNs out, then the problem likely lies with the 
>> preconditioner, so you single step through the solver around the place 
>> where 
>> the preconditioner is applied and check in which operation the NaN 
>> appears. 
>>
>> In your case, you seem to have already found out that it's the Chebyshev 
>> preconditioner. The question is why. Is it because the matrix the 
>> preconditioner uses has NaNs in it? Is it because the preconditioner 
>> makes an 
>> assumption that it can divide by certain matrix entries, but they are 
>> zero? 
>> Single stepping in a debugger will give you the answer :-) 
>>
>> Best 
>> W. 
>>
>> -- 
>>  
>> Wolfgang Bangerth email: bang...@colostate.edu 
>> www: http://www.math.colostate.edu/~bangerth/ 
>>
>>
>> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+un...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/a0326f84-a7b7-49ec-97b7-db1579574e87n%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/dc0e8bfc-3f3d-44ec-9b71-12ed663d75adn%40googlegroups.com.

Re: [deal.II] Convergence failure in step 0.

[Peter Munch]

Hi Wayne,

it seems that you are using multigrid on a locally refined mesh. Have you 
tried to use globally refined meshes? This one does not have inner 
boundaries so that the issue should not occur. Does it?

You might have forgotten to attach the constrains to the transfer 
operator: 
https://www.dealii.org/developer/doxygen/deal.II/classMGTransferBlockMatrixFree.html#afd5ace82516e421e37af4572aabf4098.
 
Also you might have forgotten to apply edge constrains. This is how we do 
it in one of our 
codes: 
https://github.com/peterrum/dealii-multigrid/blob/c50581883c0dbe35c83132699e6de40da9b1b255/include/operator.h#L191-L226.
 
Did you set the edge 
matrices: 
https://www.dealii.org/developer/doxygen/deal.II/classMultigrid.html#a6d1eff544f75da8c308fdc42c6c0c74d?

As proof of concept, you could also try out the global-coarsening multigrid 
infrastructure (step-75); there, there are no internally boundaries per 
definition.

Peter

On Tuesday, 14 February 2023 at 09:25:28 UTC+1 yy.wayne wrote:

> Thanks for your reply Martin.
>
> The reason my Chebyshev preconditioner breaks is the (inverse) diagonal 
> vector I get from MatrixFree operator contains negative entries. 
> In my corresponding matrix-based code with exactly same geometry and 
> boundary condition, the matrix diagonal has no negaive entries.
>
> I apply a "compute_nonzero_tangential_flux_constraints_on_level" function 
> similar to the normal_flux one. The geometry of this problem is a shell. 
> When that BC is applied on outer boundary there's no negative entries, but 
> the error comes when applied on inner boundary. I'm still debugging to see 
> where the error comes from.
>
> I got a quesiton that do FEEvaluation auto deal with constraints? It seems 
> a matrixfree_operator.vmult solution 
> equals matrixbased_matrix.vmult + AffineConstraints.distribute.
>
> Best
> Wayne
>
> 在2023年2月14日星期二 UTC+8 15:33:18 写道：
>
>> To extend over what Wolfgang said, the most likely causes for failure 
>> with the Chebyshev preconditioner are:
>>
>> - the vector supplying the matrix diagonal (via the field 
>> AdditionalData::preconditioner) contains Inf or NaN entries, which in turn 
>> result from either a ill-formed differential operator or a bug in the code 
>> computing the diagonal, or
>>
>> - a coarse level holding only constrained degrees of freedom, which are 
>> not treated properly so that the SolverCG making an eigenvalue estimate 
>> needs to work with an unsolvable linear system (right hand side not in the 
>> image of the matrix).
>>
>> For the first case, you would check the diagonal on each level and the 
>> code leading to that, in the second the treatment of constraints.
>>
>> Best,
>> Martin
>> On 14.02.23 06:33, 'yy.wayne' via deal.II User Group wrote:
>>
>> Thank you Wolfgang. I didin't dive much into the Chebyshev preconditioner 
>> because I'm not familiar with it.  
>> I assume it's because the CG solver inside Chebyshev preconditioner 
>> didn't converge or what.
>> But as you stated, if NaN should only get from NaN elements and divided 
>> by zero, then I may find the error. 
>> I'll follow your debug suggestion.   
>>
>> Best
>> Wayne
>>
>> 在2023年2月14日星期二 UTC+8 12:48:42 写道：
>>
>>>
>>> > It's strange that the iteration breaks at step 0. If I try right 
>>> > preconditioning, it breaks at step 1 with nan. Besides, if there is 
>>> only on 
>>> > multigrid level, the problem is solved correctly with 1 iteration, so 
>>> matrices 
>>> > should be correct. The coarse solution is good enough for smoothing. 
>>> > 
>>> > The question is, in which case may a CG or GMRES solver breaks at step 
>>> 0 with nan? 
>>>
>>> NaN errors, like segmentation faults, are relatively easy to find 
>>> because you 
>>> know that every NaN you get is wrong. So you check that the matrix and 
>>> right 
>>> hand side and solution vector you give to the solver don't have any 
>>> NaNs. If 
>>> they don't, and you get NaNs out, then the problem likely lies with the 
>>> preconditioner, so you single step through the solver around the place 
>>> where 
>>> the preconditioner is applied and check in which operation the NaN 
>>> appears. 
>>>
>>> In your case, you seem to have already found out that it's the Chebyshev 
>>> preconditioner. The question is why. Is it because the matrix the 
>>> preconditioner uses has NaNs in it? Is it because the preconditioner 
>>> makes an 
>>> assumption that it can divide by certain matrix entries, but they are 
>>> zero? 
>>> Single stepping in a debugger will give you the answer :-) 
>>>
>>> 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