RE: [deal.II] Questions on Step-18

[Michael Li]

 Hi Jean-Paul, Thank you for your patience and detailed explanation! It did help me understand the formulations. The only thing after reading the Wikipedia (https://en.wikipedia.org/wiki/Rotation_matrix#Axis_and_angle ) I still have doubts is that the angle should be calculated by ½ mag(curl) and we do not need to do the atan operation. And I think the magnitude of curl has the dimension of radians which actually is dimensionless. Quoted from Wikipedia:“Near multiples of 180°, care is needed to avoid numerical problems: in extracting the angle, a two-argument arctangent with atan2(sin θ, cos θ) equal to θ avoids the insensitivity of arccos; and in computing the axis magnitude in order to force unit magnitude, a brute-force approach can lose accuracy through underflow .” My understanding on the atan above is that it is only used to deal with the case when the angle is near multiples of 180°. So the code I suggest will look like as follows.   const Point<3> curl = …;   const double mag_curl = std::sqrt(curl * curl);   const double  angle = 0.5 * mag_curl; Thank you!Michael  From: Jean-Paul PelteretSent: Monday, July 5, 2021 11:50 PMTo: dealii@googlegroups.comSubject: Re: [deal.II] Questions on Step-18 HI Michael, I’m not the original author of step-18, but I think that I’ve found some sources that can explain both the construction of the non-normalised rotation axis w and the angle θ calculation. 1. Axial vector ω (the non-normalised axis of rotation) For this, I’m summarising the salient parts of the references that I list later; specifically for following equations:  Chadwick1998a: p 29 eq. 71, the paragraph on p79 between equations 46 and 47Holzapfel2007a: p 17 eq. 1.118, p 18 eq. 1.124, p 49 eq. 1.276 The axial vector w is related to some skew symmetric tensor W in the following manner:W.u = ω x u  for any vector u. It can then be shown thatω = -1/2[ ε_{ijk} W_{ij} e_{k}  ]   = 1/2 curl(u) So how this factor comes into the calculation would be most easily understood by introducing an intermediate quantity, const Point<3> curl = …;const Tensor<1,3> axial_vector = 0.5*curl;const double tan_angle = std::sqrt(axial_vector * axial_vector);const double angle = std::atan(tan_angle); With some generalisation, this should hold in 2-d and 3-d (and addresses your one observation, that I comment on again in the next section).  @Book{Chadwick1998a,  title     = {Continuum Mechanics: Concise Theory and Problems},  publisher = {Dover Publications Inc.},  year      = {1998},  author    = {Chadwick, P.},  address   = {Mineola, New York, USA},  edition   = {2$^{\text{nd}}$},  isbn      = {9780486401805},  owner     = {Jean-Paul Pelteret},  timestamp = {2016.01.20},} @Book{Holzapfel2007a,  title     = {Nonlinear Solid Mechanics: A Continuum Approach for Engineering},  publisher = {John Wiley \& Sons Ltd.},  year      = {2007},  author    = {Holzapfel, G. A.},  address   = {West Sussex, England},  isbn      = {0-471-82304-X},  file      = {Holzapfel2007a.pdf:References/Books/Holzapfel2007a.pdf:PDF},  owner     = {Jean-Paul Pelteret},  timestamp = {2014.09.26},}  2. Angle from ω For the angle itself, I defer to this wikipedia entry. https://en.wikipedia.org/wiki/Rotation_matrix#Axis_and_angleThere you can see that the rotation angle θ is the arctangent of the norm of the non-normalised axis magnitude, |ω|. As for why there is the inverse trigonometric operation involved, this can be understood most easily by thinking about the units involved. The norm |ω| is dimensionless, and we’re needing an angle in radians — an inverse trigonometric function does this conversion. As to why its the arctan and not something else… maybe some of the references on that page have a proof for the formula that would then provide that insight.Moreover, for 2D, do we need to do the same as 3D   tan_angle = std::sqrt(curl * curl)? I mean we first calculate the magnitude of the curl then calculate the angle. I’m concerned about the sign of the curl in 2D angle = std::atan(curl) (we need the magnitude of the curl).I think that your observation in 2-d is correct. According to the wikipedia entry, one should likely always use the magnitude of the curl. I also think that the where the rotation matrix is returned via the call to   Rotations::rotation_matrix_<2,3>d(axis, -angle);   , we should be passing in the angle and not its negation. The axial vector ω supposedly encodes both the axis direction and “sign" of the rotation angle, and should be treated as a pair. That reference says that one should construct the rotation matrix from either (ω, θ) or (-ω, -θ), which would ultimately lead to the same result. Thanks for being inquisitive and for asking all of these questions. It looks like its lead to a better understanding (which we now use to improve the documentation of the tutorial), and might have uncovered a couple of bugs! Best,Jean-Paul On 3. Jul 2021, at 02:56, Michael Lee  wrote: Hi Jean-Paul and All, I would 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

Great, I’m glad to hear that! 

> So my last question is what is the difference between a flag being ON vs set 
> up with external dependencies ( which is what trilinos is set at now) 


When you set one of these flags to “ON”, you are demanding from CMake that this 
option be enabled and expect that the associated package must be set up 
correctly. Similarly, when the flag is set to “OFF” then the auto-detection for 
that package will be skipped (and, even if you tell deal.II where that library 
is by providing its path, it will ignore it anyway). When you leave flag this 
out altogether  you rely on the auto-detection mechanism to find the package 
and if it cannot be found (or there’s some detected compatibility issue) then 
you give CMake the leeway to disable and ignore this package. So, in summary, 
it just gives the granularity to say “Yes, I definitely want this dependency 
enabled” or “No, under all circumstances ignore this optional dependency” or 
“if you find it and it works, then I want this enabled".

When the package is said to be an "external dependency”, then it just means 
that the user or OS has provided said package. We bundle a few mandatory 
packages ourselves (e.g. the boost libraries), so that if the user hasn’t got 
them installed then we can fall back to these packages that are maintained 
within deal.II itself. 

> Will I be able to run those tutorials now? or is there still more work to be 
> done. 

For step-72 and step-33, I’d say yes
https://github.com/dealii/dealii/blob/master/examples/step-72/CMakeLists.txt#L40-L51
 

https://github.com/dealii/dealii/blob/master/examples/step-33/CMakeLists.txt#L43-L53
 


But to run step-71 you’ll also need to install SymEngine
https://github.com/dealii/dealii/blob/master/examples/step-71/CMakeLists.txt#L40-L54
 


I don’t think that there’s an Ubuntu package for that yet, but it’s not too 
hard to install by hand. You can take a look at their GitHub page for build 
instructions. At the bottom of the page there is their "Recommended options to 
build”, which you might want to take note of.
https://github.com/symengine/symengine 

Best,
Jean-Paul

> On 7. Jul 2021, at 20:49, Matthew Rich  wrote:
> 
> Thanks that worked! 
> 
> I needed to install the full trilinos-all-dev to get all the packages. I also 
> needed to install libptscotch-dev. 
> 
> So my last question is what is the difference between a flag being ON vs set 
> up with external dependencies ( which is what trilinos is set at now) 
> 
> Will I be able to run those tutorials now? or is there still more work to be 
> done. 
> 
> Thank you for all your help resolving this issue. 
> 
> 
> 
> On Wednesday, 7 July 2021 at 14:36:36 UTC-4 Jean-Paul Pelteret wrote:
> Hi again Matthew,
> 
> I’ve also found this build log for the Debian deal.II apt package
> https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0
>  
> 
> and you can see that in amongst all of the dependencies are listed the 
> "trilinos-all-dev” and " trilinos-dev” packages. They are meta-packages for 
> all of the development files for Trilinos 
> . I reckon that you 
> should install these packages, and then give it another try. 
> 
> Best,
> Jean-Paul
> 
> 
>> On 7. Jul 2021, at 20:15, Jean-Paul Pelteret > > wrote:
>> 
>> Hi Matthew,
>> 
>> If you look at either log file, then you’ll see that Trilinos was in fact 
>> not detected for some reason.
>> 
>>> DEAL_II_WITH_TRILINOS = OFF
>> 
>> 
>> I’m no longer experienced in building deal.II using apt packages, but it 
>> might be that you have to install the entire trilinos-dev to get all of the 
>> headers. Some of the modules that Trilinos provides are mandatory, and some 
>> like Sacado are optional. It could be that some of the other necessary 
>> headers aren’t there for the mandatory modules, and so the configure-time 
>> checks for core Trilinos packages cannot pass.
>> 
>> Try that, and if it fails then you can also add this
>> -DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
>>  to the cmake command to explicitly state that you want Trilinos enabled. 
>> Then if it doesn’t detect it CMake should emit an error and you’ll know for 
>> sure that there’s still something wrong. From these lines
>> https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
>>  
>> 
>> there should also be some messages that indicate exactly which modules it 
>> could not find.
>> 
>> I hope 

Re: [deal.II] New location for sacado.hpp

[Matthew Rich]

Thanks that worked! 

I needed to install the full trilinos-all-dev to get all the packages. I 
also needed to install libptscotch-dev. 

So my last question is what is the difference between a flag being ON vs 
set up with external dependencies ( which is what trilinos is set at now) 

Will I be able to run those tutorials now? or is there still more work to 
be done. 

Thank you for all your help resolving this issue. 



On Wednesday, 7 July 2021 at 14:36:36 UTC-4 Jean-Paul Pelteret wrote:

> Hi again Matthew,
>
> I’ve also found this build log for the Debian deal.II apt package
>
> https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0
> and you can see that in amongst all of the dependencies are listed the 
> "trilinos-all-dev” and " trilinos-dev” packages. They are meta-packages for 
> all 
> of the development files for Trilinos 
> . I reckon that you 
> should install these packages, and then give it another try. 
>
> Best,
> Jean-Paul
>
>
> On 7. Jul 2021, at 20:15, Jean-Paul Pelteret  wrote:
>
> Hi Matthew,
>
> If you look at either log file, then you’ll see that Trilinos was in fact 
> not detected for some reason.
>
> DEAL_II_WITH_TRILINOS = OFF
>
>
> I’m no longer experienced in building deal.II using apt packages, but it 
> might be that you have to install the entire trilinos-dev to get all of the 
> headers. Some of the modules that Trilinos provides are mandatory, and some 
> like Sacado are optional. It could be that some of the other necessary 
> headers aren’t there for the mandatory modules, and so the configure-time 
> checks for core Trilinos packages cannot pass.
>
> Try that, and if it fails then you can also add this
> -DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
>  to the cmake command to explicitly state that you want Trilinos enabled. 
> Then if it doesn’t detect it CMake should emit an error and you’ll know for 
> sure that there’s still something wrong. From these lines
>
> https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
> there should also be some messages that indicate exactly which modules it 
> could not find.
>
> I hope that this helps.
>
> Best,
> Jean-Paul
>
>
> On 7. Jul 2021, at 19:43, Matthew Rich  wrote:
>
> Hi 
>
> Thanks for the prompt reply.
>
> Yes I built deal.II from source but libtrilinos-sacado-dev was installed 
> via the debian package and apt (log files attached). I have all the headers 
> in my /usr/include/trilinos directory. Just skimming the summary file it 
> appears that deal.II did not detect sacado. Not sure why not though. 
>
> Thanks for the tip on the new tutorials. I will check them out once I get 
> this working. 
>
> Matt
>
> On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:
>
>> Hi Matthew,
>>
>> I don’t quite understand exactly how you installed deal.II and Trilinos. 
>> Perhaps you can provide some more explicit details so that we can help you 
>> out.
>>
>> * Is Trilinos installed using the apt package, and deal.II installed from 
>> source? If you built deal.II from source, may you please attach the build 
>> logs (summary.log and detailed.log) for us to look at.
>>
>> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
>> libtrilinos-sacado-dev), which should install the headers into a central 
>> location?
>>
>> * When you built deal.II, and it detects Trilinos and Sacado, the 
>> following two variable is defined in config.h (this is also output to the 
>> console during configuration):
>> $ cat include/deal.II/base/config.h | grep SACADO
>>   #define DEAL_II_TRILINOS_WITH_SACADO
>> Do you see it there? If not, then deal.II did not successfully detect 
>> Sacado during configuration, and does not support it. If you try to 
>> configure step-33, an error should be emitted that expresses this.
>>
>> When you #include  then the compiler first looks for this 
>> header in the default location for the system, which I think is  
>> /usr/include. 
>> If it doesn’t find it there then it looks in some other specific locations 
>> that deal.II (through the configured packages) suggests that it goes 
>> looking in.
>>
>> As a side note, there are two new tutorials (step-71 
>>  and step-72 
>> ) that 
>> cover the topic of auto-differentiation as well. You might want to consider 
>> looking at those before step-33. Step-33 uses Sacado at a low-level, and 
>> these two new tutorials introduce some wrappers that we’ve implemented 
>> inside the library that make using Sacado a bit more tractable.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On 7. Jul 2021, at 17:41, Matthew Rich  wrote:
>>
>> Hi all,
>>
>>  I am a bit confused on step-33 which uses the differentiation of sacado. 
>> I installed the latest version. 9.3 which has trilinios in it, and 
>> therefore 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi again Matthew,

I’ve also found this build log for the Debian deal.II apt package
https://buildd.debian.org/status/fetch.php?pkg=deal.ii=all=9.2.0-3=1606990185=0
 

and you can see that in amongst all of the dependencies are listed the 
"trilinos-all-dev” and " trilinos-dev” packages. They are meta-packages for all 
of the development files for Trilinos 
. I reckon that you should 
install these packages, and then give it another try. 

Best,
Jean-Paul


> On 7. Jul 2021, at 20:15, Jean-Paul Pelteret  wrote:
> 
> Hi Matthew,
> 
> If you look at either log file, then you’ll see that Trilinos was in fact not 
> detected for some reason.
> 
>> DEAL_II_WITH_TRILINOS = OFF
> 
> 
> I’m no longer experienced in building deal.II using apt packages, but it 
> might be that you have to install the entire trilinos-dev to get all of the 
> headers. Some of the modules that Trilinos provides are mandatory, and some 
> like Sacado are optional. It could be that some of the other necessary 
> headers aren’t there for the mandatory modules, and so the configure-time 
> checks for core Trilinos packages cannot pass.
> 
> Try that, and if it fails then you can also add this
> -DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
>  to the cmake command to explicitly state that you want Trilinos enabled. 
> Then if it doesn’t detect it CMake should emit an error and you’ll know for 
> sure that there’s still something wrong. From these lines
> https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
>  
> 
> there should also be some messages that indicate exactly which modules it 
> could not find.
> 
> I hope that this helps.
> 
> Best,
> Jean-Paul
> 
> 
>> On 7. Jul 2021, at 19:43, Matthew Rich > > wrote:
>> 
>> Hi 
>> 
>> Thanks for the prompt reply.
>> 
>> Yes I built deal.II from source but libtrilinos-sacado-dev was installed via 
>> the debian package and apt (log files attached). I have all the headers in 
>> my /usr/include/trilinos directory. Just skimming the summary file it 
>> appears that deal.II did not detect sacado. Not sure why not though. 
>> 
>> Thanks for the tip on the new tutorials. I will check them out once I get 
>> this working. 
>> 
>> Matt
>> 
>> On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:
>> Hi Matthew,
>> 
>> I don’t quite understand exactly how you installed deal.II and Trilinos. 
>> Perhaps you can provide some more explicit details so that we can help you 
>> out.
>> 
>> * Is Trilinos installed using the apt package, and deal.II installed from 
>> source? If you built deal.II from source, may you please attach the build 
>> logs (summary.log and detailed.log) for us to look at.
>> 
>> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
>> libtrilinos-sacado-dev), which should install the headers into a central 
>> location?
>> 
>> * When you built deal.II, and it detects Trilinos and Sacado, the following 
>> two variable is defined in config.h (this is also output to the console 
>> during configuration):
>> $ cat include/deal.II/base/config.h | grep SACADO
>>   #define DEAL_II_TRILINOS_WITH_SACADO
>> Do you see it there? If not, then deal.II did not successfully detect Sacado 
>> during configuration, and does not support it. If you try to configure 
>> step-33, an error should be emitted that expresses this.
>> 
>> When you #include  then the compiler first looks for this header 
>> in the default location for the system, which I think is  /usr/include. If 
>> it doesn’t find it there then it looks in some other specific locations that 
>> deal.II (through the configured packages) suggests that it goes looking in.
>> 
>> As a side note, there are two new tutorials (step-71 
>>  and step-72 
>> ) that cover 
>> the topic of auto-differentiation as well. You might want to consider 
>> looking at those before step-33. Step-33 uses Sacado at a low-level, and 
>> these two new tutorials introduce some wrappers that we’ve implemented 
>> inside the library that make using Sacado a bit more tractable.
>> 
>> Best,
>> Jean-Paul
>> 
>> 
>> 
>>> On 7. Jul 2021, at 17:41, Matthew Rich >> > wrote:
>>> 
>> 
>>> Hi all,
>>> 
>>>  I am a bit confused on step-33 which uses the differentiation of sacado. I 
>>> installed the latest version. 9.3 which has trilinios in it, and therefore 
>>> sacado. Browsing that directory I see other header files for the package 
>>> but not sacado.hpp
>>> 
>>> The tutorial has the line
>>> #include 
>>> 
>>> Was this file renamed or something? I am on Debian and I have installed the 
>>> trilinios through their 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

If you look at either log file, then you’ll see that Trilinos was in fact not 
detected for some reason.

> DEAL_II_WITH_TRILINOS = OFF


I’m no longer experienced in building deal.II using apt packages, but it might 
be that you have to install the entire trilinos-dev to get all of the headers. 
Some of the modules that Trilinos provides are mandatory, and some like Sacado 
are optional. It could be that some of the other necessary headers aren’t there 
for the mandatory modules, and so the configure-time checks for core Trilinos 
packages cannot pass.

Try that, and if it fails then you can also add this
-DDEAL_II_WITH_TRILINOS=ON -DTRILINOS_DIR=“/usr"
 to the cmake command to explicitly state that you want Trilinos enabled. Then 
if it doesn’t detect it CMake should emit an error and you’ll know for sure 
that there’s still something wrong. From these lines
https://github.com/dealii/dealii/blob/master/cmake/configure/configure_2_trilinos.cmake#L58-L68
 

there should also be some messages that indicate exactly which modules it could 
not find.

I hope that this helps.

Best,
Jean-Paul


> On 7. Jul 2021, at 19:43, Matthew Rich  wrote:
> 
> Hi 
> 
> Thanks for the prompt reply.
> 
> Yes I built deal.II from source but libtrilinos-sacado-dev was installed via 
> the debian package and apt (log files attached). I have all the headers in my 
> /usr/include/trilinos directory. Just skimming the summary file it appears 
> that deal.II did not detect sacado. Not sure why not though. 
> 
> Thanks for the tip on the new tutorials. I will check them out once I get 
> this working. 
> 
> Matt
> 
> On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:
> Hi Matthew,
> 
> I don’t quite understand exactly how you installed deal.II and Trilinos. 
> Perhaps you can provide some more explicit details so that we can help you 
> out.
> 
> * Is Trilinos installed using the apt package, and deal.II installed from 
> source? If you built deal.II from source, may you please attach the build 
> logs (summary.log and detailed.log) for us to look at.
> 
> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
> libtrilinos-sacado-dev), which should install the headers into a central 
> location?
> 
> * When you built deal.II, and it detects Trilinos and Sacado, the following 
> two variable is defined in config.h (this is also output to the console 
> during configuration):
> $ cat include/deal.II/base/config.h | grep SACADO
>   #define DEAL_II_TRILINOS_WITH_SACADO
> Do you see it there? If not, then deal.II did not successfully detect Sacado 
> during configuration, and does not support it. If you try to configure 
> step-33, an error should be emitted that expresses this.
> 
> When you #include  then the compiler first looks for this header 
> in the default location for the system, which I think is  /usr/include. If it 
> doesn’t find it there then it looks in some other specific locations that 
> deal.II (through the configured packages) suggests that it goes looking in.
> 
> As a side note, there are two new tutorials (step-71 
>  and step-72 
> ) that cover the 
> topic of auto-differentiation as well. You might want to consider looking at 
> those before step-33. Step-33 uses Sacado at a low-level, and these two new 
> tutorials introduce some wrappers that we’ve implemented inside the library 
> that make using Sacado a bit more tractable.
> 
> Best,
> Jean-Paul
> 
> 
> 
>> On 7. Jul 2021, at 17:41, Matthew Rich > > wrote:
>> 
> 
>> Hi all,
>> 
>>  I am a bit confused on step-33 which uses the differentiation of sacado. I 
>> installed the latest version. 9.3 which has trilinios in it, and therefore 
>> sacado. Browsing that directory I see other header files for the package but 
>> not sacado.hpp
>> 
>> The tutorial has the line
>> #include 
>> 
>> Was this file renamed or something? I am on Debian and I have installed the 
>> trilinios through their package, which does have the header file. However I 
>> cannot get the program to work properly.
>> 
>> I am looking for guidance on this issue of getting the right headers in the 
>> program so I can run this tutorial and others leveraging the sacado package.
>> 
>> Thanks in advance,
>> 
>> Maty
>> 
>> 
>> 
>> 
> 
>> -- 
>> 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 

Re: [deal.II] New location for sacado.hpp

[Matthew Rich]

So I tried running cmake again to get trilinos picked up. It does not seem 
to be detected. I even try supplying the directory 
with 

 cmake -/usr/local ./  -DTRILINOS_DIR=/usr/include/trilinos

But it still does not get detected. 

Should I build trilinos from source as well?  I attached another log where 
I pipe all cmake output to a file 

Matt




 discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAN3OR9oH-Za8weU3xHrMs5H86VeJffqtnrNxo_xh%3DddjMhc88g%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/8c05ab82-88eb-4812-9f9a-cd3deec83475n%40googlegroups.com.
-- This is CMake 3.13.4
-- 
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/setup_external_macros.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_add_flags.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_check_compiler_setup.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_check_cxx_compiler_bug.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_check_mpi_interface.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_clear_cmake_required.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_clear_feature.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_configure_feature.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_add_definitions.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_add_library.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_add_test.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_find_file.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_find_library.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_find_path.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_find_program.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_initialize_cached_variables.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_insource_setup_target.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_invoke_autopilot.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_package_handle.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_pickup_tests.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_query_git_information.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_deal_ii_setup_target.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_decorate_with_stars.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_enable_if_links.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_enable_if_supported.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_enable_language_optional.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_evaluate_expression.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_expand_instantiations.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_filter_system_libraries.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_find_package.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_find_system_library.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_item_matches.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_purge_feature.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_register_feature.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_remove_duplicates.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_replace_flag.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_reset_cmake_required.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_set_if_empty.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_setup_source_list.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_setup_unity_target.cmake
-- Include /home/mastermind/dealII/dealii-9.3.1/cmake/macros/macro_strip_flag.cmake
-- Include 

Re: [deal.II] New location for sacado.hpp

[Matthew Rich]

Hi 

Thanks for the prompt reply.

Yes I built deal.II from source but libtrilinos-sacado-dev was installed 
via the debian package and apt (log files attached). I have all the headers 
in my /usr/include/trilinos directory. Just skimming the summary file it 
appears that deal.II did not detect sacado. Not sure why not though. 

Thanks for the tip on the new tutorials. I will check them out once I get 
this working. 

Matt

On Wednesday, 7 July 2021 at 12:51:26 UTC-4 Jean-Paul Pelteret wrote:

> Hi Matthew,
>
> I don’t quite understand exactly how you installed deal.II and Trilinos. 
> Perhaps you can provide some more explicit details so that we can help you 
> out.
>
> * Is Trilinos installed using the apt package, and deal.II installed from 
> source? If you built deal.II from source, may you please attach the build 
> logs (summary.log and detailed.log) for us to look at.
>
> * Did you install the Trilinos development packages (e.g. trilinos-dev or 
> libtrilinos-sacado-dev), which should install the headers into a central 
> location?
>
> * When you built deal.II, and it detects Trilinos and Sacado, the 
> following two variable is defined in config.h (this is also output to the 
> console during configuration):
> $ cat include/deal.II/base/config.h | grep SACADO
>   #define DEAL_II_TRILINOS_WITH_SACADO
> Do you see it there? If not, then deal.II did not successfully detect 
> Sacado during configuration, and does not support it. If you try to 
> configure step-33, an error should be emitted that expresses this.
>
> When you #include  then the compiler first looks for this 
> header in the default location for the system, which I think is  
> /usr/include. 
> If it doesn’t find it there then it looks in some other specific locations 
> that deal.II (through the configured packages) suggests that it goes 
> looking in.
>
> As a side note, there are two new tutorials (step-71 
>  and step-72 
> ) that cover 
> the topic of auto-differentiation as well. You might want to consider 
> looking at those before step-33. Step-33 uses Sacado at a low-level, and 
> these two new tutorials introduce some wrappers that we’ve implemented 
> inside the library that make using Sacado a bit more tractable.
>
> Best,
> Jean-Paul
>
>
> On 7. Jul 2021, at 17:41, Matthew Rich  wrote:
>
> Hi all,
>
>  I am a bit confused on step-33 which uses the differentiation of sacado. 
> I installed the latest version. 9.3 which has trilinios in it, and 
> therefore sacado. Browsing that directory I see other header files for the 
> package but not sacado.hpp
>
> The tutorial has the line
> #include 
>
> Was this file renamed or something? I am on Debian and I have installed 
> the trilinios through their package, which does have the header file. 
> However I cannot get the program to work properly.
>
> I am looking for guidance on this issue of getting the right headers in 
> the program so I can run this tutorial and others leveraging the sacado 
> package.
>
> Thanks in advance,
>
> Maty
>
>
>
>
> -- 
> 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/CAN3OR9oH-Za8weU3xHrMs5H86VeJffqtnrNxo_xh%3DddjMhc88g%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/e81216d4-e6bd-4a66-9196-1cd5d40d436an%40googlegroups.com.
###
#
#  deal.II configuration:
#CMAKE_BUILD_TYPE:   DebugRelease
#BUILD_SHARED_LIBS:  ON
#CMAKE_INSTALL_PREFIX:   /usr/local/deal.II
#CMAKE_SOURCE_DIR:   /home/mastermind/dealII/dealii-9.3.1
#(version 9.3.1)
#CMAKE_BINARY_DIR:   /home/mastermind/dealII/dealii-9.3.1
#CMAKE_CXX_COMPILER: GNU 8.3.0 on platform Linux x86_64
#/usr/bin/c++
#C++ language standard:  C++14
#
#  Configured Features (DEAL_II_ALLOW_BUNDLED = ON, DEAL_II_ALLOW_AUTODETECTION = ON):
#  ( 

Re: [deal.II] New location for sacado.hpp

[Jean-Paul Pelteret]

Hi Matthew,

I don’t quite understand exactly how you installed deal.II and Trilinos. 
Perhaps you can provide some more explicit details so that we can help you out.

* Is Trilinos installed using the apt package, and deal.II installed from 
source? If you built deal.II from source, may you please attach the build logs 
(summary.log and detailed.log) for us to look at.

* Did you install the Trilinos development packages (e.g. trilinos-dev or 
libtrilinos-sacado-dev), which should install the headers into a central 
location?

* When you built deal.II, and it detects Trilinos and Sacado, the following two 
variable is defined in config.h (this is also output to the console during 
configuration):
$ cat include/deal.II/base/config.h | grep SACADO
  #define DEAL_II_TRILINOS_WITH_SACADO
Do you see it there? If not, then deal.II did not successfully detect Sacado 
during configuration, and does not support it. If you try to configure step-33, 
an error should be emitted that expresses this.

When you #include  then the compiler first looks for this header in 
the default location for the system, which I think is  /usr/include. If it 
doesn’t find it there then it looks in some other specific locations that 
deal.II (through the configured packages) suggests that it goes looking in.

As a side note, there are two new tutorials (step-71 
 and step-72 
) that cover the 
topic of auto-differentiation as well. You might want to consider looking at 
those before step-33. Step-33 uses Sacado at a low-level, and these two new 
tutorials introduce some wrappers that we’ve implemented inside the library 
that make using Sacado a bit more tractable.

Best,
Jean-Paul


> On 7. Jul 2021, at 17:41, Matthew Rich  wrote:
> 
> Hi all,
> 
>  I am a bit confused on step-33 which uses the differentiation of sacado. I 
> installed the latest version. 9.3 which has trilinios in it, and therefore 
> sacado. Browsing that directory I see other header files for the package but 
> not sacado.hpp
> 
> The tutorial has the line
> #include 
> 
> Was this file renamed or something? I am on Debian and I have installed the 
> trilinios through their package, which does have the header file. However I 
> cannot get the program to work properly.
> 
> I am looking for guidance on this issue of getting the right headers in the 
> program so I can run this tutorial and others leveraging the sacado package.
> 
> Thanks in advance,
> 
> Maty
> 
> 
> 
> 
> -- 
> 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/CAN3OR9oH-Za8weU3xHrMs5H86VeJffqtnrNxo_xh%3DddjMhc88g%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/C1F05D6B-DC3D-427B-B350-F0767A98B6B4%40gmail.com.

[deal.II] New location for sacado.hpp

[Matthew Rich]

Hi all,

 I am a bit confused on step-33 which uses the differentiation of sacado. I
installed the latest version. 9.3 which has trilinios in it, and therefore
sacado. Browsing that directory I see other header files for the package
but not sacado.hpp

The tutorial has the line
#include 

Was this file renamed or something? I am on Debian and I have installed the
trilinios through their package, which does have the header file. However I
cannot get the program to work properly.

I am looking for guidance on this issue of getting the right headers in the
program so I can run this tutorial and others leveraging the sacado package.

Thanks in advance,

Maty

-- 
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/CAN3OR9oH-Za8weU3xHrMs5H86VeJffqtnrNxo_xh%3DddjMhc88g%40mail.gmail.com.

Re: [deal.II] triangulation.signals.post_refinement :connection of a member function

[Simon Wiesheier]

I will look that up :-)

Just one last question:
In the constructed a class I store a DoFHandler and Triangulation object as
member variables like this:
SmartPointer> dof_handler;
SmartPointer> triangulation;

I created the instance at the same time when constructing the Solid
instance (pM = boost::make_shared<...>)
After a few loadsteps my solid triangulation changes and the DoFHandler as
well (standard adaptivity).
The instance of the other class where I stored the just mentioned
SmartPointers is "aware" of that, i.e. I don't update the SmartPointers
after adaptivity.
Of course the (smart)pointer stores the address of the triangulation, but
is it not possible that the the call "triangulation.execute_refinement()"
makes the triangulation object too big so that it has to be reallocated at
another adress (->address changes)?
So is that what I observe something like undefined behaviour or do calls
like "dof_handler.distribute_dofs(fe)" or
"triangulation.execute_refinement()" indeed don't change the address of the
underlying triangulation (dof_handler) in memory?

Thank you very much again!



Am Mi., 7. Juli 2021 um 06:35 Uhr schrieb Wolfgang Bangerth <
bange...@colostate.edu>:

> On 7/6/21 2:45 AM, Simon Wiesheier wrote:
> >
> > Is it also possible to get a reference (pointer) to the Solid object
> within
> > the constructor of 'AnotherClass', so without passing a solid reference
> to the
> > latters constructor? 'this' would in this case refer to the instance of
> > 'AnotherClass'.
> >
> > The class 'AnotherClass' needs access to objects of type DoFHandler
> and
> > CellDataStorage. As for the DoFHandler the copy
> instructor,
> > i.e something like 'dof_handler(dof_handler_from_solid)' will delete
> > 'dof_handler_from_solid'. It actually doesn't delete it but throws an
> > exception as it is also described in the documentation.
> > I checked a few source code files of the library how they manage the
> storage
> > of large objects, for instance the GridTools::Cache class stores a
> > triangulation like this:
> > SmartPointer>  tria;
> > So I did this in the same way for the DoFHandler and the CellDataStorage
> object:
> > SmartPointer> dof_handler;
> > ...
> > Is this a efficient way to do that or is there a more sophisticated way
> to
> > store the member variables? I asked myself why dealii did not just use
> the
> > SmartPointers of the c++ standard library, namely std::shared_ptr<...>,
> > std::unique_ptr<...>,  I guess most of them also make sure that they
> don't
> > become dangling pointers.
>
> All of this is possible with minimal pain by using "lambda functions" and
> "captured variables". You might want to read up on them in a recent C++
> book :-)
>
> Cheers
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to 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/0bad1924-dbba-c826-d91e-ed56c17767a6%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/CAM50jEuuDrsx0i6SFOw6fTUw3ByTVXLRvEyeJEiP2PX9iivMWQ%40mail.gmail.com.

[deal.II] Re: Solving an interface problem using matrix-free

['David Schneider' via deal.II User Group]

I can answer it myself after a bit of work, maybe there is someone 
wondering about similar things in the future:

> (1) will the SolverControl emit convergence although I operate only on 
some of the DoFs (do I need to reset the remaining ones)

Yes it will. Just reset the irrelevant DoFs and consider only the relevant 
here.

> (2) are there other options to achieve this (solving a problem on a  
subdomain such as an interface) using matrix-free

Not sure. However, project_boundary_values works only for serial 
Triangulations (there is actually an Assertion in deal.II missing). 
Reducing the overall system size to the size of the subdomain (as it is 
done for the serial version) while still considering the global coupling of 
distributed DoFs is exceedingly complicated. With matrix-free, I only touch 
the relevant DoFs when solving the system and I still have the DoF coupling 
and ghost value exchange as usual. The only 'price' I pay consists of the 
additional memory consumption for a global vector in the CGSolve, which is 
tolerable, or at least the best I can get.

> (3) do you think the approach makes sense or should I just go with the 
sparse matrix-vector approach since the overall system will be anyway 
relatively small (dim - 1)?

Makes sense. Choosing here sparse matrices is not a good idea as then I 
would have more unused memory allocated. Also, the (my selected) Jacobi 
preconditioner might become problematic for sparse matrices, if DoFs on the 
diagonal are ignored completely.


On Friday, 2 July 2021 at 19:02:09 UTC+2 David Schneider wrote:

> Hello all together,
>
> I'm currently working on a modified version of step-37 dealing with a 
> matrix-free implementation of a Laplace problem. As a postprocessing step, 
> I need to solve an interface problem: the function is essentially already 
> implemented in VectorTools::project_boundary_values() 
> .
>  
> However, I cannot use the default implementation in the library, because I 
> don't have a boundary function to project, but I have already a nodal 
> vector (the RHS) describing the boundary.
> Thus, I copied more or less the implementation of 
> 'VectorTools::project_boundary_values' into my program and this works out. 
> However, the implementation relies on a matrix-based approach and there are 
> lots of data structures I need to setup for this small and simple system. I 
> was wondering if I can re-use the MatrixFree object for this purpose, as it 
> has already all the preconditioners and operators implemented. 
>
> The idea would be to pass a global vector into the cg.solve() function and 
> (instead of looping over all cells) looping over all boundary cells and 
> only perform operations on the desired faces belonging to the relevant 
> interface. There are mainly three questions I was wondering about: (1) will 
> the SolverControl emit convergence although I operate only on some of the 
> DoFs (do I need to reset the remaining ones) ? (2) are there other options 
> to achieve this (solving a problem on a  subdomain such as an interface) 
> using matrix-free (3) do you think the approach makes sense or should I 
> just go with the sparse matrix-vector approach since the overall system 
> will be anyway relatively small (dim - 1)?
>
> Thanks in advance and kind regards,
> David
>

-- 
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/501bbd46-84e2-49bb-8287-a77dab7883a5n%40googlegroups.com.

[deal.II] Unexpected data output with cell data vector

[vachanpo...@gmail.com]

Dear all,

I am having some confusion regarding the index used in DataOut for a cell 
vector.

I have created a distributed vector for storing cell data using 
p::d::Triangulation::global_active_cell_index_partitioner() 
.
 
I am accessing the elements using cell->global_active_cell_index() 

.

LA::MPI::Vector vec(partitioner->locally_owned_range(), mpi_comm); // cell 
vector
LA::MPI::Vector gh_vec(
  partitioner->locally_owned_range(),
  partitioner->ghost_indices(),
  mpi_comm
); // ghosted cell vector

I want to visualise this vector so was adding this to DataOut like so:
// do some computations
// write data
Vector temp_vec(gh_vec); // for data output
data_out.add_data_vector(temp_vec, "vector");

However, seeing the result, it looks like there is some mismatch of indices 
happening. The vector shows wrong values at wrong places. If I instead do

Vector temp_vec(gh_vec); // for data output
for(auto : dof_handler.active_cell_iterators()){
  if(!(cell->is_locally_owned())) continue;
  temp_vec[cell->index()] = gh_vec[cell->global_active_cell_index()];
}
data_out.add_data_vector(temp_vec, "vector");

... then the output looks as expected. So here I have manually set the 
entries of the temporary vector using cell->index(), rather than letting 
the constructor do the job. For 1d meshes both seem to produce the same 
output.

What is the correct procedure? What kind of cell index does DataOut use 
internally? Any clarification would be greatly appreciated!

Thanking in anticipation
Vachan

-- 
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/34324c0d-bdff-4fdd-8265-f0a09c409923n%40googlegroups.com.