[deal.II] open PhD position

[Alberto Salvadori]

Dear community

a fully funded, three years long PhD position is available at the m4lab at 
the University of Brescia (https://m4lab.unibs.it), under the supervision 
of Prof. A. Salvadori. The candidate will collaborate in the development of 
deal.ii - based FEM codes for modeling thermo-chemo-mechanics of batteries, 
Lithium and Sodium based.

Interested students are kindly asked to submit a CV by email at

alberto.salvadori AT unibs.it

at their earliest convenience. 
Warm regards,

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/27ec139f-2499-44bd-9946-35c496a21e39n%40googlegroups.com.

[deal.II] candi installation issue

[Alberto Salvadori]

Dear community

while installing deal.ii on a new machine with candi I got this message.
















*candi tries now to download, configure, build and install:Project: 
 deal.II-toolchainPlatform: 
deal.II-toolchain/platforms/supported/ubuntu.platformLoading 
dealii-prepareFetching opencascade 0.18.3Trying to download 
https://tjhei.info/candi-mirror/OCE-0.18.3.tar.gz--2023-10-30 17:31:59-- 
 https://tjhei.info/candi-mirror/OCE-0.18.3.tar.gzResolving tjhei.info 
(tjhei.info)... 45.63.8.119Connecting to tjhei.info 
(tjhei.info)|45.63.8.119|:443... connected.WARNING: cannot verify 
tjhei.info's certificate, issued by 
‘CN=_default,OU=Dev,O=GridPane,L=Bath,ST=Michigan,C=US’:  Self-signed 
certificate encountered.WARNING: certificate common name ‘_default’ 
doesn't match requested host name ‘tjhei.info’.HTTP request sent, awaiting 
response... Read error (Connection reset by peer) in headers.Retrying.*

Am I missing something? I did try on two different systems with the same 
outcome.
Thank you,

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/d53ae7c0-7ae3-4af0-8e10-81a20e385cfdn%40googlegroups.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
> <https://groups.google.com/d/msgid/dealii/4074cb43-9656-476b-ad5e-9b34fc73dc32n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 


Informativa sulla Privacy: https://www.unibs.it/it/node/1452 
<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] SEGMENTATION FAULT(CORE DUMPED)

[Alberto SALVADORI]

Erkin

as far as I understand, your problem is not in compilation. In fact, you
seamlessly compiled step-1 and step-2, both in debug and release mode.
Your "segmentation fault" issue arises in running the executable file from
the command line.
That said, I have no idea on what is causing the issue. Perhaps someone in
the community has had similar problems and can address us.

dealii-candi 9.4.0 was compiled with gcc 13.3.0

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 Fri, Nov 11, 2022 at 5:21 PM erkin yildiz  wrote:

> Dear everyone,
>
> My name is Erkin Yildiz. I am PhD student at University of Brescia. The
> deal.ii has been installed with candi inside of my computer. I am going to
> share the problem that I have deal with it. After the everything when I
> want to compile the system by using IDE it gives me error which is called
> segmentation faul (core dumped).
>
> What does it mean? I am going to share also the properities of the
> computer.
>
> Best regards,
> Erkin
>
>
> 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/CAP3xP0raSGJCG8Z72JSZ1QMSx_hUDyHS-c9tF6wHFXQ_Pc-ePg%40mail.gmail.com
> <https://groups.google.com/d/msgid/dealii/CAP3xP0raSGJCG8Z72JSZ1QMSx_hUDyHS-c9tF6wHFXQ_Pc-ePg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 


Informativa sulla Privacy: https://www.unibs.it/it/node/1452 
<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/CABcATpcRX%3DcpmYHESg0Hrda1FeAsofvS6RAcONNdcwj%3DVLLHXA%40mail.gmail.com.

[deal.II] Re: dealii-9.4.0 release candidate 1

[Alberto Salvadori]

Matthias,

I wonder if this release is  fully compatible with Apple M1 (and M2 as 
well) or not. 
Thank you,

Alberto

Il giorno giovedì 16 giugno 2022 alle 23:04:32 UTC+2 Matthias Maier ha 
scritto:

> Dear all,
>
> We have tagged a first release candidate for the upcoming deal.II 9.4.0 
> release.
> You can find the sources and a generated offline documentation here:
>
> https://github.com/dealii/dealii/releases/tag/v9.4.0-rc1
>
> Alternatively, you can switch to the dealii-9.4 branch in your local git 
> repository
>
> git remote update
> git checkout v9.4.0-rc1
>
> It would be great if you could test it on your machine with your typical 
> configuration!
> If no further regressions show up, we will release Friday June 24. The 
> release
> progress is tracked in the following GitHub issue:
>
> https://github.com/dealii/dealii/issues/13574
>
> Thanks!
>
> Matthias
> on behalf of the deal.II developer team
>

-- 


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/78c18263-d006-4bc2-a6df-6b7681a90ef6n%40googlegroups.com.

[deal.II] Re: Affine constraints distribute_local_to_global

[Alberto Salvadori]

Dear community,

I have found a way to implement the case of multiple constraints that was 
mentioned in my previous discussion. I am sharing it here, in case of use.
Basically, it seems to me that all affine constraints should be merged 
before constructing the sparsity pattern. Differently than before, I build 
the affine constraint m_interfaces_constraints
as








*for (auto tie_table_ii : tie_table ){   if ( tie_table_ii.first < 
tie_table_ii.second )  { m_interfaces_constraints.add_line( 
tie_table_ii.first ); m_interfaces_constraints.add_entry( 
tie_table_ii.first, tie_table_ii.second, 1 );   }}*

and then I merged it with the hanging_node_constraints


*this->hanging_node_constraints.merge( this->m_interfaces_constraints );*

from that point on, nothing changes, 

*this->hanging_node_constraints.distribute_local_to_global(cell_matrix, 
cell_rhs,*
*  
local_dof_indices,*
*  
this->system_matrix, this->system_rhs);*

is all I need. It works, but I did not make any test on mesh refinement so 
far.
Thanks!

In developing those ideas, I found the .print method of AffineConstraints 
particularly useful.

Alberto

Il giorno martedì 10 agosto 2021 alle 06:52:40 UTC+2 Alberto Salvadori ha 
scritto:

> Dear community
>
> I am asking your help today about imposing affine constraints. I 
> understood well example 6, but when it comes to apply it to sparse MPI 
> matrices I get lost. I am not sure if example 27 is of help for my case.
>
> What would I like to simulate? Take two separate domains, with conformal 
> meshes. I want to impose that two sets of nodes share the same solution, 
> i.e. the solution field is continuous. To this aim, the dofs to be tied 
> have been collected in a set of pairs (which has been verified, it is OK). 
> Hence, say the set is named tie_table, the dof tie_table.first shall be 
> equal to tie_table.second .
>
> So far so good, but from now on it blurs to me. I figured out that I shall 
> build the affine constraint (say it is named m_interfaces_constraints) and 
> update the sparsity pattern (say it is named dsp). 
>
> The dsp has been created after the hanging node constraints
>   
>   DoFTools::make_flux_sparsity_pattern( this->dof_handler,
>dip,
>this->hanging_node_constraints,
>/*keep constrained dofs*/ false);
>
> and it has been updated afterwards like that:
>
>   for (auto tie_table_ii : tie_table )
> {
>
> if ( tie_table_ii.first < tie_table_ii.second )
>
> // we shall make sure not to impose a tie twice ...
> 
>   {
> dsp->add( tie_table_ii.first, tie_table_ii.second  ) ;
> dsp->add( tie_table_ii.second, tie_table_ii.first  ) ;
> m_interfaces_constraints.add_line( tie_table_ii.first );
> m_interfaces_constraints.add_entry( tie_table_ii.first, 
> tie_table_ii.second, 1 );
>   }
> }
>
>   m_interfaces_constraints.close();
>
>
> Is the above reasonable to build the m_interfaces_constraints? Am I 
> missing something? At this point how shall I proceed in distributing the 
> cell matrix into the system matrix in the assembly phase? The following 
> code does not seem to work.
>
>   ... make entries in cell_matrix, cell_rhs ...
> cell->get_dof_indices (local_dof_indices);
> 
> this->hanging_node_constraints.distribute_local_to_global(cell_matrix, 
> cell_rhs,
>   
> local_dof_indices,
>   
> this->system_matrix, this->system_rhs);
> 
> this->m_interfaces_constraints.distribute_local_to_global(cell_matrix, 
> cell_rhs,
> 
>  local_dof_indices,
> 
>  this->system_matrix, this->system_rhs);
>
> specifically, the instruction 
> this->m_interfaces_constraints.distribute_local_to_global generates the 
> following error:
>
>
> 
> An error occurred in line <1683> of file 
> 
>  
> in function
> void dealii::TrilinosWrappers::SparseMatrix::add(const 
> dealii::TrilinosWrappers::SparseMatrix::size_type, const 
> dealii::TrilinosWrappers::SparseMatrix::size_type, const 
> dealii::TrilinosWrappers::SparseMatrix::size_type *, const 
> dealii::

[deal.II] Affine constraints distribute_local_to_global

[Alberto Salvadori]

Dear community

I am asking your help today about imposing affine constraints. I understood 
well example 6, but when it comes to apply it to sparse MPI matrices I get 
lost. I am not sure if example 27 is of help for my case.

What would I like to simulate? Take two separate domains, with conformal 
meshes. I want to impose that two sets of nodes share the same solution, 
i.e. the solution field is continuous. To this aim, the dofs to be tied 
have been collected in a set of pairs (which has been verified, it is OK). 
Hence, say the set is named tie_table, the dof tie_table.first shall be 
equal to tie_table.second .

So far so good, but from now on it blurs to me. I figured out that I shall 
build the affine constraint (say it is named m_interfaces_constraints) and 
update the sparsity pattern (say it is named dsp). 

The dsp has been created after the hanging node constraints
  
  DoFTools::make_flux_sparsity_pattern( this->dof_handler,
   dip,
   this->hanging_node_constraints,
   /*keep constrained dofs*/ false);

and it has been updated afterwards like that:

  for (auto tie_table_ii : tie_table )
{

if ( tie_table_ii.first < tie_table_ii.second )

// we shall make sure not to impose a tie twice ...

  {
dsp->add( tie_table_ii.first, tie_table_ii.second  ) ;
dsp->add( tie_table_ii.second, tie_table_ii.first  ) ;
m_interfaces_constraints.add_line( tie_table_ii.first );
m_interfaces_constraints.add_entry( tie_table_ii.first, 
tie_table_ii.second, 1 );
  }
}

  m_interfaces_constraints.close();


Is the above reasonable to build the m_interfaces_constraints? Am I missing 
something? At this point how shall I proceed in distributing the cell 
matrix into the system matrix in the assembly phase? The following code 
does not seem to work.

  ... make entries in cell_matrix, cell_rhs ...
cell->get_dof_indices (local_dof_indices);

this->hanging_node_constraints.distribute_local_to_global(cell_matrix, 
cell_rhs,
  
local_dof_indices,
  
this->system_matrix, this->system_rhs);

this->m_interfaces_constraints.distribute_local_to_global(cell_matrix, 
cell_rhs,

 local_dof_indices,

 this->system_matrix, this->system_rhs);

specifically, the instruction 
this->m_interfaces_constraints.distribute_local_to_global generates the 
following error:



An error occurred in line <1683> of file 

 
in function
void dealii::TrilinosWrappers::SparseMatrix::add(const 
dealii::TrilinosWrappers::SparseMatrix::size_type, const 
dealii::TrilinosWrappers::SparseMatrix::size_type, const 
dealii::TrilinosWrappers::SparseMatrix::size_type *, const 
dealii::TrilinosScalar *, const bool, const bool)
The violated condition was: 
ierr == 0
Additional information: 
An error with error number 2 occurred while calling a Trilinos function


Finally, shall I call this function? What does it do?

  m_interfaces_constraints.condense(*dsp);

I appreciate your help, very much.

Alberto





-- 


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/ae36b1dd-a214-4f1b-ad38-086e9c5fb8dan%40googlegroups.com.

Re: [deal.II] errors in running step-18 within Xcode

[Alberto Salvadori]

Hi Luca,
thanks for clarifying. Still not succeeded, see below.

1. opened a Rosetta terminal
2. source /Applications/deal.II.app/Contents/MacOS/dealii.conf

  __   _  _ _

|  _  \ | ||_   _|_   _|

| | | |___  __ _| |  | |   | |

| | | / _ \/ _| | |  | |   | |

| |/ /  __/ (_| | |__| |_ _| |_

|___/ \___|\__,_|_(_)___/ \___/


This is a bash shell with CMAKE_PREFIX_PATH and DYLD_LIBRARY_PATH set to
work

with Deal.II. A full spack installation with deal.II is available under


/Applications/deal.II.app/Contents/Resources/spack


If you want to set up your daily Terminal to work with deal.II, add these
lines

to your ~/.profile (or ~/.zshrc, if you prefer zsh):


   export DEAL_II_CONF_SILENT=ON# Turn off this message

   . /Applications/deal.II.app/Contents/MacOS/dealii.conf


deal.II and all its dependencies were installed using spack, and are also

available through spack, e.g.:


spack find # Shows all installed packages


You can find the deal.II examples directory under



  /Applications/deal.II.app/Contents/Resources/Libraries/share/deal.II/examples




3. cmake -G 'Unix Makefiles'
4. make release
5. make

[ 50%] Building CXX object CMakeFiles/step-18.dir/step-18.cc.o

[100%] *Linking CXX executable step-18*

[100%] Built target step-18

albertosalvadori@uu-guest-150-117 step-18 unix % ./step-18

zsh: illegal hardware instruction  ./step-18

albertosalvadori@uu-guest-150-117 step-18 unix % which cmake

/Applications/deal.II.app/Contents/Resources/Libraries/bin/cmake

albertosalvadori@uu-guest-150-117 step-18 unix %




*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, Aug 3, 2021 at 1:34 PM Luca Heltai  wrote:

> Actually, not exactly. The instructions are i the screen shot.
>
> Open a Rosetta terminal, and then source the conf file, i.e.
>
> ./Appl/dealii.conf
>
> The command you called opens a normal terminal, and then sources the conf
> file.
>
> Luca
>
> Il giorno 3 ago 2021, alle ore 13:28, Alberto Salvadori <
> alberto.salvad...@unibs.it> ha scritto:
>
> 
> Luca,
> this is what I have done, if I got what you meant:
>
> 1. opened a Rosetta terminal
> 2. /Applications/deal.II.app/Contents/MacOS/dealii-terminal
>
>   __   _  _ _
>
> |  _  \ | ||_   _|_   _|
>
> | | | |___  __ _| |  | |   | |
>
> | | | / _ \/ _| | |  | |   | |
>
> | |/ /  __/ (_| | |__| |_ _| |_
>
> |___/ \___|\__,_|_(_)___/ \___/
>
>
> This is a bash shell with CMAKE_PREFIX_PATH and DYLD_LIBRARY_PATH set to
> work
>
> with Deal.II. A full spack installation with deal.II is available under
>
>
> /Applications/deal.II.app/Contents/Resources/spack
>
>
> If you want to set up your daily Terminal to work with deal.II, add these
> lines
>
> to your ~/.profile (or ~/.zshrc, if you prefer zsh):
>
>
>export DEAL_II_CONF_SILENT=ON# Turn off this message
>
>. /Applications/deal.II.app/Contents/MacOS/dealii.conf
>
>
> deal.II and all its dependencies were installed using spack, and are also
>
> available through spack, e.g.:
>
>
> spack find # Shows all installed packages
>
>
> You can find the deal.II examples directory under
>
>
>
> /Applications/deal.II.app/Contents/Resources/Libraries/share/deal.II/examples
>
>
>
>
> 3. cmake -G 'Unix Makefiles'
> 4. make release
> 5. make
> 6.  ./step-18
>
> Illegal instruction: 4
>
>
>
>
>
>
> *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, Aug 3, 2021 at 1:10 PM Luca Heltai  wrote:
>
>> Can you open a Rosetta terminal and follow the instructions to parse
>> deal.ii init files? I think it is just the fact that you are not running
>> under Rosetta, but cannot confirm...
>>
>> Luca
>>
>> Il giorno 3 ago 2021, alle ore 11:28, Alberto Salvadori <
>> alberto.salvad...@unibs.it> ha scritto:
>>
>> Dear community
>>
>> I successfully installed 9.3 on my mac M1 from the dmg . However, I am at
>> present unable to run examples, as for the step-18. For this reason, I
>> share my attempts.
>> I am using Xcode 12.5.1 (12E507) on BigSur 11.2.3 (20D91).
>>
>> After opening a deal.ii terminal from 

Re: [deal.II] errors in running step-18 within Xcode

[Alberto Salvadori]

Luca,
this is what I have done, if I got what you meant:

1. opened a Rosetta terminal
2. /Applications/deal.II.app/Contents/MacOS/dealii-terminal

  __   _  _ _

|  _  \ | ||_   _|_   _|

| | | |___  __ _| |  | |   | |

| | | / _ \/ _| | |  | |   | |

| |/ /  __/ (_| | |__| |_ _| |_

|___/ \___|\__,_|_(_)___/ \___/


This is a bash shell with CMAKE_PREFIX_PATH and DYLD_LIBRARY_PATH set to
work

with Deal.II. A full spack installation with deal.II is available under


/Applications/deal.II.app/Contents/Resources/spack


If you want to set up your daily Terminal to work with deal.II, add these
lines

to your ~/.profile (or ~/.zshrc, if you prefer zsh):


   export DEAL_II_CONF_SILENT=ON# Turn off this message

   . /Applications/deal.II.app/Contents/MacOS/dealii.conf


deal.II and all its dependencies were installed using spack, and are also

available through spack, e.g.:


spack find # Shows all installed packages


You can find the deal.II examples directory under



/Applications/deal.II.app/Contents/Resources/Libraries/share/deal.II/examples




3. cmake -G 'Unix Makefiles'
4. make release
5. make
6.  ./step-18

Illegal instruction: 4






*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, Aug 3, 2021 at 1:10 PM Luca Heltai  wrote:

> Can you open a Rosetta terminal and follow the instructions to parse
> deal.ii init files? I think it is just the fact that you are not running
> under Rosetta, but cannot confirm...
>
> Luca
>
> Il giorno 3 ago 2021, alle ore 11:28, Alberto Salvadori <
> alberto.salvad...@unibs.it> ha scritto:
>
> Dear community
>
> I successfully installed 9.3 on my mac M1 from the dmg . However, I am at
> present unable to run examples, as for the step-18. For this reason, I
> share my attempts.
> I am using Xcode 12.5.1 (12E507) on BigSur 11.2.3 (20D91).
>
> After opening a deal.ii terminal from deal.ii.app, the step-18 code
> compiles well both inside Xcode and from Makefile. When it comes to run the
> executable, neither of the two apparently work. The output message from
> terminal is
>
> bash-3.2$ ./step-18
>
> Illegal instruction: 4
>
> whereas the debugger provides some further notifications, as in figure,
> which I am not able to discern.
>
> 
>
>
> I had at my disposal a former installation of deal.ii.9.2, that I made
> with spack and gcc in a rosetta terminal. In such a case, within a rosetta
> terminal, the step-18 compiles and runs well. Note that deal.ii9.3 does not
> open a rosetta terminal.
>
> Hope these evidences can be of help.
>
> Best and thanks, as always!
>
> Alberto
>
>
> 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/9014a8cd-0df9-499d-8aa0-d1b0a3427cfcn%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/9014a8cd-0df9-499d-8aa0-d1b0a3427cfcn%40googlegroups.com?utm_medium=email&utm_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/F3E122B8-F84B-406D-BC55-37144F3E6607%40gmail.com
> <https://groups.google.com/d/msgid/dealii/F3E122B8-F84B-406D-BC55-37144F3E6607%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpeRgfNDPcTh9u-bSTL-uhik_W9o9N%2BJsNE7fkaWkQuUxg%40mail.gmail.com.

Re: [deal.II] Re: issue in installing dealii 9.2 and .3 on centos

[Alberto Salvadori]

Hi Bruno and Luca,
I finally made it. Here is what I did:

spack install gmsh@4.8.4%gcc@7.4.0~med+tetgen+oce


less ~/.spack/linux/packages.yaml

packages:

  all:

compiler: [gcc@7.4.0]

  flex:

version: [2.6.4]

buildable: false

  gmsh:

version: [4.8.4]

buildable: false


externals:

- prefix:
/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/flex-2.6.4-qqacz2f6twfpyotvlzqgtktpmcdn5cni

  spec: flex@2.6.4%gcc@7.4.0

- prefix:
/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/gmsh-4.8.4-476qnx2qlzhfboru3b6cn5sw4auxjtkp

  spec: gmsh@4.8.4%gcc@7.4.0~med+tetgen+oce



spack install dealii%gcc@7.4.0




Thank you for your help.
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 Fri, Jul 30, 2021 at 5:14 PM Bruno Turcksin 
wrote:

> Alberto,
>
> If the question is "can dealii read a gmsh file without gmsh support ?"
> the answer is yes. The gmsh support is for deal.II to use gmsh internally
> not to read a gmsh file.
>
> Best,
>
> Bruno
>
> On Friday, July 30, 2021 at 11:09:28 AM UTC-4 Alberto Salvadori wrote:
>
>> Bruno,
>>
>> I do import gmsh triangulations in dealii simulations. Would this be
>> possible without including gmsh ?
>>
>> 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@unibs.it
>> web-page:
>>  http://m4lab.unibs.it/faculty.html
>>
>>
>> On Fri, Jul 30, 2021 at 5:01 PM Bruno Turcksin 
>> wrote:
>>
>>> Alberto,
>>>
>>> My experience with spack is to use a release version instead of the
>>> development version. They are too many moving parts in spack to expect the
>>> development version to be stable. My first question is do you need gmsh
>>> support in deal.II? If not you can just do spack install dealii~gmsh. If
>>> you need gmsh, can you try spack spec dealii^gmsh~med to check that spack
>>> can concretize the package.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> On Friday, July 30, 2021 at 10:39:13 AM UTC-4 Alberto Salvadori wrote:
>>>
>>>> Thank you, Bruno.
>>>> It looks like gmsh is the package which requires med:
>>>>
>>>> 
>>>> ^gm...@4.8.4%g...@7.4.0+alglib~cairo+cgns+compression~eigen~external+fltk+gmp~hdf5~ipo+med+metis+mmg~mpi+netgen+oce~opencascade~openmp~petsc~privateapi+shared~slepc+tetgen+voropp
>>>> build_type=RelWithDebInfo arch=linux-centos7-broadwell
>>>>
>>>> I am using
>>>>
>>>> [asalvado@r000u07l02 uBS21_CivSal_0]$ spack --version
>>>>
>>>> 0.16.2-3715-a904418
>>>>
>>>> Your help is appreciated.
>>>> 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@unibs.it
>>>> web-page:
>>>>  http://m4lab.unibs.it/faculty.html
>>>>
>>>>
>>>>
>>>> On Fri, Jul 30, 2021 at 4:12 PM Bruno Turcksin 
>>>> wrote:
>>>>
>>>>> Alberto,
>>>>>
>>>>> I have no clue what med is, so it's not a basic dependency of deal.II.
>>>>> Which version of spack are you using? I don't see a dependency on med when
>>>>> I do `spack speck dealii` You can tell spack not to install med but you
>>>>> need to know which package pulled it.
>>>>>
>>>>> Best,
>>>>>
>>>>> Bruno
>>>>>
>>>>> On Friday, July 30, 2021 at 8:48:04 AM UTC-4 Alberto Salvadori wrote:
>>>>>
>>>>>> Dear community
>>>>>>
>>>>>> while installing deal.ii on a centos cluster, I am facing the
>>>>>> following issue related to med :
>>>>>>
>>>>>> *==>* *Installing* *med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf*
>>>>>>
>>>>>> *==>

Re: [deal.II] Re: issue in installing dealii 9.2 and .3 on centos

[Alberto Salvadori]

[asalvado@r000u07l02 uBS21_CivSal_0]$ spack spec dealii^gmsh~med

Input spec



dealii

^gmsh~med


Concretized



*==>* Error: An unsatisfiable variant constraint has been detected for spec:



gmsh@4.8.4%gcc@7.4.0+alglib~cairo+cgns+compression~eigen~external+fltk+gmp~hdf5~ipo+med+metis+mmg~mpi+netgen~oce~opencascade~openmp~petsc~privateapi+shared~slepc~tetgen+voropp
build_type=RelWithDebInfo arch=linux-centos7-broadwell



while trying to concretize the partial spec:



dealii@9.3.0%gcc@7.4.0+adol-c+arborx+arpack+assimp~cuda~doc+examples+ginkgo+gmsh+gsl+hdf5~int64~ipo+metis+mpi+muparser~nanoflann~netcdf+oce~optflags+p4est+petsc~python+scalapack+simplex+slepc+sundials+symengine+threads+trilinos
build_type=DebugRelease cuda_arch=none cxxstd=default
arch=linux-centos7-broadwell

^arborx@1.0%gcc@7.4.0~cuda~ipo+mpi~openmp~rocm+serial+trilinos
build_type=RelWithDebInfo arch=linux-centos7-broadwell

^cmake@3.20.5%gcc@7.4.0~doc+ncurses+openssl+ownlibs~qt
build_type=Release arch=linux-centos7-broadwell

^ncurses@6.2%gcc@7.4.0~symlinks+termlib abi=none
arch=linux-centos7-broadwell

^pkgconf@1.7.4%gcc@7.4.0 arch=linux-centos7-broadwell

^openssl@1.1.1k%gcc@7.4.0~docs+systemcerts
arch=linux-centos7-broadwell

^perl@5.34.0%gcc@7.4.0+cpanm+shared+threads
arch=linux-centos7-broadwell

^berkeley-db@18.1.40%gcc@7.4.0+cxx~docs+stl
arch=linux-centos7-broadwell

^bzip2@1.0.8%gcc@7.4.0~debug~pic+shared
arch=linux-centos7-broadwell

^diffutils@3.7%gcc@7.4.0
arch=linux-centos7-broadwell

^libiconv@1.16%gcc@7.4.0
arch=linux-centos7-broadwell

^gdbm@1.19%gcc@7.4.0 arch=linux-centos7-broadwell

^readline@8.1%gcc@7.4.0
arch=linux-centos7-broadwell

^zlib@1.2.11%gcc@7.4.0+optimize+pic+shared
arch=linux-centos7-broadwell


^openmpi@4.1.1%gcc@7.4.0~atomics~cuda~cxx~cxx_exceptions+gpfs~internal-hwloc~java~legacylaunchers~lustre~memchecker~pmi~singularity~sqlite3+static~thread_multiple+vt+wrapper-rpath
fabrics=none schedulers=none arch=linux-centos7-broadwell

^hwloc@2:

^libevent@2.0:

^numactl@2.0.14%gcc@7.4.0 arch=linux-centos7-broadwell

^autoconf@2.69%gcc@7.4.0 arch=linux-centos7-broadwell

^m4@1.4.19%gcc@7.4.0+sigsegv
arch=linux-centos7-broadwell

^libsigsegv

^automake@1.16.3%gcc@7.4.0 arch=linux-centos7-broadwell

^libtool@2.4.6%gcc@7.4.0 arch=linux-centos7-broadwell

^openssh

^libedit


^trilinos@13.0.1%gcc@7.4.0~adios2+amesos+amesos2+anasazi+aztec~basker+belos~boost~cgns~chaco~complex~cuda~cuda_rdc~debug~dtk+epetra+epetraext~epetraextbtf~epetraextexperimental~epetraextgraphreorderings~exodus+explicit_template_instantiation~float+fortran~hdf5~hypre+ifpack+ifpack2~intrepid~intrepid2~ipo~isorropia+kokkos~matio~mesquite~minitensor+ml+mpi+muelu~mumps~netcdf~nox~openmp~phalanx~piro~pnetcdf~python~rol~rythmos+sacado~scorec~shards+shared~shylu~stk~stokhos~stratimikos~strumpack~suite-sparse~superlu~superlu-dist~teko~tempus+tpetra~trilinoscouplings~wrapper~zlib~zoltan~zoltan2
build_type=RelWithDebInfo cuda_arch=none cxxstd=11 gotype=long
arch=linux-centos7-broadwell


^openblas@0.3.17%gcc@7.4.0~bignuma~consistent_fpcsr~ilp64+locking+pic+shared
threads=none arch=linux-centos7-broadwell

^arpack-ng@3.8.0%gcc@7.4.0+mpi+shared arch=linux-centos7-broadwell

^metis@5.1.0%gcc@7.4.0~gdb~int64~real64+shared build_type=Release
arch=linux-centos7-broadwell



dealii requires gmsh variant +tetgen, but spec asked for ~tetgen

[asalvado@r000u07l02 uBS21_CivSal_0]$




*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 Fri, Jul 30, 2021 at 5:01 PM Bruno Turcksin 
wrote:

> Alberto,
>
> My experience with spack is to use a release version instead of the
> development version. They are too many moving parts in spack to expect the
> development version to be stable. My first question is do you need gmsh
> support in deal.II? If not you can just do spack install dealii~gmsh. If
> you need gmsh, can you try spack spec dealii^gmsh~med to check that spack
> can concretize the package.
>
> Best,
>
> Bruno
>
> On Friday, July 30, 2021 at 10:39:13 AM UTC-4 Alberto Salvadori wrote:
>
>> Thank you, Bruno.
>> It looks like gmsh is the package which requires med:
>>
>> 
>> ^gm...@4.8.4%g...@7.4.0+alglib~cairo+

Re: [deal.II] Re: issue in installing dealii 9.2 and .3 on centos

[Alberto Salvadori]

Bruno,

I do import gmsh triangulations in dealii simulations. Would this be
possible without including gmsh ?

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 Fri, Jul 30, 2021 at 5:01 PM Bruno Turcksin 
wrote:

> Alberto,
>
> My experience with spack is to use a release version instead of the
> development version. They are too many moving parts in spack to expect the
> development version to be stable. My first question is do you need gmsh
> support in deal.II? If not you can just do spack install dealii~gmsh. If
> you need gmsh, can you try spack spec dealii^gmsh~med to check that spack
> can concretize the package.
>
> Best,
>
> Bruno
>
> On Friday, July 30, 2021 at 10:39:13 AM UTC-4 Alberto Salvadori wrote:
>
>> Thank you, Bruno.
>> It looks like gmsh is the package which requires med:
>>
>> 
>> ^gm...@4.8.4%g...@7.4.0+alglib~cairo+cgns+compression~eigen~external+fltk+gmp~hdf5~ipo+med+metis+mmg~mpi+netgen+oce~opencascade~openmp~petsc~privateapi+shared~slepc+tetgen+voropp
>> build_type=RelWithDebInfo arch=linux-centos7-broadwell
>>
>> I am using
>>
>> [asalvado@r000u07l02 uBS21_CivSal_0]$ spack --version
>>
>> 0.16.2-3715-a904418
>>
>> Your help is appreciated.
>> 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@unibs.it
>> web-page:
>>  http://m4lab.unibs.it/faculty.html
>>
>>
>>
>> On Fri, Jul 30, 2021 at 4:12 PM Bruno Turcksin 
>> wrote:
>>
>>> Alberto,
>>>
>>> I have no clue what med is, so it's not a basic dependency of deal.II.
>>> Which version of spack are you using? I don't see a dependency on med when
>>> I do `spack speck dealii` You can tell spack not to install med but you
>>> need to know which package pulled it.
>>>
>>> Best,
>>>
>>> Bruno
>>>
>>> On Friday, July 30, 2021 at 8:48:04 AM UTC-4 Alberto Salvadori wrote:
>>>
>>>> Dear community
>>>>
>>>> while installing deal.ii on a centos cluster, I am facing the following
>>>> issue related to med :
>>>>
>>>> *==>* *Installing* *med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf*
>>>>
>>>> *==>* Warning: Spack will not check SSL certificates. You need to
>>>> update your Python to enable certificate verification.
>>>>
>>>> *==>* No binary for med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf found:
>>>> installing from source
>>>>
>>>> *==>* Using cached archive:
>>>> /marconi_work/uBS21_CivSal_0/spack/var/spack/cache/_source-cache/archive/a4/a474e90b5882ce69c5e9f66f6359c53b8b73eb448c5f631fa96e8cd2c14df004.tar.gz
>>>>
>>>> *==>* No patches needed for med
>>>>
>>>> *==>* med: Executing phase: 'cmake'
>>>>
>>>> *==>* Error: ProcessError: Command exited with status 1:
>>>>
>>>> 'cmake' '-G' 'Unix Makefiles'
>>>> '-DCMAKE_INSTALL_PREFIX:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf'
>>>> '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo'
>>>> '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF'
>>>> '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON'
>>>> '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=OFF'
>>>> '-DCMAKE_INSTALL_RPATH:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib64;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/numactl-2.0.14-qtf6zwk7cppy35evzpg5bvngl4uioe7v/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openmpi-4.1.1-ctp6zbck3skxoohx24qake6oljk6ufzr/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hwloc-2.5.0-g27bmqmr42ruvvwvhvxuqoyk22xokrah/lib;/m

Re: [deal.II] Re: issue in installing dealii 9.2 and .3 on centos

[Alberto Salvadori]

Thank you, Bruno.
It looks like gmsh is the package which requires med:


^gmsh@4.8.4%gcc@7.4.0+alglib~cairo+cgns+compression~eigen~external+fltk+gmp~hdf5~ipo+med+metis+mmg~mpi+netgen+oce~opencascade~openmp~petsc~privateapi+shared~slepc+tetgen+voropp
build_type=RelWithDebInfo arch=linux-centos7-broadwell

I am using

[asalvado@r000u07l02 uBS21_CivSal_0]$ spack --version

0.16.2-3715-a904418

Your help is appreciated.
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 Fri, Jul 30, 2021 at 4:12 PM Bruno Turcksin 
wrote:

> Alberto,
>
> I have no clue what med is, so it's not a basic dependency of deal.II.
> Which version of spack are you using? I don't see a dependency on med when
> I do `spack speck dealii` You can tell spack not to install med but you
> need to know which package pulled it.
>
> Best,
>
> Bruno
>
> On Friday, July 30, 2021 at 8:48:04 AM UTC-4 Alberto Salvadori wrote:
>
>> Dear community
>>
>> while installing deal.ii on a centos cluster, I am facing the following
>> issue related to med :
>>
>> *==>* *Installing* *med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf*
>>
>> *==>* Warning: Spack will not check SSL certificates. You need to update
>> your Python to enable certificate verification.
>>
>> *==>* No binary for med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf found:
>> installing from source
>>
>> *==>* Using cached archive:
>> /marconi_work/uBS21_CivSal_0/spack/var/spack/cache/_source-cache/archive/a4/a474e90b5882ce69c5e9f66f6359c53b8b73eb448c5f631fa96e8cd2c14df004.tar.gz
>>
>> *==>* No patches needed for med
>>
>> *==>* med: Executing phase: 'cmake'
>>
>> *==>* Error: ProcessError: Command exited with status 1:
>>
>> 'cmake' '-G' 'Unix Makefiles'
>> '-DCMAKE_INSTALL_PREFIX:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf'
>> '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo'
>> '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF'
>> '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON'
>> '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=OFF'
>> '-DCMAKE_INSTALL_RPATH:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib64;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/numactl-2.0.14-qtf6zwk7cppy35evzpg5bvngl4uioe7v/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openmpi-4.1.1-ctp6zbck3skxoohx24qake6oljk6ufzr/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hwloc-2.5.0-g27bmqmr42ruvvwvhvxuqoyk22xokrah/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libpciaccess-0.16-3lmrc4ak3cqlrwdmu3rwgmdzj6256j6q/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libxml2-2.9.10-r7ofye65rymwgmbdqgka3tnwbzw3kcvx/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libiconv-1.16-meyg2avc5ldglxqayvrmzltjirkpgplv/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/xz-5.2.5-wczw77mhc2n2anwdvurydxw45nifh5ik/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/zlib-1.2.11-w4v4ex6wf3qcmkuxdnmga7snctdxiz6h/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/ncurses-6.2-73efdut6ehthgyksblf3qjpmgm7rtced/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libevent-2.1.12-2y4ktlntxfx32bacu2rrpvmummy7zslt/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openssl-1.1.1k-p5o7iymffnfrwrakncqzibjwoxoutlsj/lib'
>> '-DCMAKE_PREFIX_PATH:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openmpi-4.1.1-ctp6zbck3skxoohx24qake6oljk6ufzr;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libevent-2.1.12-2y4ktlntxfx32bacu2rrpvmummy7zslt;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hwloc-2.5.0-g27bmqmr42ruvvwvhvxuqoyk22xokrah;/marconi_work/uBS21_Ci

[deal.II] issue in installing dealii 9.2 and .3 on centos

[Alberto Salvadori]

Dear community

while installing deal.ii on a centos cluster, I am facing the following 
issue related to med :

*==>* *Installing* *med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf*

*==>* Warning: Spack will not check SSL certificates. You need to update 
your Python to enable certificate verification.

*==>* No binary for med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf found: 
installing from source

*==>* Using cached archive: 
/marconi_work/uBS21_CivSal_0/spack/var/spack/cache/_source-cache/archive/a4/a474e90b5882ce69c5e9f66f6359c53b8b73eb448c5f631fa96e8cd2c14df004.tar.gz

*==>* No patches needed for med

*==>* med: Executing phase: 'cmake'

*==>* Error: ProcessError: Command exited with status 1:

'cmake' '-G' 'Unix Makefiles' 
'-DCMAKE_INSTALL_PREFIX:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf'
 
'-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' 
'-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF' 
'-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' 
'-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=OFF' 
'-DCMAKE_INSTALL_RPATH:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/med-4.0.0-d65qwjrfigoxirhf5xy6lsumdwpcvluf/lib64;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/numactl-2.0.14-qtf6zwk7cppy35evzpg5bvngl4uioe7v/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openmpi-4.1.1-ctp6zbck3skxoohx24qake6oljk6ufzr/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hwloc-2.5.0-g27bmqmr42ruvvwvhvxuqoyk22xokrah/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libpciaccess-0.16-3lmrc4ak3cqlrwdmu3rwgmdzj6256j6q/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libxml2-2.9.10-r7ofye65rymwgmbdqgka3tnwbzw3kcvx/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libiconv-1.16-meyg2avc5ldglxqayvrmzltjirkpgplv/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/xz-5.2.5-wczw77mhc2n2anwdvurydxw45nifh5ik/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/zlib-1.2.11-w4v4ex6wf3qcmkuxdnmga7snctdxiz6h/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/ncurses-6.2-73efdut6ehthgyksblf3qjpmgm7rtced/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libevent-2.1.12-2y4ktlntxfx32bacu2rrpvmummy7zslt/lib;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openssl-1.1.1k-p5o7iymffnfrwrakncqzibjwoxoutlsj/lib'
 
'-DCMAKE_PREFIX_PATH:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openmpi-4.1.1-ctp6zbck3skxoohx24qake6oljk6ufzr;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libevent-2.1.12-2y4ktlntxfx32bacu2rrpvmummy7zslt;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hwloc-2.5.0-g27bmqmr42ruvvwvhvxuqoyk22xokrah;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libxml2-2.9.10-r7ofye65rymwgmbdqgka3tnwbzw3kcvx;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/xz-5.2.5-wczw77mhc2n2anwdvurydxw45nifh5ik;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libpciaccess-0.16-3lmrc4ak3cqlrwdmu3rwgmdzj6256j6q;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/numactl-2.0.14-qtf6zwk7cppy35evzpg5bvngl4uioe7v;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/cmake-3.20.5-gnzlzwmoxs5uf2q2sxke33gf2f7atp7h;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/openssl-1.1.1k-p5o7iymffnfrwrakncqzibjwoxoutlsj;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/zlib-1.2.11-w4v4ex6wf3qcmkuxdnmga7snctdxiz6h;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/libiconv-1.16-meyg2avc5ldglxqayvrmzltjirkpgplv;/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/ncurses-6.2-73efdut6ehthgyksblf3qjpmgm7rtced'
 
'-DHDF5_ROOT_DIR:STRING=/marconi_work/uBS21_CivSal_0/spack/opt/spack/linux-centos7-broadwell/gcc-7.4.0/hdf5-1.10.7-nrpa5xndtz4a2yo6xjulubsoqufllvpo'
 
'-DMEDFILE_BUILD_TESTS:BOOL=OFF' '-DMEDFILE_BUILD_PYTHON:BOOL=OFF' 
'-DMEDFILE_INSTALL_DOC:BOOL=OFF' '-DCMAKE_Fortran_COMPILER=' 
'-DCMAKE_CXX_FLAGS:STRING=-DMED_API_23=1' 
'-DCMAKE_C_FLAGS:STRING=-DMED_API_23=1' '-DMED_API_23=1' 
'-DMEDFILE_BUILD_SHARED_LIBS=OFF' '-DMED

[deal.II] Fully funded PhD position at m4lab@UNIBS

[Alberto Salvadori]

Dear community,

The Multiscale Mechanics and Multiphysics of Materials Lab (
http://m4lab.unibs.it) at the School of Engineering, University of Brescia, 
Italy announces a PhD fellowship on *Modeling and simulations for next 
generation lithium-ion cells via deal.ii*. The fellowship is fully funded 
by the m4lab in collaboration with the Austrian Research Center Virtual 
Vehicles (https://www.v2c2.at) and will last three years.

If interested, please contact alberto.salvadori(at)unibs.it. A copy of a 
CV, eligibility to work in Italy, and a description of research interests 
is mandatory.

Further information and administrative facts can be found at 

https://en.unibs.it/university/calls-and-notices-students-and-graduates/... 


Thanks!
Alberto



-- 


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/3351bfb6-e21e-4569-af3a-870f3b0ab525n%40googlegroups.com.

Re: [deal.II] AffineCostraints and MPI

[Alberto Salvadori]

Thank you, Wolfgang.
I sorted it out, following the hanging node constraint sequence of
instructions.
It seems to work just fine.


*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 Wed, May 5, 2021 at 12:19 AM Wolfgang Bangerth 
wrote:

>
> Alberto,
>
> > Basically, I would like to rephrase The step-11 tutorial program
> > for parallel::shared matrices, as in step 18. If I am not wrong the
> "condense"
> > methods do not apply to MPI::SparseMatrix and I guess I should use the
> methods
> > of the family distribute_local_to_global,
>
> Correct. For matrices that are stored in parallel, after-the-fact
> modification
> is very expensive and the way to deal with constraints is to take care of
> them
> during the copy-to-local phase.
>
> > but I am a bit confused and cannot
> > connect the strategy in step 11
> >
> > mean_value_constraints.add_line(first_boundary_dof);
> > for (unsigned int i = first_boundary_dof + 1; i < dof_handler.n_dofs();
> ++i)
> > if (boundary_dofs[i] == true)
> > mean_value_constraints.add_entry(first_boundary_dof, i, -1);
> >
> > with any distribute_local_to_global.
>
> These lines build a ConstraintMatrix object with a single constraint. You
> can
> then call
>mean_value_constraints.distribute_local_to_global (...)
> in the assembly phase.
>
> But I might just not know what your problem is in detail. Can you explain
> what
> doesn't work?
>
> 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/27c40b58-770f-c19c-0703-97a8062a8afa%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpfaku7RSQJQkjUN54S0D4KYzmaZpj7RbX_ePW0BYMP55Q%40mail.gmail.com.

Re: [deal.II] dealii/spack on apple m1

[Alberto Salvadori]

Hi Praveen,

here is my experience on apple M1 and deal.ii.

1 - After opening a terminal rosetta, installing gcc, installing deal.ii
via spack and using gfortran from gcc installation, it works just fine
2 - Even in a rosetta terminal, the current dmg package does not seem to
work
3 - After opening a terminal rosetta, NOT installing gcc, installing
deal.ii via spack and using gfortran from homebrew installation, deal.ii
apparently does not work
4 - I had some issues with openmpi after installation, because of the
dynamic library that apparently conflicts with cmake. My skills are very
limited, but with some further work (that I cannot recall now)
I made it, even with Xcode projects.

Hope it helps
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 Thu, Apr 15, 2021 at 7:00 AM Praveen C  wrote:

> Dear all
>
> Has anyone succeeded in installing dealii via spack on an apple m1 ?
>
> What works/does not work ?
>
> spack gives me a spec but also gives some warnings
>
> $ spack spec dealii
> Input spec
> 
> dealii
>
> Concretized
> 
> sysctl: unknown oid 'machdep.cpu.leaf7_features'
> sysctl: unknown oid 'machdep.cpu.vendor'
> sysctl: unknown oid 'machdep.cpu.model'
> sysctl: unknown oid 'machdep.cpu.leaf7_features'
> sysctl: unknown oid 'machdep.cpu.vendor'
> sysctl: unknown oid 'machdep.cpu.model'
>
> Or have you been able to compile dealii via some other method on m1 ?
>
> Thanks
> 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/CCA9B9D2-AC5B-4327-820D-472FB5AE3BDB%40gmail.com
> <https://groups.google.com/d/msgid/dealii/CCA9B9D2-AC5B-4327-820D-472FB5AE3BDB%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpfQ70FmrDAjuE-WhGP4nsHXQWDXw0rsRmQ5KV5rY_tLiA%40mail.gmail.com.

[deal.II] AffineCostraints and MPI

[Alberto Salvadori]

Dear community,
I wonder if you could address me to study how to solve this problem, which 
I am sure is quite simple. 
Basically, I would like to rephrase The step-11 tutorial program
for parallel::shared matrices, as in step 18. If I am not wrong the 
"condense" methods do not apply to MPI::SparseMatrix and I guess I should 
use the methods of the family distribute_local_to_global, but I am a bit 
confused and cannot connect the strategy in step 11

mean_value_constraints.add_line(first_boundary_dof);
for (unsigned int i = first_boundary_dof + 1; i < dof_handler.n_dofs(); ++i)
if (boundary_dofs[i] == true)
mean_value_constraints.add_entry(first_boundary_dof, i, -1);

with any distribute_local_to_global.

I appreciate your help as always
Alberto

-- 


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/5b78e1cb-779f-4df3-a887-424103cd01e6n%40googlegroups.com.

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

[Alberto Salvadori]

-7.5.0/hypre-2.20.0-gxamjchraomkzvxbkyw5iomwetsgs42y/lib/libHYPRE.so
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/superlu-dist-6.4.0-rmikly
 vwbbt43hqdirs5teolapo42ehw/lib/libsuperlu_dist.so  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/openblas-0.3.13-rdcfnb5vanisjm5jwfymqnubvalw2p7g/lib/libopenblas.so
  

 
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/hdf5-1.10.7-xqvpzaheb7samdgjskaj6ipkwvkjn6fp/lib/libhdf5hl_fortran.so
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-sk

 ylake/gcc-7.5.0/hdf5-1.10.7-xqvpzaheb7samdgjskaj6ipkwvkjn6fp/lib/libhdf5_hl.so 
 
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/hdf5-1.10.7-xqvpzaheb7samdgjskaj6ipkwvkj
 n6fp/lib/libhdf5_fortran.so  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/hdf5-1.10.7-xqvpzaheb7samdgjskaj6ipkwvkjn6fp/lib/libhdf5.so
  
/home/dealii/spack/opt/spack/l

 
inux-ubuntu18.04-skylake/gcc-7.5.0/parmetis-4.0.3-ctkvdv4r3s53vcjmh3lj7ofva64pfxm3/lib/libparmetis.so
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/metis-5.1.0-5nhfc
 72ai2qxmtzp5yo2asgnj5lpvtpk/lib/libmetis.so  -lz  
-lmpi_usempif08  -lmpi_usempi_ignore_tkr  -lmpi_mpifh  -lmpi  -lgfortran  
-lm  -lpthread  -lquadmath  -ldl  /home/dealii/spack/opt/spac

 
k/linux-ubuntu18.04-skylake/gcc-7.5.0/sundials-3.2.1-r4mumobygmp6fx53cuelcm4ea46ni7bq/lib/libsundials_idas.so
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/sundials-

 3.2.1-r4mumobygmp6fx53cuelcm4ea46ni7bq/lib/libsundials_arkode.so  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/sundials-3.2.1-r4mumobygmp6fx53cuelcm4ea46ni7bq/lib/li
 bsundials_kinsol.so  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/sundials-3.2.1-r4mumobygmp6fx53cuelcm4ea46ni7bq/lib/libsundials_nvecserial.so
  
/home/dealii/spack/o

 
pt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/sundials-3.2.1-r4mumobygmp6fx53cuelcm4ea46ni7bq/lib/libsundials_nvecparallel.so
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-

 
7.5.0/symengine-0.6.0-by2wo5lc2fdqjaq4nx73ukopbsiiriao/lib/libsymengine.so.0.6.0
  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/gmp-6.1.2-eccwifch7wiznkg5z5lvkcqo4php
 g2vv/lib/libgmp.so  
/home/dealii/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-7.5.0/mpc-1.1.0-hdara4muh5idq45qfhxyklkdydw6h2kr/lib/libmpc.so
  
/home/dealii/spack/opt/spack/linux-ubuntu1

 
8.04-skylake/gcc-7.5.0/mpfr-4.0.2-ke4vba5vg4mwmoymqrs3p32ylhinwy67/lib/libmpfr.so
 
&& :
  >> 1924lib/libdeal_II.g.so.9.2.0: error: undefined reference to 
'gko::OmpExecutor::raw_copy_to(gko::HipExecutor const*, unsigned long, void 
const*, void*) const'
  >> 1925lib/libdeal_II.g.so.9.2.0: error: undefined reference to 
'typeinfo for gko::HipExecutor'
  >> 1926collect2: error: ld returned 1 exit status


I wondered if this error was related to mumps and dependences of ginkgo. I 
attempted therefore at using the older version of ginkgo as well, 
ginkgo-1.1.0. With such a version, no further errors arose and 


==> Installing dealii-9.2.0-ixyu3bhuwzk3ydljzr64vspiwnqcqyoa
==> No binary for dealii-9.2.0-ixyu3bhuwzk3ydljzr64vspiwnqcqyoa found: 
installing from source
==> Using cached archive: 
/home/dealii/spack/var/spack/cache/_source-cache/archive/d0/d05a82fb40f1f1e24407451814b5a6004e39366a44c81208b1ae9d65f3efa43a.tar.gz
==> Using cached archive: 
/home/dealii/spack/var/spack/cache/_source-cache/archive/5f/5f9f411ab9336bf49d8293b9936344bad6e1cf720955b9d8e8b29883593b0ed9
==> dealii: Executing phase: 'cmake'
==> dealii: Executing phase: 'build'
==> dealii: Executing phase: 'install'
==> dealii: Successfully installed 
dealii-9.2.0-ixyu3bhuwzk3ydljzr64vspiwnqcqyoa
  Fetch: 0.14s.  Build: 16m 12.77s.  Total: 16m 12.91s.


Alberto


Il giorno venerdì 15 gennaio 2021 alle 17:44:44 UTC+1 Jean-Paul Pelteret ha 
scritto:

> Hi Alberto,
>
> Thanks for pointing out that the Wiki is out of date. I've updated that 
> portion of the page with the correct information.
>
> Best,
> Jean-Paul
>
>
> On 15.01.21 09:25, Alberto Salvadori wrote:
>
> Thank you, very useful. 
> I suggest adding this info to the wiki page , in place of git checkout 
> master.
>
>
> *Alberto Salvadori * Dipartimento di Ingegneria Meccanica e Industriale 
> (DIMI)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3715426
>
> e-mail: 
>  alberto@unibs.it
> web-page:
>  http://m4lab.unibs.it/faculty.html
>
>
>
> On Thu, Jan 14, 2021 at 7:57 PM Jean-Paul Pelteret  
> wrote:
>
>> Hi Alberto,
>>
>> I concur with Bruno. ADOL-C changed the location o

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

[Alberto Salvadori]

Thank you, very useful.
I suggest adding this info to the wiki page , in place of git checkout
master.


*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 Thu, Jan 14, 2021 at 7:57 PM Jean-Paul Pelteret 
wrote:

> Hi Alberto,
>
> I concur with Bruno. ADOL-C changed the location of their project and
> repository, so Spack's master branch must be directing you towards the old
> site. Clearly it doesn't have an updated package for deal.II either,
> because its trying to deduce the location of the deal.II tarball on GitHub.
> Using Spack's "develop" branch is the way to keep up to date with the
> latest developments or, should you want to be a little more conservative,
> you could check out their latest tag, which is v0.16.0
> <https://github.com/spack/spack/tree/v0.16.0> .
>
> Best,
> Jean-Paul
>
> On 14.01.21 19:37, Bruno Turcksin wrote:
>
> Alberto,
>
> Do not use the master branch in spack. The last commit from the master
> branch on spack is from 2018. I'm guessing you want to use develop. develop
> for spack is the equivalent of master in deal.II
>
> Best,
>
> Bruno
>
> On Thursday, January 14, 2021 at 1:20:09 PM UTC-5 Alberto Salvadori wrote:
>
>> Dear community
>>
>> I have been trying installing dealii@9.2 on ubuntu 18.04 gcc7.5.0,
>> unsuccesfully.
>> The version 9.1.1 is already installed and works just fine, at that
>> installation time
>> I did manage to install ado...@2.7.3 and I put its path into the
>> pacages.yaml
>> as I did for dea...@9.1.1
>> URL in fetch seem to be wrong, in fact they do not exist, if I am not
>> misunderdanding.
>> Any suggestion is appreciated.
>> Alberto
>>
>> I did the following:
>>
>> 1 - in spack directory
>>  git checkout master
>>
>> response: your branch is up to date with 'origin/master'
>>
>> 2 - in the same directory
>> spack install dealii@9.2
>>
>> response:
>> Warning: Missing a source id for ado...@2.7.3
>> Warning: Missing a source id for dealii@9.2
>>
>> ==> 26892: Installing dealii
>> ==> Warning: There is no checksum on file to fetch dealii@9.2 safely.
>> ==>   Fetch anyway? [y/N] y
>> ==> Fetching with no checksum.
>>   Add a checksum or use --no-checksum to skip this check.
>> ==> Fetching
>> https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
>> #=#=-  #   #
>>
>>
>>   #=O=# ##
>>
>>
>>
>> curl: (22) The requested URL returned error: 404
>> ==> Failed to fetch file from URL:
>> https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
>> URL
>> https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz was
>> not found!
>> ==> Fetching from
>> https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
>>  failed.
>> ==> Error: FetchError: All fetchers failed for
>> spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn
>>
>> /home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
>>1124raise FetchError("Will not fetch %s" %
>>1125
>> self.spec.format('{name}{@version}'), ck_msg)
>>1126
>>   >>   1127self.stage.create()
>>1128self.stage.fetch(mirror_only)
>>1129self._fetch_time = time.time() - start_time
>>1130
>>
>>
>> ==> Error: Failed to install dealii due to ChildError: FetchError: All
>> fetchers failed for spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn
>> /home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
>>1124raise FetchError("Will not fetch %s" %
>>1125
>> self.spec.format('{name}{@version}'), ck_msg)
>>1126
>>   >>   1127self.stage.create()
>>1128self.stage.fetch(mirror_only)
>>1129self._fetch_time = time.time() - start_time
>>1130
>>
>> Traceback (most recent call last):
>>   File "/home/dealii/spack/lib/spack/spack/build_environment.py", line
>> 801, in child_process
>> return_value = function()
>>   File "/home/dealii/spack/lib/spack/spack/installer.py", line 1046, in
>> build_process
>> pk

[deal.II] issue in installing dealii@9.2 on ubuntu through spack

[Alberto Salvadori]

Dear community

I have been trying installing dealii@9.2 on ubuntu 18.04 gcc7.5.0, 
unsuccesfully.
The version 9.1.1 is already installed and works just fine, at that 
installation time
I did manage to install adol-c@2.7.3 and I put its path into the 
pacages.yaml
as I did for dealii@9.1.1
URL in fetch seem to be wrong, in fact they do not exist, if I am not 
misunderdanding.
Any suggestion is appreciated.
Alberto

I did the following:

1 - in spack directory
 git checkout master

response: your branch is up to date with 'origin/master'

2 - in the same directory 
spack install dealii@9.2

response:
Warning: Missing a source id for adol-c@2.7.3
Warning: Missing a source id for dealii@9.2

==> 26892: Installing dealii
==> Warning: There is no checksum on file to fetch dealii@9.2 safely.
==>   Fetch anyway? [y/N] y
==> Fetching with no checksum.
  Add a checksum or use --no-checksum to skip this check.
==> Fetching 
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
#=#=-  #   #   


#=O=# ##   


   
curl: (22) The requested URL returned error: 404
==> Failed to fetch file from URL: 
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
URL 
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz was 
not found!
==> Fetching from 
https://github.com/dealii/dealii/releases/download/v9.2/dealii-9.2.tar.gz
 failed.
==> Error: FetchError: All fetchers failed for 
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn

/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
   1124raise FetchError("Will not fetch %s" %
   1125 
self.spec.format('{name}{@version}'), ck_msg)
   1126
  >>   1127self.stage.create()
   1128self.stage.fetch(mirror_only)
   1129self._fetch_time = time.time() - start_time
   1130


==> Error: Failed to install dealii due to ChildError: FetchError: All 
fetchers failed for spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn
/home/dealii/spack/lib/spack/spack/package.py:1127, in do_fetch:
   1124raise FetchError("Will not fetch %s" %
   1125 
self.spec.format('{name}{@version}'), ck_msg)
   1126
  >>   1127self.stage.create()
   1128self.stage.fetch(mirror_only)
   1129self._fetch_time = time.time() - start_time
   1130

Traceback (most recent call last):
  File "/home/dealii/spack/lib/spack/spack/build_environment.py", line 801, 
in child_process
return_value = function()
  File "/home/dealii/spack/lib/spack/spack/installer.py", line 1046, in 
build_process
pkg.do_patch()
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1167, in 
do_patch
self.do_stage()
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1152, in 
do_stage
self.do_fetch(mirror_only)
  File "/home/dealii/spack/lib/spack/spack/package.py", line 1128, in 
do_fetch
self.stage.fetch(mirror_only)
  File "/home/dealii/spack/lib/spack/spack/util/pattern.py", line 68, in 
getter
getattr(item, self.name)(*args, **kwargs)
  File "/home/dealii/spack/lib/spack/spack/stage.py", line 476, in fetch
raise fs.FetchError(err_msg, None)
spack.fetch_strategy.FetchError: All fetchers failed for 
spack-stage-dealii-9.2-s4o6vff2suxztaxmilrhrzts34jngztn







-- 


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/928185e9-d3b7-41e5-8dda-aa4bcbffdc7en%40googlegroups.com.

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Thank you, Wolfgang. The explanation was clear as usual, I understood the
principle but overlooked the DoFTools class. This is now set.
Unfortunately, it seems that it does not solve my issue and I guess I
figured out why.

In brief, I am building an
interface matrix and an interface rhs in the very same way cell matrix and
cell rhs have been built in step 18 - as depicted already (I won't repeat
it here).

Issues arise when I attempt at distributing the matrices into system
matrix:  I coded this

  local_interface_dof_indices = fiv.get_interface_dof_indices() ;


this->hanging_node_constraints.distribute_local_to_global(interface_matrix,
interface_rhs,  local_interface_dof_indices, this->system_matrix,
this->system_rhs);
using the very same hanging_node_constraints I used for the usual continuum
elements.
This last statement causes an error FOR TRILINOS (AND NOT FOR PETSc, which
works OK).

According to your remark "make_flux_sparsity_pattern() also adds entries
for DoFs i,j that are located
on cells that are face neighbors of each other" the error may arise because
in defining the interfaces I am:
1 - duplicating the nodes in order to separate the initial triangulation
into two
2 - building a new data structure that provide connectivity for the dofs of
the separated elements, exploiting the class FEInterfaceValues
I wonder if by doing so, the notion of "cells that are face neighbors of
each other" may not apply anymore and hence, as you suspected, I am
computing terms for the interface matrix
that are not part of the sparsity pattern of the Trilinos matrix.

If this is correct, do you see a way to circumvent the TRILINOS problem I
am facing?

Thank you,
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 Fri, Jan 8, 2021 at 9:10 PM Wolfgang Bangerth 
wrote:

> On 1/8/21 10:19 AM, Alberto Salvadori wrote:
> >
> > thank you for the hint. I looked at setp 47 sparsity pattern. If I
> understood
> > it right,
> > the main difference stands in the locally_relevant_dofs, which are no
> longer
> > extracted and used.
> > Rather, the sparsity pattern is based on the whole dof_handler, as per
> the
> > instruction
> >
> > DoFTools::make_flux_sparsity_pattern( this->dof_handler, dsp,
> > this->hanging_node_constraints, true );
>
> No, you mistook what the difference is. The difference is that
> make_sparsity_pattern() only adds entries for the matrix that correspond
> to
> DoFs i and j that are located on the same cell.
>
> make_flux_sparsity_pattern() also adds entries for DoFs i,j that are
> located
> on cells that are face neighbors of each other.
>
> In both cases, you can use the same locally_relevant_set when you set up
> the
> sparsity pattern object.
>
> 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/a7c6b38b-8537-26e1-5ea6-72b06cc5b8f3%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpfwhHhyDhCENUshUraRm3md1Uvnh5hhzqAFGXhXt7TZkw%40mail.gmail.com.

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Wolfgang,

thank you for the hint. I looked at setp 47 sparsity pattern. If I
understood it right,
the main difference stands in the locally_relevant_dofs, which are no
longer extracted and used.
Rather, the sparsity pattern is based on the whole dof_handler, as per the
instruction

DoFTools::make_flux_sparsity_pattern( this->dof_handler, dsp,
this->hanging_node_constraints, true );

At present, I am a bit confused by the final statements of the
setup_system, namely:

system_matrix.reinit(sparsity_pattern);
system_rhs.reinit(dof_handler.n_dofs());

In step 47, system_matrix is of type Sparse_Matrix, whereas I am using
wrappers to PETSc or TRILINOS ( i.e LA::MPI::SparseMatrix )
and they cannot be reinit with the sparsity_pattern.
Similarly for system_rhs. I have been reading those classes yet could not
figure out how to
circumvent the problem. Can you please address me in this regard?

Thank you so much,
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 Wed, Dec 23, 2020 at 8:43 PM Wolfgang Bangerth 
wrote:

>
> Alberto,
> my suspicion would be that you are computing terms for the interface
> matrix
> that are not part of the sparsity pattern of the Trilinos matrix. (PETSc
> does
> not require you to say up front where the nonzero entries of the matrix
> are
> going to be, if I recall correctly.)
>
> This can happen because for "normal" CG methods, you only get entries in
> the
> matrix if DoFs i,j are located on the same cell. But for methods that
> contain
> jump terms on the interfaces, you also get contributions for DoFs i,j
> located
> on different cells (and not necessarily at the face you're integrating
> over).
> Take a look at how step-47 builds its sparsity pattern.
>
> 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/138efd45-e249-2dbf-af90-b4e2edb4e40f%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpdaH%3Dxg1FPy0GnS5Rk6VcCzWH1jSHPVZRoiqXihjj7T9w%40mail.gmail.com.

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Thank you very much, Timo.
I have my code running reasonably well now and this is mostly because of
your suggestions.
The files you pointed me out to were exactly what I was looking for.
Perhaps this little effort in writing interfaces for continuous fe might
worth some description in the deal.ii
library.

Thank you again
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 Sat, Dec 26, 2020 at 11:00 PM Timo Heister  wrote:

> Alberto,
>
> >  I would like to associate to each gauss point on the interface,
> identified by the command
> >   const auto &q_points = fiv.get_quadrature_points();
> >  the values of the unknown fields at the two faces of the two cells that
> form the interface itself.
> >  It should not be too difficult I think.
> >  Perhaps I should use
>
> Currently, FEInterfaceValues does not have support for
> get_function_values() directly but this is something I am planning to
> do soon.
>
> Your code looks reasonable, but I think you can use the existing
> FEFaceValues objects inside the FEInterfaceValues like
>
> feiv.get_fe_face_values(0).get_function_values(...)
> feiv.get_fe_face_values(1).get_function_values(...)
>
>
> --
> 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/CAMRj59F15KznNpjHyAT_UmAs5k-%3DwMp9Xo952V5KBDm6JH1bsw%40mail.gmail.com
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpctA9fPDRtAoOnY%3D8MDPEpUc4DX8t%2BWV49sxjDx89U3tg%40mail.gmail.com.

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Some further information:

- no errors are detected by PETSc. By using it in place of Trilinos the 
code seem to work OK.
- if only the rhs is distributed, no errors again. Errors are due to the 
matrix distribution in Trilinos. 

Thank you again
Alberto

Il giorno mercoledì 23 dicembre 2020 alle 07:11:47 UTC+1 Alberto Salvadori 
ha scritto:

> Dear community
>
> After Timo's suggestions I attempted at assembling matrix and rhs for 
> problems with an interface, using continuum elements (not DG).
> I mean at this: take two domains connected by springs and pull them apart, 
> so to separate the domains and elongate the spring.
> Since the forces provided by the springs are due to the separation of the 
> faces, there is a contribution in the Newton Raphson system
> provided by the interface.
>
> The code I wrote is actually "almost" working, some help in addressing the 
> hopefully last piece of the puzzle is very much appreciated. In brief, I am 
> building an 
> interface matrix and an interface rhs in the very same way cell matrix and 
> cell rhs have been built in step 18:
>
> FEInterfaceValues fiv(fe, face_quadrature_formula,
> update_values | update_quadrature_points |
> update_normal_vectors | update_JxW_values);
>
> reinit_FeInterfaceValues ( fiv );
>
> unsigned dofs_per_interfaces = fiv.n_current_interface_dofs() ;
>
> std::vector local_interface_dof_indices 
> (dofs_per_interfaces);
> FullMatrix interface_matrix ( dofs_per_interfaces, 
> dofs_per_interfaces );
> Vector interface_rhs ( dofs_per_interfaces );
>
> interface_matrix = 0.0;
> interface_rhs = 0.0;
>
> for (unsigned int q_point=0; q_point < q_points.size(); ++q_point)
> {
>for (unsigned int ii=0; ii{
>   for ( unsigned int jj=0; jjinterface_matrix( ii,jj ) += ...
>
>interface_rhs(ii) += ...
>
> }
> }
>
> so far, this seems to work OK (although so far I did not checked if 
> processors own cells). Issues arise when I attempt at distributing 
> the matrices into system matrix: I coded this
>
>   local_interface_dof_indices = fiv.get_interface_dof_indices() ;
>
>   
> this->hanging_node_constraints.distribute_local_to_global(interface_matrix, 
> interface_rhs,  local_interface_dof_indices, this->system_matrix, 
> this->system_rhs);
> using the very same hanging_node_constraints I used for the usual 
> continuum elements. This last statement causes an error, though. Either 
> running in debug or release mode, these are the info from deal.ii:
>
> * *
> *Exception on processing: *
>
> **
> *An error occurred in line <1683> of file 
> 
>  
> in function*
> *void dealii::TrilinosWrappers::SparseMatrix::add(const 
> dealii::TrilinosWrappers::SparseMatrix::size_type, const 
> dealii::TrilinosWrappers::SparseMatrix::size_type, const 
> dealii::TrilinosWrappers::SparseMatrix::size_type *, const 
> dealii::TrilinosScalar *, const bool, const bool)*
> *The violated condition was: *
> *ierr == 0*
> *Additional information: *
> *An error with error number 2 occurred while calling a Trilinos 
> function*
> **
>
> *Aborting!*
> **
>
> The hanging_node_constraints was defined in the setup_system as:
>
>   this->hanging_node_constraints.clear ();
>   DoFTools::make_hanging_node_constraints (this->dof_handler,  
> this->hanging_node_constraints);
>   this->hanging_node_constraints.close ();
>   
>
> Can I ask from some hints?
> Thank you so much
> Alberto
>
> Il giorno martedì 22 dicembre 2020 alle 10:26:22 UTC+1 Alberto Salvadori 
> ha scritto:
>
>> Timo,
>> thank you. These two files are extremely helpful and I guess I understood 
>> a lot from them. Extremely well written, by the way.
>> I really appreciate it.
>>
>>  I would like to associate to each gauss point on the interface, 
>> identified by the command
>>   const auto &q_points = fiv.get_quadrature_points();
>>  the values of the unknown fields at the two faces of the two cells that 
>> form the interface itself.
>>  It should not be too difficult I think.
>>  Perhaps I should use
>>   
>>   FEFaceValues fe_face0_values (fe, face_quadrature_formula,
>> update_values | 
>> update_quadrature_points  |
>> update_normal_vectors | 
>> update_JxW_values);
>>   FEF

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Dear community

After Timo's suggestions I attempted at assembling matrix and rhs for 
problems with an interface, using continuum elements (not DG).
I mean at this: take two domains connected by springs and pull them apart, 
so to separate the domains and elongate the spring.
Since the forces provided by the springs are due to the separation of the 
faces, there is a contribution in the Newton Raphson system
provided by the interface.

The code I wrote is actually "almost" working, some help in addressing the 
hopefully last piece of the puzzle is very much appreciated. In brief, I am 
building an 
interface matrix and an interface rhs in the very same way cell matrix and 
cell rhs have been built in step 18:

FEInterfaceValues fiv(fe, face_quadrature_formula,
update_values | update_quadrature_points |
update_normal_vectors | update_JxW_values);

reinit_FeInterfaceValues ( fiv );

unsigned dofs_per_interfaces = fiv.n_current_interface_dofs() ;

std::vector local_interface_dof_indices 
(dofs_per_interfaces);
FullMatrix interface_matrix ( dofs_per_interfaces, 
dofs_per_interfaces );
Vector interface_rhs ( dofs_per_interfaces );

interface_matrix = 0.0;
interface_rhs = 0.0;

for (unsigned int q_point=0; q_point < q_points.size(); ++q_point)
{
   for (unsigned int ii=0; iihanging_node_constraints.distribute_local_to_global(interface_matrix, 
interface_rhs,  local_interface_dof_indices, this->system_matrix, 
this->system_rhs);
using the very same hanging_node_constraints I used for the usual continuum 
elements. This last statement causes an error, though. Either running in 
debug or release mode, these are the info from deal.ii:

* *
*Exception on processing: *

**
*An error occurred in line <1683> of file 

 
in function*
*void dealii::TrilinosWrappers::SparseMatrix::add(const 
dealii::TrilinosWrappers::SparseMatrix::size_type, const 
dealii::TrilinosWrappers::SparseMatrix::size_type, const 
dealii::TrilinosWrappers::SparseMatrix::size_type *, const 
dealii::TrilinosScalar *, const bool, const bool)*
*The violated condition was: *
*ierr == 0*
*Additional information: *
*An error with error number 2 occurred while calling a Trilinos 
function*
**

*Aborting!*
**

The hanging_node_constraints was defined in the setup_system as:

  this->hanging_node_constraints.clear ();
  DoFTools::make_hanging_node_constraints (this->dof_handler,  
this->hanging_node_constraints);
  this->hanging_node_constraints.close ();
  

Can I ask from some hints?
Thank you so much
Alberto

Il giorno martedì 22 dicembre 2020 alle 10:26:22 UTC+1 Alberto Salvadori ha 
scritto:

> Timo,
> thank you. These two files are extremely helpful and I guess I understood 
> a lot from them. Extremely well written, by the way.
> I really appreciate it.
>
>  I would like to associate to each gauss point on the interface, 
> identified by the command
>   const auto &q_points = fiv.get_quadrature_points();
>  the values of the unknown fields at the two faces of the two cells that 
> form the interface itself.
>  It should not be too difficult I think.
>  Perhaps I should use
>   
>   FEFaceValues fe_face0_values (fe, face_quadrature_formula,
> update_values | 
> update_quadrature_points  |
> update_normal_vectors | 
> update_JxW_values);
>   FEFaceValues fe_face1_values (fe, face_quadrature_formula,
> update_values | 
> update_quadrature_points  |
> update_normal_vectors | 
> update_JxW_values);
>
>   fe_face0_values.reinit (cell0, face_number_on_cell0);
>   fe_face1_values.reinit (cell0, face_number_on_cell1);
>
>   std::vector< Vector< double > > old_solution_values_at_face_0 ( 
> face_quadrature_formula.size(), Vector< double >(dofs.GPDofs) );
>   fe_face0_values.get_function_values ( accumulated_displacement, 
> old_solution_values_at_face_0 );
>   std::vector< Vector< double > > old_solution_values_at_face_1 ( 
> face_quadrature_formula.size(), Vector< double >(dofs.GPDofs) );
>   fe_face1_values.get_function_values ( accumulated_displacement, 
> old_solution_values_at_face_0 );
>
> I am concerned about the correspondence of quadrature points on the 
> interface and on the cell faces. Is there a simple and effective way to 
> find their association?
>
> Thanks,
> Alberto
>
>
> *Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale 
> (DIMI)
>  Universita` di Brescia, via Br

Re: [deal.II] FEInterfaceValues

[Alberto Salvadori]

Timo,
thank you. These two files are extremely helpful and I guess I understood a
lot from them. Extremely well written, by the way.
I really appreciate it.

 I would like to associate to each gauss point on the interface, identified
by the command
  const auto &q_points = fiv.get_quadrature_points();
 the values of the unknown fields at the two faces of the two cells that
form the interface itself.
 It should not be too difficult I think.
 Perhaps I should use

  FEFaceValues fe_face0_values (fe, face_quadrature_formula,
update_values |
update_quadrature_points  |
update_normal_vectors |
update_JxW_values);
  FEFaceValues fe_face1_values (fe, face_quadrature_formula,
update_values |
update_quadrature_points  |
update_normal_vectors |
update_JxW_values);

  fe_face0_values.reinit (cell0, face_number_on_cell0);
  fe_face1_values.reinit (cell0, face_number_on_cell1);

  std::vector< Vector< double > > old_solution_values_at_face_0 (
face_quadrature_formula.size(), Vector< double >(dofs.GPDofs) );
  fe_face0_values.get_function_values ( accumulated_displacement,
old_solution_values_at_face_0 );
  std::vector< Vector< double > > old_solution_values_at_face_1 (
face_quadrature_formula.size(), Vector< double >(dofs.GPDofs) );
  fe_face1_values.get_function_values ( accumulated_displacement,
old_solution_values_at_face_0 );

I am concerned about the correspondence of quadrature points on the
interface and on the cell faces. Is there a simple and effective way to
find their association?

Thanks,
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 Wed, Dec 16, 2020 at 11:25 PM Timo Heister  wrote:

> Alberto,
>
> > I would like to have a few more details on the class
> FEInterfaceValues.
> > since it is my feeling that  FEInterfaceValues
> > might be conveniently used for interfaces, even out of DG methods.
>
> Yes, I would think so.
>
> > Specifically I'd like to figure out if this notion can be used without
> recurring to the MeshWorker::mesh_loop,
> > which I am not quite confident at present.
>
> Note that we are not using the MeshWorker machinery but a single
> function that contains the loops over the cells. The code of the
> function is "relatively" easy to understand and you will appreciate
> the logic for the following things you would have to deal with when
> looping manually:
> - assembling from the finer cell for interfaces with adaptive refinement
> - correctly handling each facet once (or twice if desired) even in parallel
> - handling of periodic boundaries
>
> > I'd like to play autonomously with the class FEInterfaceValues
> > but unfortunately I cannot grasp the notion of subface, which is
> apparently
> > required by the reinit as in step 12:
> >  fe_iv.reinit(cell, f, sf, ncell, nf, nsf);
>
> With adaptivity you will need to pass the subface as returned by
> neighbor_of_coarser_neighbor, otherwise it is
> numbers::invalid_unsigned_int. See
>
> https://github.com/dealii/dealii/blob/691ff4907964605dd21e94f06c880786af2cd612/tests/feinterface/fe_interface_values_03.cc#L94-L100
> and
>
> https://github.com/dealii/dealii/blob/691ff4907964605dd21e94f06c880786af2cd612/tests/feinterface/fe_interface_values_02.cc#L88-L93
>
> > Can anyone address me some reading on this notion and how it is dealt
> with
> > by the MeshWorker::mesh_loop ?
>
> Take a look at the tests in tests/feinterface/:
> https://github.com/dealii/dealii/tree/master/tests/feinterface
>
> Many of them use FEInterfaceValues directly on a small test mesh.
>
> --
> 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/CAMRj59Fq2wUezf%3DikmWF5_BPB-Q1zzYgjOgd4XESUYdwX_pJ_A%40mail.gmail.com
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<http://www.unibs.it/node/8155>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum opti

Re: [deal.II] faces barycenter

[Alberto Salvadori]

You are right, of course, Wolfgang.
I should offer to contribute in the development of this method. I will.
Thank you
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 Mon, Dec 21, 2020 at 4:11 AM Wolfgang Bangerth 
wrote:

> On 12/20/20 2:58 AM, Alberto Salvadori wrote:
> >
> > Point centroid = cell->face(face_number)->barycenter() ;
> >
> > provides always centroid = {0,0,0}, whereas the following
> >
> > Point centroid = cell->face(face_number)->center() ;
> >
> > returns the correct amount.
> >
> > Am I misunderstanding something or may it be a bug?
>
> I suspect that you forgot to try running your code in debug mode :-) In
> debug
> mode, I'm pretty sure you would run into this assertion:
>
>template 
>Point
>barycenter(const TriaAccessor &)
>{
>  // this function catches all the cases not
>  // explicitly handled above
>  Assert(false, ExcNotImplemented());
>  return Point();
>}
>
> In other words, the function is simply not implemented -- though I suspect
> that it would not be very difficult to do so.
>
> 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/c6c8111e-a53a-da7a-4b5e-40b870546283%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpfQhoj40UDEfu5wVVAa2%3DrBxf2byZKdtUBHF37QKLMnHA%40mail.gmail.com.

[deal.II] faces barycenter

[Alberto Salvadori]

Dear community

I observed that this instruction:

Point centroid = cell->face(face_number)->barycenter() ;

provides always centroid = {0,0,0}, whereas the following

Point centroid = cell->face(face_number)->center() ;

returns the correct amount.

Am I misunderstanding something or may it be a bug?

Thanks,

Alberto

-- 


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/2554f429-14fd-49ae-9ca9-943db692f4f2n%40googlegroups.com.

[deal.II] FEInterfaceValues

[Alberto Salvadori]

Dear community

I would like to have a few more details on the class FEInterfaceValues 

.
since it is my feeling that  FEInterfaceValues 

might be conveniently used for interfaces, even out of DG methods.

Specifically I'd like to figure out if this notion can be used without 
recurring to the MeshWorker::mesh_loop 

,
which I am not quite confident at present.

I'd like to play autonomously with the class FEInterfaceValues 

but unfortunately I cannot grasp the notion of subface, which is apparently
required by the reinit as in step 12:
 fe_iv.reinit 
(cell,
 
f, sf, ncell, nf, nsf);

Can anyone address me some reading on this notion and how it is dealt with
by the MeshWorker::mesh_loop 

 ?

I appreciate your help

Alberto




-- 


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/1d271fc5-1017-49a3-80bf-cdd17e2e70aan%40googlegroups.com.

Re: [deal.II] catching SolverControl::NoConvergence

[Alberto Salvadori]

Wolfgang,

I am going to provide the small test case as soon as I can make it. In the 
meanwhile, it turned out that 

*catch* ( *const* std::exception &exc)
rather than  SolverControl::NoConvergence  works fine. 
By the way, I noticed that there is no Trilinos wrapper for GMRES, yet the 
implementation of LA::MPI::SolverGMRES provides no error when 
the trilinos flag is set. Is there any redirection to another solver? Is 
this a potential source of the unexpected behavior mentioned above?

Thank you.

Alberto
Il giorno giovedì 30 luglio 2020 alle 02:15:16 UTC+2 Wolfgang Bangerth ha 
scritto:

> On 7/29/20 5:37 AM, Alberto Salvadori wrote:
> > 
> > try
> > {
> > iterate_on_tolerance = false ;
> > this->pcout << " AMG - Bicgstab " << std::flush ;
> > 
> > bicgstab.solve (this->system_matrix, 
> distributed_incremental_displacement, 
> > this->system_rhs, preconditioner);
> > solver_control_last_step = bicgstab_solver_control.last_step();
> > }
> > 
> > catch ( SolverControl::NoConvergence )
> > {
> > iterate_on_tolerance = true ;
> > try
> > {
> >   ... whatever ...
> > }
> > 
> > My idea is: whenever  bicgstab.solve fails, for instance because the 
> accuracy 
> > is higher than the tolerance, I want to catch the exception 
> > SolverControl::NoConvergence  and do something else. I am insecure if 
> the 
> > above code is fine for this purpose, could you please address me  to a 
> broader 
> > explanation ?
>
> Yes, this is the equivalent code of what we have here in ASPECT:
>
> https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L502-L520
> or more tailored to your situation:
>
> https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L838-L913
>
>
> > At any rate, it turns out that the code above works OK for PETSc, but 
> not for 
> > trilinos - I do would like to use trilinos for the sake of memory leaks. 
> > Apparently , errors of kind
> > 
> > aztec00 error code #
> > 
> > take the lead with trilinos and the exception is not caught properly. I 
> must 
> > have done something wrong.
> Interesting. Can you again construct a small test case so we can see how 
> to 
> fix this?
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/51db88db-ae30-4888-a0b6-e66cd7e60192n%40googlegroups.com.

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

[Alberto Salvadori]

rs from 1 contexts (suppressed: 0 from 0)


Il giorno venerdì 24 luglio 2020 alle 21:37:02 UTC+2 d.arnd...@gmail.com ha 
scritto:

> 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@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+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/24389a5b-59ba-4f32-8c4b-06d23d0fe2ban%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/dealii/24389a5b-59ba-4f32-8c4b-06d23d0fe2ban%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/198cb5c7-7c39-4b4a-bba8-88dfaad20b97n%40googlegroups.com.

[deal.II] catching SolverControl::NoConvergence

[Alberto Salvadori]

 Dear community

in these days I am particularly bothering you, I apologize. Today, I wonder 
if I can receive some clarifications on catching the exception 
SolverControl::NoConvergence in using trilinos.

I wrote the code below for a linear system solver:

SolverControl bicgstab_solver_control ( bicgstab_max_iterations , tolerance 
); 
SolverControl gmres_solver_control ( gmres_max_iterations , tolerance );  


#ifdef USE_PETSC_LA 
PETScWrappers::SolverBicgstab bicgstab (bicgstab_solver_control, 
this->mpi_communicator); 
PETScWrappers::SolverGMRES gmres (gmres_solver_control, 
this->mpi_communicator, PETScWrappers::SolverGMRES::AdditionalData(50, 
true)); 

#else 
TrilinosWrappers::SolverBicgstab::AdditionalData solver_data; 
TrilinosWrappers::SolverBicgstab bicgstab (bicgstab_solver_control, 
solver_data ); 
TrilinosWrappers::SolverGMRES gmres (gmres_solver_control, 
TrilinosWrappers::SolverGMRES::AdditionalData(50, true)); 

#endif 

if ( PreconditionIsAMG ) 

{ 

LA::MPI::PreconditionAMG preconditioner; 
LA::MPI::PreconditionAMG::AdditionalData data; 
preconditioner.initialize(this->system_matrix, data); 

try 
{ 
iterate_on_tolerance = false ; 
this->pcout << " AMG - Bicgstab " << std::flush ; 

bicgstab.solve (this->system_matrix, distributed_incremental_displacement, 
this->system_rhs, preconditioner); 
solver_control_last_step = bicgstab_solver_control.last_step(); 
} 

catch ( SolverControl::NoConvergence ) 
{ 
iterate_on_tolerance = true ; 
try 
{ 
  ... whatever ...
}

My idea is: whenever  bicgstab.solve fails, for instance because the 
accuracy is higher than the tolerance, I want to catch the exception 
SolverControl::NoConvergence  and do something else. I am insecure if the 
above code is fine for this purpose, could you please address me  to a 
broader explanation ?
At any rate, it turns out that the code above works OK for PETSc, but not 
for trilinos - I do would like to use trilinos for the sake of memory 
leaks. Apparently , errors of kind 

aztec00 error code #

take the lead with trilinos and the exception is not caught properly. I 
must have done something wrong.

I appreciate your help.

Alberto




-- 


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/9f1be8ac-db68-4b94-98b1-3d4feff2b493n%40googlegroups.com.

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

[Alberto Salvadori]

Dear Wolfgang,

thank you for your guidance, I did what you suggested. Basically all calls 
in the system matrix construction have been removed but integration of unit 
per each element, with zero rhs. To make the system solvable, (non-zero, 
but it should be non relevant) Dirichlet boundary conditions have been 
imposed on the whole boundary. I checked the memory consumption through 
top->RES without solving the linear system, no issues arose. Again, as soon 
as I invoke 

BiCG.solve (this->system_matrix, distributed_incremental_displacement, 
this->system_rhs, preconditioner);

top->RES shows memory leaks. Guided by Richard remark, I implemented the 
trilinos solver as well. In such a case, no leaks at all. Even building the 
system matrix in the complete form.
My guess is that there must be either some conflicts or installation 
related issues with PETSc. Note that the system solution was always OK, the 
concern was just about the memory loss.

I did check that no issue arise in running step-18 from the library 
examples. 

In conclusion, the problem must be there, sorry I was not able to identify 
it more properly. Maybe Richard can be more precise, and I am at disposal, 
of course.

Hope this helps. 

Alberto


Il giorno sabato 25 luglio 2020 alle 05:46:08 UTC+2 Wolfgang Bangerth ha 
scritto:

> On 7/24/20 3:32 AM, Alberto Salvadori wrote:
> > 
> > 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.
>
> Alberto -- I've taken a look at the SolverBicgstab class and don't see 
> anything glaringly obvious that would suggest where the memory is lost. 
> It's 
> also funny that that would only happen with more than one processor 
> because 
> the memory handling of PETSc vectors shouldn't be any different for one or 
> more processors.
>
> Do you think you could come up with a simple test case that illustrates 
> the 
> problem? In your case, I'd start with the code you have and remove 
> basically 
> everything you do: replace the assembly by a function that just fills the 
> matrix with the identity matrix (or something similarly simple), remove 
> everything that does anything useful with the solution, remove graphical 
> output, etc. The only thing that should remain is the loop that repeatedly 
> solves a linear system and illustrates the memory leak, but the program no 
> longer has to do anything useful (in fact, it probably shouldn't -- it 
> should 
> only exercise the one part you suspect of causing the memory leak).
>
> I think that would make finding the root cause substantially simpler!
>
> Best
> W.
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/903450f4-1846-4979-978c-929f8c3167b9n%40googlegroups.com.

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

[Alberto Salvadori]

It happens to me the same, the memory loss increments at each call if the 
solver. It happens with BICG and with GMRES as well. 

Alberto Salvadori
Associate Professor 
DIMI, University of Brescia, Italy


> On 25 Jul 2020, at 10:24, Richard Schussnig  
> wrote:
> 
> Hi Alberto,
> I might be having a similar or even the same problem with petsc! In my case, 
> the memory accumulated is proportional to the number of iterations done in 
> the SolverFGMRES solver. Also, when using trilinos (switch between petsc and 
> trilinos see step 40 I believe), this does not(!) happen!
> Please do report back, if you find anything - I did not look into it for now, 
> but will do in a week or so.
> Regards & good luck,
> Richard
> 
> -- 
> 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/e0b379a9-dba7-4133-8ef0-ad308e680ffeo%40googlegroups.com.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/4587DD20-9DB7-4A2D-ACBD-C17F79ACB060%40unibs.it.

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

[Alberto Salvadori]

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 
<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.

[deal.II] Memory loss in system solver

[Alberto Salvadori]

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/a6abf4d8-ae28-4c74-a0be-3f47f046368an%40googlegroups.com.

[deal.II] Re: 9.2 issue during compilation on macOSX

[Alberto Salvadori]

quick update:

since I noticed the directory * 
zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff37x*
in deal.ii directory * 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple*

I thus attempted at creating a symbolic link* ln -s 
zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff37x 
zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff*
to sort out the warning message


*Scanning dependencies of target step-17*[ 50%] Building CXX object 
CMakeFiles/step-17.dir/step-17.cc.o
[100%] 
*Linking CXX executable step-17*ld: warning: directory not found for option 
'-L/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff'
[100%] Built target step-17


It worked, in the sense that :


bash-3.2$ make release

*Scanning dependencies of target release*[100%] 
*Switching CMAKE_BUILD_TYPE to Release*-- Autopilot invoked
-- Run   $ make info  to print a detailed help message
-- Configuring done
-- Generating done
-- Build files have been written to: 
/Users/albertosalvadori/Codes/dealii-9.2/examples/step-17

***
*** Switched to Release mode. Now recompile with:  $ make
***

[100%] Built target release

bash-3.2$ make

*Scanning dependencies of target step-17*[ 50%] Building CXX object 
CMakeFiles/step-17.dir/step-17.cc.o
[100%] 
*Linking CXX executable step-17*[100%] Built target step-17


Nonetheless,  the code still does not run neither in debug nor in release 
mode, providing the following output:

bash-3.2$ ./step-17 
dyld: malformed mach-o: load commands size (33840) > 32768
Abort trap: 6

Any help appreciated.

Thanks
Alberto



Il giorno lunedì 15 giugno 2020 alle 19:15:09 UTC+2 Alberto Salvadori ha 
scritto:

> Hi,
>
> I just installed release 9.2, with great pleasure on my mac. Not working 
> yet. 
>
> Here is the error I receive, my OSX is 10.15.4 (19E287) and Xcode 11.5 
> (11E608c)
>
>
> *Developer Tools:*
>
>
>   Version: 11.5 (11E608c)
>
>   Location: /Applications/Xcode.app
>
>   Applications:
>
>   Xcode: 11.5 (16139)
>
>   Instruments: 11.5 (64535.75)
>
>   SDKs:
>
>   iOS:
>
>   13.5: (17F65)
>
>   iOS Simulator:
>
>   13.5: (17F65)
>
>   macOS:
>
>   10.15.4: (19E258)
>
>   19.0: 
>
>   tvOS:
>
>   13.4: (17L255)
>
>   tvOS Simulator:
>
>   13.4: (17L255)
>
>   watchOS:
>
>   6.2: (17T255)
>
>   watchOS Simulator:
>
>   6.2: (17T255)
>
>
> It seems that a library is sought for in a non existing directory:
>
>
> bash-3.2$ ls 
> /Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff
>
> ls: 
> /Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff:
>  
> No such file or directory
>
>
> Let me know if I can be of further help.
>
>
> Thanks!
> Alberto
>
>
>
> This is a shell with modules and PATHs set to work with Deal.II.
>
> All external libraries and deal.II itself are located in 
>
>
> /Applications/deal.II.app/Contents/Resources/spack/
>
>
> If you want to set up your daily Terminal to work with deal.II, add
>
> these lines to your ~/.profile file (the first line turns off this 
> message):
>
>
>export DEAL_II_CONF_SILENT=ON
>
># DEAL_II_USE_LMOD=ON # if you want to use lmod instead of tcl module
>
># DEAL_II_ENABLE_VIEW=ON # if you want to set CMAKE_PREFIX_PATH to a 
> view of
>
>. /Applications/deal.II.app/Contents/MacOS/dealii.conf
>
>
> deal.II and all its dependencies were installed using spack, and are 
> available
>
> through the spack and module or lmod commands, e.g.:
>
>
> module load dealii
>
> 
>
>
> The default interactive shell is now zsh.
>
> To update your account to use zsh, please run `chsh -s /bin/zsh`.
>
> For more details, please visit https://support.apple.com/kb/HT208050.
>
> bash-3.2$ 
>
> bash-3.2$ 
>
> bash-3.2$ cd /Users/albertosalvadori/Codes/dealii-9.2/examples/step-17
>
> bash-3.2$ cmake -G 'Unix Makefiles'
>
> CMake Warning:
>
>   No source or binary directory provided.  Both will be assumed to be the
>
>   same as the current working directory, but note that this warning will
>
>   become a fatal error in future CMake releases.
>
>
>
> -- The C compiler identification is AppleClang 11.0.3.11030032
>
> -- The CXX compiler identification is AppleClang 11.0.3.11030032
>
> -- Check for working C compiler: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>
> -- Check 

[deal.II] 9.2 issue during compilation on macOSX

[Alberto Salvadori]

Hi,

I just installed release 9.2, with great pleasure on my mac. Not working 
yet. 

Here is the error I receive, my OSX is 10.15.4 (19E287) and Xcode 11.5 
(11E608c)


*Developer Tools:*


  Version: 11.5 (11E608c)

  Location: /Applications/Xcode.app

  Applications:

  Xcode: 11.5 (16139)

  Instruments: 11.5 (64535.75)

  SDKs:

  iOS:

  13.5: (17F65)

  iOS Simulator:

  13.5: (17F65)

  macOS:

  10.15.4: (19E258)

  19.0: 

  tvOS:

  13.4: (17L255)

  tvOS Simulator:

  13.4: (17L255)

  watchOS:

  6.2: (17T255)

  watchOS Simulator:

  6.2: (17T255)


It seems that a library is sought for in a non existing directory:


bash-3.2$ ls 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff

ls: 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/zlib-1.2.11-rqiqrujgg5aemhk7eqjk3asbaukff:
 
No such file or directory


Let me know if I can be of further help.


Thanks!
Alberto



This is a shell with modules and PATHs set to work with Deal.II.

All external libraries and deal.II itself are located in 


/Applications/deal.II.app/Contents/Resources/spack/


If you want to set up your daily Terminal to work with deal.II, add

these lines to your ~/.profile file (the first line turns off this message):


   export DEAL_II_CONF_SILENT=ON

   # DEAL_II_USE_LMOD=ON # if you want to use lmod instead of tcl module

   # DEAL_II_ENABLE_VIEW=ON # if you want to set CMAKE_PREFIX_PATH to a 
view of

   . /Applications/deal.II.app/Contents/MacOS/dealii.conf


deal.II and all its dependencies were installed using spack, and are 
available

through the spack and module or lmod commands, e.g.:


module load dealii




The default interactive shell is now zsh.

To update your account to use zsh, please run `chsh -s /bin/zsh`.

For more details, please visit https://support.apple.com/kb/HT208050.

bash-3.2$ 

bash-3.2$ 

bash-3.2$ cd /Users/albertosalvadori/Codes/dealii-9.2/examples/step-17

bash-3.2$ cmake -G 'Unix Makefiles'

CMake Warning:

  No source or binary directory provided.  Both will be assumed to be the

  same as the current working directory, but note that this warning will

  become a fatal error in future CMake releases.



-- The C compiler identification is AppleClang 11.0.3.11030032

-- The CXX compiler identification is AppleClang 11.0.3.11030032

-- Check for working C compiler: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

-- Check for working C compiler: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 
- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/openmpi-3.1.6-5strmdmhwolf2dlkebtvhizrmgnsnlce/bin/mpic++

-- Check for working CXX compiler: 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.3-apple/openmpi-3.1.6-5strmdmhwolf2dlkebtvhizrmgnsnlce/bin/mpic++
 
- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Autopilot invoked

###

#

#  Project  step-17  set up with  deal.II-9.2.0  found at

#  /Applications/deal.II.app/Contents/Resources/Libraries

#

#  CMAKE_BUILD_TYPE:  Debug

#

#  You can now run

#   $ make- to compile and link the program

#   $ make run- to (compile, link and) run the program

#

#   $ make sign   - to sign the executable with the supplied 
OSX developer key

#

#   $ make debug  - to switch the build type to 'Debug'

#   $ make release- to switch the build type to 'Release'

#

#   $ make edit_cache - to change (cached) configuration variables

#   and rerun the configure and generate phases 
of CMake

#

#   $ make strip_comments - to strip the source files in this

#   directory off their comments; this is 
irreversible

#   $ make clean  - to remove the generated executable as well 
as

#   all intermediate compilation files

#   $ make runclean   - to remove all output generated by the 
program

#   $ make distclean  - to clean the directory from _all_ generated

#   files (includes clean, runclean and the 
removal

#   of the generated build system)

#   $ make info   - to view this message again

#

#  Have a nice day!

#

###

-- Configuring done

-- Generating done

-- Build files have been written to: 
/Users/albertosalvadori/Codes/dealii-9.2/

Re: [deal.II] vertex and dofcells

[Alberto Salvadori]

Thank you, Jean Paul. Exhaustive, as usual.


*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, May 26, 2020 at 6:42 PM Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> Quick answer: There’s a entry in the FAQ that may answer your question:
>
> https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-get-the-degree-of-freedom-indices-at-vertices
>
> As mentioned at the bottom of that entry, is a small point on how to go
> from DoFs -> vertices using DoFTools::map_dofs_to_support_points()
> <https://dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a5514e4f59ea659f63953d62ca429eaff>
> .
>
> Does this help you?
> Best,
> Jean-Paul
>
> On 26 May 2020, at 18:35, Alberto Salvadori 
> wrote:
>
> Dear community,
>
> this looks a simple question but I just cannot find a simple answer, I
> apologize.
>
> The code I aim at writing is similar to:
>
> *unsigned* vv = 0 ;
>
>
> *for* (*unsigned* *int* ii=0; ii
> {
>
>   *const* *unsigned* *int* ii_group = manifold_fe
> .system_to_base_index(ii).first.first;
>
>
>   *if* ( ii_group == manifold_dofs.cS_dof )
>
>   {
>
> Point this_node = cell->vertex(vv) ;
>
>
> [ ... omitted code ... ]
>
>
> cell_matrix( ii,ii ) = 1 ;
>
> cell_rhs( ii ) = some_function_of( this_node );
>
>
> ...
>
> ++vv;
>
>   }
>
>  }
>
>
> In a nutshell, I want to retrieve information that I stored at each node
> of the cell, while looping on the dofcells.
> I am not sure if the order of the dofs and of the vertex coincide, suspect
> they do not.
> Can you please address me to a function that connects the dofcells to the
> associated vertex,or suggest a better approach?
>
> Thank you so much
>
> Alberto
>
>
> 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/3a275ee6-9416-4547-8a81-188c29579e2a%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/3a275ee6-9416-4547-8a81-188c29579e2a%40googlegroups.com?utm_medium=email&utm_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/F28279CC-8C0A-4CFC-84AC-4D97BE725C2E%40gmail.com
> <https://groups.google.com/d/msgid/dealii/F28279CC-8C0A-4CFC-84AC-4D97BE725C2E%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpcEuTUVgnhTBo_74HhXNhuqtyOA9sk3aroY1oH0NH1LNA%40mail.gmail.com.

[deal.II] vertex and dofcells

[Alberto Salvadori]

Dear community,

this looks a simple question but I just cannot find a simple answer, I 
apologize.

The code I aim at writing is similar to:

*unsigned* vv = 0 ;



*for* (*unsigned* *int* ii=0; ii this_node = cell->vertex(vv) ;



[ ... omitted code ... ]


cell_matrix( ii,ii ) = 1 ;

cell_rhs( ii ) = some_function_of( this_node );


...

++vv;

  }

 }



In a nutshell, I want to retrieve information that I stored at each node of 
the cell, while looping on the dofcells. 
I am not sure if the order of the dofs and of the vertex coincide, suspect 
they do not.
Can you please address me to a function that connects the dofcells to the 
associated vertex,or suggest a better approach?

Thank you so much

Alberto

-- 


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/3a275ee6-9416-4547-8a81-188c29579e2a%40googlegroups.com.

[deal.II] deal.ii 9.1.1 quit running after macOS Catalina update

[Alberto Salvadori]

Dear community,
Luca in particular

sorry for this bothering. It happened again, as on Dec. 2 , 2019 that after 
a macOS update deal.ii 9.1.1 quit running.
There appears to be an issue with the PETScWrappers  to MPI, for what I 
understand.
I really appreciate your help.

Alberto


Here is a log:

macOS Catalina 10.15.4 (19E287)

*Hardware Overview:*

  Model Name: MacBook Pro

  Model Identifier: MacBookPro10,1

  Processor Name: Quad-Core Intel Core i7

  Processor Speed: 2.3 GHz

  Number of Processors: 1

  Total Number of Cores: 4

  L2 Cache (per Core): 256 KB

  L3 Cache: 6 MB

  Hyper-Threading Technology: Enabled

  Memory: 8 GB


bash-3.2$ echo $DEAL_II_DIR 

/Applications/deal.II.app/Contents/Resources/Libraries

bash-3.2$ which cmake

/Applications/deal.II.app/Contents/Resources/Libraries/bin/cmake

bash-3.2$ cmake -G 'Unix Makefiles'

CMake Warning:

  No source or binary directory provided.  Both will be assumed to be the

  same as the current working directory, but note that this warning will

  become a fatal error in future CMake releases.



-- The C compiler identification is AppleClang 11.0.3.11030032

-- The CXX compiler identification is Clang 9.0.0

-- Check for working C compiler: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

-- Check for working C compiler: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 
-- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-haswell/clang-9.0.0/mpich-3.3.2-xfnadjyi3l5hbjla3xm2vhdtwq4sjsmi/bin/mpic++

-- Check for working CXX compiler: 
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-haswell/clang-9.0.0/mpich-3.3.2-xfnadjyi3l5hbjla3xm2vhdtwq4sjsmi/bin/mpic++
 
-- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Autopilot invoked

###

#

#  Project  step-18  set up with  deal.II-9.1.1  found at

#  /Applications/deal.II.app/Contents/Resources/Libraries

#

#  CMAKE_BUILD_TYPE:  Debug

#

#  You can now run

#   $ make- to compile and link the program

#   $ make run- to (compile, link and) run the program

#

#   $ make sign   - to sign the executable with the supplied 
OSX developer key

#

#   $ make debug  - to switch the build type to 'Debug'

#   $ make release- to switch the build type to 'Release'

#

#   $ make edit_cache - to change (cached) configuration variables

#   and rerun the configure and generate phases 
of CMake

#

#   $ make strip_comments - to strip the source files in this

#   directory off their comments; this is 
irreversible

#   $ make clean  - to remove the generated executable as well 
as

#   all intermediate compilation files

#   $ make runclean   - to remove all output generated by the 
program

#   $ make distclean  - to clean the directory from _all_ generated

#   files (includes clean, runclean and the 
removal

#   of the generated build system)

#   $ make info   - to view this message again

#

#  Have a nice day!

#

###

-- Configuring done

-- Generating done

-- Build files have been written to: 
/Users/albertosalvadori/Codes/dealii-9.1.1/examples/mystep-18 

bash-3.2$ make relase

make: *** No rule to make target `relase'.  Stop.

bash-3.2$ make release

*Scanning dependencies of target release*

[100%] *Switching CMAKE_BUILD_TYPE to Release*

-- Autopilot invoked

-- Run   $ make info  to print a detailed help message

-- Configuring done

-- Generating done

-- Build files have been written to: 
/Users/albertosalvadori/Codes/dealii-9.1.1/examples/mystep-18 

***

*** Switched to Release mode. Now recompile with:  $ make

***

[100%] Built target release

bash-3.2$ make

*Scanning dependencies of target step-18*

[ 50%] Building CXX object CMakeFiles/step-18.dir/step-18.cc.o

[100%] *Linking CXX executable step-18*

[100%] Built target step-18

bash-3.2$ ./step-18 

Timestep 1 at time 1

  Cycle 0:

Number of active cells:   3712 (by partition: 3712)

Number of degrees of freedom: 17226 (by partition: 17226)

Assembling system... norm of rhs is Illegal instruction: 4

bash-3.2$ which mpirun

/Applications/deal.II.app/Contents/Resources/Libraries/bin/mpirun

bash-3.2$ mpirun -np 2 ./step-18

Timestep 1 at time 1

  Cycle 0:

Number of active cells:   3712 (by partition: 1972+1740)

Number of degrees of freedom: 17226 (by partition: 9396+7830)

Assembling s

Re: [deal.II] deal stopped working with latest macOS update (10.15)

[Alberto Salvadori]

It works very well. Thank you so much, Luca.
Alberto


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

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



On Sat, Dec 7, 2019 at 7:23 AM luca.heltai  wrote:

> Dear Alberto,
>
> I’ve just finished uploading a new image:
>
>
> https://github.com/dealii/dealii/releases/download/v9.1.1/dealii-9.1.1-clang-9.0.0.dmg
>
> This one is built with clang-9.0.0 (embedded in the image), and mpich. It
> is still a temporary image, because symengine could not be installed (
> www.mpfr.org is down, and symengine depends on it), and neither could
> netcdf.
>
> Can you see if this image works for you?
>
> The examples are in the path
>
>
> /Applications/deal.II.app/Contents/Resources/Libraries/share/deal.II/examples
>
> I quickly checked step-40, and it compiled and run fine.
>
> L.
>
> > On 6 Dec 2019, at 15:16, Alberto Salvadori 
> wrote:
> >
> > Hi Luca
> >
> > many thanks. I got this:
> >
> > bash-3.2$ spack arch
> > shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> > shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> > shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> > shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> > darwin-catalina-ivybridge
> >
> > Thank you, I will do as you suggest.
> >
> > Alberto
> >
> > Alberto Salvadori
> >  Dipartimento di Ingegneria Meccanica e Industriale (DIMI)
> >  Universita` di Brescia, via Branze 43, 25123 Brescia
> >  Italy
> >  tel 030 3711239
> >  fax 030 3711312
> >
> > e-mail:
> >  alberto.salvad...@unibs.it
> > web-page:
> >  http://m4lab.unibs.it/faculty.html
> >
> >
> >
> > On Fri, Dec 6, 2019 at 11:18 AM luca.heltai 
> wrote:
> > Alberto,
> >
> > this may be related to different hardware and different optimisation
> configurations.
> >
> > What’s the output of:
> >
> > spack arch
> >
> > for you, in the deal.II terminal?
> >
> > I get:
> >
> > darwin-catalina-haswell
> >
> > If you get something different, then maybe the problem is there. I don’t
> have a more recent mac (yet). It should arrive shortly, and then I should
> be able to fix it also for you, I think.
> >
> > My initial suggestion still stands. I create the package using simply
> “spack install dealii”. Try the following (in your dealii terminal):
> >
> > cd $SPACK_ROOT
> > # git pull origin develop # Optional, if you want the latest versions of
> all libraries
> > spack install dealii@9.1.1
> >
> > This will take some time, but should succeed.
> >
> > Luca.
> >
> >
> > > On 5 Dec 2019, at 16:56, Alberto Salvadori 
> wrote:
> > >
> > > This is good, perhaps you can address how did you solved the issue.
> > > I honestly have not done anything fancy:
> > >
> > >
> > > 1 - downloaded dealii-9.1.1-catalina-haswell-ro.dmg.zip
> > > 2 - drag and drop into applications
> > > 3 - open the deal.ii.app
> > > 4 - the outcome in attachment.
> > >
> > > I am using Xcode Version 11.2.1 (11B500), and macOS Catalina 10.15
> > >
> > > Thank you!
> > >
> > >
> > >
> > > Il giorno martedì 3 dicembre 2019 17:45:13 UTC+1, Ester Comellas ha
> scritto:
> > > I'm also able to run step-20 succesfully, both in debug and release
> modes.
> > >
> > > El dimarts, 3 desembre de 2019 11:33:40 UTC-5, Ester Comellas va
> escriure:
> > > Hi,
> > >
> > > I got deal.II-9.1.1 to work on macOS Catalina using the link Luca
> provided. I'm running my parallel code using mpirun and everything works
> smoothly.
> > >
> > > I don't recall the details, but I remember having some issues with
> XCode during the installation. I thought it had automatically updated
> correctly, but on closer inspection there was an error message (nothing an
> online search couldn't solve).
> > >
> > > Ester
> > >
> > >
> > > El dimarts, 3 desembre de 2019 11:08:57 UTC-5, luca.heltai va escriure:
> > > I hav

Re: [deal.II] deal stopped working with latest macOS update (10.15)

[Alberto Salvadori]

Hi Luca

many thanks. I got this:

bash-3.2$ spack arch

shell-init: error retrieving current directory: getcwd: cannot access
parent directories: Operation not permitted

shell-init: error retrieving current directory: getcwd: cannot access
parent directories: Operation not permitted

shell-init: error retrieving current directory: getcwd: cannot access
parent directories: Operation not permitted

shell-init: error retrieving current directory: getcwd: cannot access
parent directories: Operation not permitted

darwin-catalina-ivybridge

Thank you, I will do as you suggest.

Alberto


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

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



On Fri, Dec 6, 2019 at 11:18 AM luca.heltai  wrote:

> Alberto,
>
> this may be related to different hardware and different optimisation
> configurations.
>
> What’s the output of:
>
> spack arch
>
> for you, in the deal.II terminal?
>
> I get:
>
> darwin-catalina-haswell
>
> If you get something different, then maybe the problem is there. I don’t
> have a more recent mac (yet). It should arrive shortly, and then I should
> be able to fix it also for you, I think.
>
> My initial suggestion still stands. I create the package using simply
> “spack install dealii”. Try the following (in your dealii terminal):
>
> cd $SPACK_ROOT
> # git pull origin develop # Optional, if you want the latest versions of
> all libraries
> spack install dealii@9.1.1
>
> This will take some time, but should succeed.
>
> Luca.
>
>
> > On 5 Dec 2019, at 16:56, Alberto Salvadori 
> wrote:
> >
> > This is good, perhaps you can address how did you solved the issue.
> > I honestly have not done anything fancy:
> >
> >
> > 1 - downloaded dealii-9.1.1-catalina-haswell-ro.dmg.zip
> > 2 - drag and drop into applications
> > 3 - open the deal.ii.app
> > 4 - the outcome in attachment.
> >
> > I am using Xcode Version 11.2.1 (11B500), and macOS Catalina 10.15
> >
> > Thank you!
> >
> >
> >
> > Il giorno martedì 3 dicembre 2019 17:45:13 UTC+1, Ester Comellas ha
> scritto:
> > I'm also able to run step-20 succesfully, both in debug and release
> modes.
> >
> > El dimarts, 3 desembre de 2019 11:33:40 UTC-5, Ester Comellas va
> escriure:
> > Hi,
> >
> > I got deal.II-9.1.1 to work on macOS Catalina using the link Luca
> provided. I'm running my parallel code using mpirun and everything works
> smoothly.
> >
> > I don't recall the details, but I remember having some issues with XCode
> during the installation. I thought it had automatically updated correctly,
> but on closer inspection there was an error message (nothing an online
> search couldn't solve).
> >
> > Ester
> >
> >
> > El dimarts, 3 desembre de 2019 11:08:57 UTC-5, luca.heltai va escriure:
> > I have not updated to the latest version yet. They changed clang, xcode,
> and a few other things. I’m assuming that the package I built on catalina
> is no longer functional.
> >
> > I’ll get to it as quickly as I can.
> >
> > In the mean time, can you try to see if you can install deal.II using
> spack?
> >
> > L.
> >
> > > On 2 Dec 2019, at 17:24, Alberto Salvadori 
> wrote:
> > >
> > > Dear community,
> > > Luca in particular
> > >
> > > I have installed the package for Mac OS Catalina that was pointed out.
> > > In running the examples I noticed some unexpected errors
> > >
> > > Illegal instruction: 4
> > >
> > > See below.
> > >
> > > Needless to say, the very same error comes out in running my own code.
> > > Any help is appreciated
> > >
> > > Perhaps you may also address me on this: when running my old deal.ii
> 8.5.1 version, it does not work anymore.
> > > The application just does not open and if I attempt at running via
> command line, I get this:
> > >
> > >
> /Applications/deal.II-8.5.1.app/Contents/Resources/opt/openmpi-1.10.2/bin/mpirun
> -np 4 ./m4_code ../input/SE_trivial_battery_m
> > > dyld: Library not loaded:
> /Applications/deal.II.app/Contents/Resources/opt/openmpi-1.10.2/lib/libopen-rte.12.dylib
>
> > >   Referenced from:
> /Applications/deal.II-8.5.1.app/Contents/Resources/opt/openmpi-1.10.2/bin/mpirun
>
> > >   Reason: image not found
> > > Abort trap: 6
> > > tests-MacBook-Pro:Release albertosalvadori$
> 

Re: [deal.II] deal stopped working with latest macOS update (10.15)

[Alberto Salvadori]

Dear community,
Luca in particular

I have installed the package for Mac OS Catalina that was pointed out.
In running the examples I noticed some unexpected errors

Illegal instruction: 4

See below.

Needless to say, the very same error comes out in running my own code.
Any help is appreciated

Perhaps you may also address me on this: when running my old deal.ii 8.5.1
version, it does not work anymore.
The application just does not open and if I attempt at running via command
line, I get this:

/Applications/deal.II-8.5.1.app/Contents/Resources/opt/openmpi-1.10.2/bin/mpirun
-np 4 ./m4_code ../input/SE_trivial_battery_m

dyld: Library not loaded:
/Applications/deal.II.app/Contents/Resources/opt/openmpi-1.10.2/lib/libopen-rte.12.dylib

  Referenced from:
/Applications/deal.II-8.5.1.app/Contents/Resources/opt/openmpi-1.10.2/bin/mpirun

  Reason: image not found

Abort trap: 6

tests-MacBook-Pro:Release albertosalvadori$

Any suggestions on how to sort this issue out?
Thank you,

Alberto

---


bash-3.2$ which cmake

/Applications/deal.II.app/Contents/Resources/Libraries/bin/cmake

bash-3.2$ cmake -G 'Unix Makefiles' .

-- The C compiler identification is AppleClang 11.0.0.1133

-- The CXX compiler identification is AppleClang 11.0.0.1133

-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler:
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-haswell/clang-11.0.0-apple/openmpi-3.1.4-qcsz2fblznqlgt3j4u7dctfjag4kapar/bin/mpic++

-- Check for working CXX compiler:
/Applications/deal.II.app/Contents/Resources/spack/opt/spack/darwin-catalina-haswell/clang-11.0.0-apple/openmpi-3.1.4-qcsz2fblznqlgt3j4u7dctfjag4kapar/bin/mpic++
-- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Autopilot invoked

###

#

#  Project  step-20  set up with  deal.II-9.1.1  found at

#  /Applications/deal.II.app/Contents/Resources/Libraries

#

#  CMAKE_BUILD_TYPE:  Debug

#

#  You can now run

#   $ make- to compile and link the program

#   $ make run- to (compile, link and) run the program

#

#   $ make sign   - to sign the executable with the supplied
OSX developer key

#

#   $ make debug  - to switch the build type to 'Debug'

#   $ make release- to switch the build type to 'Release'

#

#   $ make edit_cache - to change (cached) configuration variables

#   and rerun the configure and generate phases
of CMake

#

#   $ make strip_comments - to strip the source files in this

#   directory off their comments; this is
irreversible

#   $ make clean  - to remove the generated executable as well
as

#   all intermediate compilation files

#   $ make runclean   - to remove all output generated by the
program

#   $ make distclean  - to clean the directory from _all_ generated

#   files (includes clean, runclean and the
removal

#   of the generated build system)

#   $ make info   - to view this message again

#

#  Have a nice day!

#

###

-- Configuring done

-- Generating done

-- Build files have been written to:
/Users/albertosalvadori/Codes/dealii-9.1.1/deal.II/examples/step-20

bash-3.2$ make release

*Scanning dependencies of target release*

[100%] *Switching CMAKE_BUILD_TYPE to Release*

-- Autopilot invoked

-- Run   $ make info  to print a detailed help message

-- Configuring done

-- Generating done

-- Build files have been written to:
/Users/albertosalvadori/Codes/dealii-9.1.1/deal.II/examples/step-20

***

*** Switched to Release mode. Now recompile with:  $ make

***

[100%] Built target release

bash-3.2$ make

*Scanning dependencies of target step-20*

[ 50%] Building CXX object CMakeFiles/step-20.dir/step-20.cc.o

[100%] *Linking CXX executable step-20*

[100%] Built target step-20

bash-3.2$ ./step-20

Illegal instruction: 4







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

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



On Fri, Oct 25, 2019 at 2:35 PM luca.heltai  wrote:

> Dear Ester,
>
> please take a look at the release page:
>
> https://github.com/dealii/dealii/releases/tag/v9.1.1
>
> 

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Thank you, Bruno.
I did notice the very same error. I do not know either why this error
emerges, the installation of hypre, PETSc was part of the spack
installation process.
Since all preliminary packages have now been installed with no further
errors, I suspect that some settings shall be redefined in the spack system
in order to configure
the installation of deal.ii. Whom should I address this question to?
Alberto


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

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



On Mon, Oct 14, 2019 at 2:58 PM Bruno Turcksin 
wrote:

> Alberto,
>
> If you look in the CMakeError.log, you can see what's the real problem:
>
>
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/lib/libpetsc.so:
> undefined reference to `hypre_ParCSRMatrixCompleteClone'
>
> Hypre is in the linking line so I am not sure what's the problem. I
> don't use PETSc and Hypre so I don't know why you have this error.
>
> Best,
>
> Bruno
>
> Le ven. 11 oct. 2019 à 14:04, Alberto Salvadori
>  a écrit :
> >
> > Sorry to invoke your help again,
> > since though I am stuck in the very final step, I wonder if anyone can
> provide some suggestions to the issue below. I really appreciate
> > Alberto
> >
> > Il giorno mercoledì 9 ottobre 2019 09:30:18 UTC+2, Alberto Salvadori ha
> scritto:
> >>
> >> Hi Denis
> >>
> >> thank you very much for pointing out to @balay. His suggestion:
> >>
> >> spack install slepc~arpack ^hypre@develop
> >>
> >> indeed works. I will prepare a short report on successful installation
> on CentOS7 through spack, summarizing all these issues.
> >> I am almost there, but another - hopefully small - problem arises and
> it is related to the installation of the deal.ii package, thus this forum
> should be appropriate.
> >> Here is the error message,
> >>
> >> ==> Installing dealii
> >>
> >> ==> Searching for binary cache of dealii
> >>
> >> ==> Warning: No Spack mirrors are currently configured
> >>
> >> ==> No binary for dealii found: installing from source
> >>
> >> ==> Using cached archive:
> /home/deal.ii/spack/var/spack/cache/dealii/dealii-9.1.1.tar.gz
> >>
> >> ==> Staging archive:
> /tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/dealii-9.1.1.tar.gz
> >>
> >> ==> Created stage in
> /tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx
> >>
> >> ==> No patches needed for dealii
> >>
> >> ==> Building dealii [CMakePackage]
> >>
> >> ==> Executing phase: 'cmake'
> >>
> >> ==> Error: ProcessError: Command exited with status 1:
> >>
> >> 'cmake'
> '/tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/spack-src'
> '-G' 'Unix Makefiles'
> '-DCMAKE_INSTALL_PREFIX:PATH=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx'
> '-DCMAKE_BUILD_TYPE:STRING=DebugRelease' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON'
> '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=FALSE'
> '-DCMAKE_INSTALL_RPATH:STRING=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/lib64;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openblas-0.3.7-2dvho7dpjd4bndibkwb7hocq2jcjri3a/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/boost-1.70.0-dqafhnyzp5sbdfre5isyyyr353vzjtgn/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/suite-sparse-5.3.0-hcb2uveywowaqvnfclinxy43ejj5r6jc/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/intel-tbb-2019.4-or4oyfysguife7miu6wpj5pvgusr4xrw/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/assimp-4.0.1-gaj2yfue2mi3pdp5i4d2s3g7fts6mrkg/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/

[deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Sorry to invoke your help again,
since though I am stuck in the very final step, I wonder if anyone can 
provide some suggestions to the issue below. I really appreciate
Alberto

Il giorno mercoledì 9 ottobre 2019 09:30:18 UTC+2, Alberto Salvadori ha 
scritto:
>
> Hi Denis
>
> thank you very much for pointing out to @balay. His suggestion:
>
> spack install slepc~arpack ^hypre@develop
>
> indeed works. I will prepare a short report on successful installation on 
> CentOS7 through spack, summarizing all these issues. 
> I am almost there, but another - hopefully small - problem arises and it 
> is related to the installation of the deal.ii package, thus this forum 
> should be appropriate.
> Here is the error message,
>
> *==>* *Installing* *dealii*
>
> *==>* Searching for binary cache of dealii
>
> *==>* Warning: No Spack mirrors are currently configured
>
> *==>* No binary for dealii found: installing from source
>
> *==>* Using cached archive: 
> /home/deal.ii/spack/var/spack/cache/dealii/dealii-9.1.1.tar.gz
>
> *==>* Staging archive: 
> /tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/dealii-9.1.1.tar.gz
>
> *==>* Created stage in 
> /tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx
>
> *==>* No patches needed for dealii
>
> *==>* Building dealii [CMakePackage]
>
> *==>* Executing phase: 'cmake'
>
> *==>* Error: ProcessError: Command exited with status 1:
>
> 'cmake' 
> '/tmp/deal.ii/spack-stage/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/spack-src'
>  
> '-G' 'Unix Makefiles' 
> '-DCMAKE_INSTALL_PREFIX:PATH=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx'
>  
> '-DCMAKE_BUILD_TYPE:STRING=DebugRelease' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' 
> '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=FALSE' 
> '-DCMAKE_INSTALL_RPATH:STRING=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/dealii-9.1.1-3idaq2jucltrqd5z5bdgsdxgfhirhrwx/lib64;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openblas-0.3.7-2dvho7dpjd4bndibkwb7hocq2jcjri3a/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/boost-1.70.0-dqafhnyzp5sbdfre5isyyyr353vzjtgn/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/suite-sparse-5.3.0-hcb2uveywowaqvnfclinxy43ejj5r6jc/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/intel-tbb-2019.4-or4oyfysguife7miu6wpj5pvgusr4xrw/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/assimp-4.0.1-gaj2yfue2mi3pdp5i4d2s3g7fts6mrkg/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/ginkgo-1.0.0-zsbnkl7a37zhjql2ts4s3eeuq56dueb4/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gsl-2.5-f7vcvzuzt3eysbwbdrmhfyakvdpzm7kv/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hdf5-1.10.5-lt5jyi3ix6dbrbblku7ygutgek7wg5w2/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/metis-5.1.0-zepovp3vvqzcirbxoqyb33fg5mm26spe/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/nanoflann-1.2.3-czda3taau7otp3ls26eezaxhag46gl2v/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/netcdf-4.7.0-tilgbdk7nwewrjy6yhrou6655uqslsvz/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/netcdf-cxx-4.2-axbx4ojpxkyvxxshyb2ucxxy6stfmfbq/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/oce-0.18.3-aobmiazqg5kugtdd6fwujbuevk3w3lcd/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/p4est-2.2-jfhddkrr4d2rgs4ebmccwx6bd6um4vfa/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/netlib-scalapack-2.0.2-ztpgqfczbercfgd3ylfyl47mnylz3lyz/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-yi7yatd5yz2pjlmxzfjmehw67ucwzyyu/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/symengine-0.4.0-wn7tujjbrfsywir3u3vkcu3qq47cdiry/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/trilinos-12.14.1-qqgitozqkocbplh4rqklzdzb5kkdkjpw/lib;/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/suite-sparse-5.3.0-hcb2uveyw

[deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

For further information, hoping this can be of use,
it turned out that the very same error in slepc installation occurs with 
gcc@7.4.0 .
This strikes me a bit, because I did install deal.ii with such a compiler 
on a ubuntu machine,  rather than CentOS7, via spack.
The issue was reported on Spack Github.
Thank you,

Alberto

Il giorno venerdì 4 ottobre 2019 12:50:24 UTC+2, Alberto Salvadori ha 
scritto:
>
> Dear community
>
> I apologize for this too long bothering on  installing deal.ii on a linux 
> machine equipped with CentOS7. I am having quite a large amount of issues, 
> perhaps related to the gcc compiler(?). 
> The very last, which I was unable to solve up to now, relates to slepc . I 
> wonder if any of you had a similar problem and in case could address its 
> solution.
>
> Here is the outcome of installation via spack:
>
> *==>* *Installing* *slepc*
>
> *==>* Searching for binary cache of slepc
>
> *==>* Warning: No Spack mirrors are currently configured
>
> *==>* No binary for slepc found: installing from source
>
> *==>* Fetching http://slepc.upv.es/download/distrib/slepc-3.12.0.tar.gz
>
>  
> 100.0%
>
> *==>* Staging archive: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/slepc-3.12.0.tar.gz
>
> *==>* Created stage in 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>
> *==>* No patches needed for slepc
>
> *==>* Building slepc [Package]
>
> *==>* Executing phase: 'install'
>
> *==>* Error: ProcessError: Command exited with status 1:
>
> './configure' 
> '--prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr'
>  
> '--with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib'
>  
> '--with-arpack-flags=-lparpack,-larpack'
>
> See build log for details:
>
>   
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-build-out.txt
>
>
> and the log (s):
>
> ==> Executing phase: 'install'
>
> ==> [2019-10-03-20:48:03.194513] './configure' 
> '--prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr'
>  
> '--with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib'
>  
> '--with-arpack-flags=-lparpack,-larpack'
>
> Checking environment... done
>
> Checking PETSc installation... 
>
> ERROR: Unable to link with PETSc
>
> ERROR: See "installed-arch-linux2-c-opt/lib/slepc/conf/configure.log" file 
> for details
>
>
>
> 
>
> Starting Configure Run at Thu Oct  3 20:48:03 2019
>
> Configure Options: 
> --prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>  
> --with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib
>  
> --with-arpack-flags=-lparpack,-larpack
>
> Working directory: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-src
>
> Python version:
>
> 2.7.16 (default, Oct  3 2019, 20:40:41) 
>
> [GCC 9.2.0]
>
> make: /usr/bin/gmake
>
> PETSc source directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s
>
> PETSc install directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s
>
> PETSc version: 3.12.0
>
> SLEPc source directory: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-src
>
> SLEPc install directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>
> SLEPc version: 3.12.0
>
>
> 
>
> Checking PETSc installation...
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>
> Running command:
>
> cd /tmp/slepc-7TxU8j;/usr/bin/gmake checklink TESTFLAGS=""
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>
> #include "petscsnes.h"
>
> int main() {
>
> Vec v; Mat m; KSP k;
>
> PetscInitializeNoArguments();
>
&

[deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

me/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj/include
  
  `pwd`/checklink.c

/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/bin/mpicc
 
-fPIC  -o checklink checklink.o  
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hypre-2.18.0-dbexk2cnwvnsjd5fm6ltw7o7q66ik3hy/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hypre-2.18.0-dbexk2cnwvnsjd5fm6ltw7o7q66ik3hy/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/superlu-dist-6.1.1-stsykz4xojdqtlnjavms2opkppopzush/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/superlu-dist-6.1.1-stsykz4xojdqtlnjavms2opkppopzush/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openblas-0.3.7-2dvho7dpjd4bndibkwb7hocq2jcjri3a/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openblas-0.3.7-2dvho7dpjd4bndibkwb7hocq2jcjri3a/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hdf5-1.10.5-lt5jyi3ix6dbrbblku7ygutgek7wg5w2/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hdf5-1.10.5-lt5jyi3ix6dbrbblku7ygutgek7wg5w2/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/parmetis-4.0.3-p3vaameiqho6enhkpjhcupk5lam6jvc6/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/parmetis-4.0.3-p3vaameiqho6enhkpjhcupk5lam6jvc6/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/metis-5.1.0-zepovp3vvqzcirbxoqyb33fg5mm26spe/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/metis-5.1.0-zepovp3vvqzcirbxoqyb33fg5mm26spe/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hwloc-1.11.11-admmx7jd2wn63yvpnbp4secnkvhpmevu/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hwloc-1.11.11-admmx7jd2wn63yvpnbp4secnkvhpmevu/lib
 
-Wl,-rpath,/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/lib
 
-L/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/lib
 
-Wl,-rpath,/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.2.0 
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.2.0 -Wl,-rpath,/usr/local/lib64 
-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib -L/usr/local/lib -lpetsc 
-lHYPRE -lsuperlu_dist -lopenblas -lhdf5hl_fortran -lhdf5_fortran -lhdf5_hl 
-lhdf5 -lparmetis -lmetis -lm -lz -lstdc++ -ldl -lmpi_usempif08 
-lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lgfortran -lm -lgfortran -lm 
-lgcc_s -lquadmath -lpthread -lquadmath -lstdc++ -ldl

/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/lib/libpetsc.so:
 
undefined reference to `hypre_ParCSRMatrixCompleteClone'

collect2: error: ld returned 1 exit status

gmake: *** [checklink] Error 1


ERROR: Unable to link with PETSc

Could it be related to make? It is still the GNU Make 3.82 . Thank you so 
much
Alberto


Il giorno martedì 1 ottobre 2019 19:02:43 UTC+2, Alberto Salvadori ha 
scritto:
>
> Dear community
>
> I have been trying to install deal.ii on a linux machine equipped with 
> CentOS7. As very clearly explained in " 
> https://github.com/dealii/dealii/wiki/deal.II-in-Spack#check-before-build 
> "
> I have installed the latest version of gcc, openmpi, cmake.
>
> [deal.ii@localhost spack]$ gcc --version
>
> gcc (GCC) 9.2.0
>
> Copyright (C) 2019 Free Software Foundation, Inc.
>
> This is free software; see the source for copying conditions.  There is NO
>
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [deal.ii@localhost spack]$ mpirun --version
>
> mpirun (Open MPI) 3.1.4
>
> [deal.ii@localhost spack]$ cmake --version
>
> cmake version 3.15.3
>
> Noticing the incompatibility with cmake, I run
>
> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4
>
>
>
>
> but I got this error:
>
>
>
> *==>* libsigsegv is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>
> *==>* m4 is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzq

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Hi Denis

thanks for your note. I figured out that by adding the path in the 
compilers.yaml file, in this way

- compiler:

environment: 

  append-path:

LD_LIBRARY_PATH: /usr/local/lib64

extra_rpaths: []

flags: {}

modules: []

operating_system: centos7

paths:

  cc: /usr/local/bin/gcc

  cxx: /usr/local/bin/g++

  f77: /usr/local/bin/gfortran

  fc: /usr/local/bin/gfortran

spec: gcc@9.2.0

target: x86_64

sorts out the issue.


Il giorno mercoledì 2 ottobre 2019 19:26:06 UTC+2, Denis Davydov ha scritto:
>
> Hi Alberto,
>
> Looks like the issue is known to Spack community: 
> https://github.com/spack/spack/issues/11224 where there is also a 
> possible source of the problem you can try as a fix (un-do on-line PR).
>
> Regards,
> Denis.
>
> On Wednesday, October 2, 2019 at 3:14:46 PM UTC+2, Bruno Turcksin wrote:
>>
>> Alberto, 
>>
>> So what happens is that spack is using gcc 9.2 like you want but it 
>> usess the libstdc++ from gcc 4.8.5 I usually spack to install a new 
>> compiler and my compilers.yaml looks like your *but* I have the path 
>> to the correct libstdc++ in my LD_LIBRARY_PATH when I load the module. 
>> So I guess you need to add that path somewhere in your compilers.yaml 
>>
>> Best, 
>>
>> Bruno 
>>
>> Le mer. 2 oct. 2019 à 08:51, Alberto Salvadori 
>>  a écrit : 
>> > 
>> > Thank you, Bruno. In fact, my aim was to use my system compiler. 
>> > Here is my  .spack/linux/packages.yaml: 
>> > 
>> > packages: 
>> > 
>> >   all: 
>> > 
>> > compiler: [gcc] 
>> > 
>> > providers: 
>> > 
>> >   mpi: [openmpi] 
>> > 
>> >   openmpi: 
>> > 
>> > version: [3.1.4] 
>> > 
>> > paths: 
>> > 
>> >   openmpi@3.1.4%gcc@9.2.0: /usr/local/ 
>> > 
>> > buildable: False 
>> > 
>> >   perl: 
>> > 
>> > paths: 
>> > 
>> >   perl@5.16.3%gcc@9.2.0: /usr 
>> > 
>> >   cmake: 
>> > 
>> > version: [3.15.3] 
>> > 
>> > paths: 
>> > 
>> >   cmake@3.15.3%gcc@9.2.0: /usr/local/ 
>> > 
>> >   hdf5: 
>> > 
>> > version: [1.8.12] 
>> > 
>> > paths: 
>> > 
>> >   hdf5@1.8.12%gcc@9.2.0: /usr 
>> > 
>> > variants: +hl+fortran 
>> > 
>> >   netcdf: 
>> > 
>> > version: [7.2.0] 
>> > 
>> > paths: 
>> > 
>> >  netcdf@7.2.0%gcc@9.2.0: /usr 
>> > 
>> >   netcdf-cxx: 
>> > 
>> > version: [4.2.8] 
>> > 
>> > paths: 
>> > 
>> >  netcdf-cxx@4.2.8%gcc@9.2.0: /usr 
>> > 
>> >   dealii: 
>> > 
>> > variants: +optflags~python 
>> > 
>> > 
>> > Shall I perhaps add something to the compiler flag (paths or so)? 
>> > Here is also my  .spack/linux/compilers.yaml 
>> > 
>> > compilers: 
>> > 
>> > - compiler: 
>> > 
>> > environment: {} 
>> > 
>> > extra_rpaths: [] 
>> > 
>> > flags: {} 
>> > 
>> > modules: [] 
>> > 
>> > operating_system: centos7 
>> > 
>> > paths: 
>> > 
>> >   cc: /usr/bin/gcc 
>> > 
>> >   cxx: /usr/bin/g++ 
>> > 
>> >   f77: /usr/bin/gfortran 
>> > 
>> >   fc: /usr/bin/gfortran 
>> > 
>> > spec: gcc@4.8.5 
>> > 
>> > target: x86_64 
>> > 
>> > - compiler: 
>> > 
>> > environment: {} 
>> > 
>> > extra_rpaths: [] 
>> > 
>> > flags: {} 
>> > 
>> > modules: [] 
>> > 
>> > operating_system: centos7 
>> > 
>> > paths: 
>> > 
>> >   cc: /usr/local/bin/gcc 
>> > 
>> >   cxx: /usr/local/bin/g++ 
>> > 
>> >   f77: /usr/local/bin/gfortran 
>> > 
>> >   fc: /usr/local/bin/gfortran 
>> > 
>> > spec: gcc@9.2.0 
>> > 
>> > target: x86_64 
>> > 
>> > 
>> > 
>> > Alberto 
>> > 
>> > 
>> > Alberto Salvadori 
>> >  Dipartimento di Ingegneria Meccanica e Industriale (DIMI) 
>> >

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Bruno, I guess the point is that cmake invokes  /lib64/libstdc++.so.6
rather than /usr/local/lib64/libstdc++.so.6
Is it correct?


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

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



On Wed, Oct 2, 2019 at 2:51 PM Alberto Salvadori 
wrote:

> Thank you, Bruno. In fact, my aim was to use my system compiler.
> Here is my  .spack/linux/packages.yaml:
>
> packages:
>
>   all:
>
> compiler: [gcc]
>
> providers:
>
>   mpi: [openmpi]
>
>   openmpi:
>
> version: [3.1.4]
>
> paths:
>
>   openmpi@3.1.4%gcc@9.2.0: /usr/local/
>
> buildable: False
>
>   perl:
>
> paths:
>
>   perl@5.16.3%gcc@9.2.0: /usr
>
>   cmake:
>
> version: [3.15.3]
>
> paths:
>
>   cmake@3.15.3%gcc@9.2.0: /usr/local/
>
>   hdf5:
>
> version: [1.8.12]
>
> paths:
>
>   hdf5@1.8.12%gcc@9.2.0: /usr
>
> variants: +hl+fortran
>
>   netcdf:
>
> version: [7.2.0]
>
> paths:
>
>  netcdf@7.2.0%gcc@9.2.0: /usr
>
>   netcdf-cxx:
>
> version: [4.2.8]
>
> paths:
>
>  netcdf-cxx@4.2.8%gcc@9.2.0: /usr
>
>   dealii:
>
> variants: +optflags~python
>
> Shall I perhaps add something to the compiler flag (paths or so)?
> Here is also my  .spack/linux/compilers.yaml
>
> compilers:
>
> - compiler:
>
> environment: {}
>
> extra_rpaths: []
>
> flags: {}
>
> modules: []
>
> operating_system: centos7
>
> paths:
>
>   cc: /usr/bin/gcc
>
>   cxx: /usr/bin/g++
>
>   f77: /usr/bin/gfortran
>
>   fc: /usr/bin/gfortran
>
> spec: gcc@4.8.5
>
> target: x86_64
>
> - compiler:
>
> environment: {}
>
> extra_rpaths: []
>
>     flags: {}
>
> modules: []
>
> operating_system: centos7
>
> paths:
>
>   cc: /usr/local/bin/gcc
>
>   cxx: /usr/local/bin/g++
>
>   f77: /usr/local/bin/gfortran
>
>   fc: /usr/local/bin/gfortran
>
> spec: gcc@9.2.0
>
> target: x86_64
>
>
> *Alberto*
>
>
>
> *Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
> (DIMI)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3711239
>  fax 030 3711312
>
> e-mail:
>  alberto.salvad...@unibs.it
> web-page:
>  http://m4lab.unibs.it/faculty.html
>
>
>
> On Wed, Oct 2, 2019 at 2:41 PM Bruno Turcksin 
> wrote:
>
>> Alberto,
>>
>> On Wednesday, October 2, 2019 at 7:24:32 AM UTC-4, Alberto Salvadori
>> wrote:
>>>
>>>
>>> Thank you so much W and D,
>>> As you pointed out there seems to be a mistake in the most recent
>>> version of perl during installation.
>>> I will propagate this to the proper communities.
>>>
>>> As Denis proposed, I went on simply tell Spack to use Perl from system:
>>>
>>> perl:
>>> paths:
>>>  perl@5.26.2%gcc@9.2.0: /usr
>>>
>>> but I bumped into another issue:
>>>
>>> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4
>>>
>>> *==>* libsigsegv is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>>>
>>> *==>* m4 is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt
>>>
>>> *==>* perl@5.16.3 : externally installed in /usr
>>>
>>> *==>* perl@5.16.3 : already registered in DB
>>>
>>> *==>* autoconf is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/autoconf-2.69-2vk2foufmuyjm2gh47u6nouxezza3p6p
>>>
>>> *==>* automake is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/automake-1.16.1-z52jybnv7ass3otkgegjazvdbbughw2q
>>>
>>> *==>* libtool is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libtool-2.4.6-mr3m4npcnryydzctugoebk2zuoav7zte
>>>
>>> *==>* adol-c is already installed in
>>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/adol-c-develop-xioth2pegguh6rb6mzfzk7zhvb2kgeue
>>>
>>> *==>* pkgconf is already inst

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Thank you, Bruno. In fact, my aim was to use my system compiler.
Here is my  .spack/linux/packages.yaml:

packages:

  all:

compiler: [gcc]

providers:

  mpi: [openmpi]

  openmpi:

version: [3.1.4]

paths:

  openmpi@3.1.4%gcc@9.2.0: /usr/local/

buildable: False

  perl:

paths:

  perl@5.16.3%gcc@9.2.0: /usr

  cmake:

version: [3.15.3]

paths:

  cmake@3.15.3%gcc@9.2.0: /usr/local/

  hdf5:

version: [1.8.12]

paths:

  hdf5@1.8.12%gcc@9.2.0: /usr

variants: +hl+fortran

  netcdf:

version: [7.2.0]

paths:

 netcdf@7.2.0%gcc@9.2.0: /usr

  netcdf-cxx:

version: [4.2.8]

paths:

 netcdf-cxx@4.2.8%gcc@9.2.0: /usr

  dealii:

variants: +optflags~python

Shall I perhaps add something to the compiler flag (paths or so)?
Here is also my  .spack/linux/compilers.yaml

compilers:

- compiler:

environment: {}

extra_rpaths: []

flags: {}

modules: []

operating_system: centos7

paths:

  cc: /usr/bin/gcc

  cxx: /usr/bin/g++

  f77: /usr/bin/gfortran

  fc: /usr/bin/gfortran

spec: gcc@4.8.5

target: x86_64

- compiler:

environment: {}

extra_rpaths: []

flags: {}

modules: []

operating_system: centos7

paths:

  cc: /usr/local/bin/gcc

  cxx: /usr/local/bin/g++

  f77: /usr/local/bin/gfortran

  fc: /usr/local/bin/gfortran

spec: gcc@9.2.0

target: x86_64


*Alberto*



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

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



On Wed, Oct 2, 2019 at 2:41 PM Bruno Turcksin 
wrote:

> Alberto,
>
> On Wednesday, October 2, 2019 at 7:24:32 AM UTC-4, Alberto Salvadori wrote:
>>
>>
>> Thank you so much W and D,
>> As you pointed out there seems to be a mistake in the most recent version
>> of perl during installation.
>> I will propagate this to the proper communities.
>>
>> As Denis proposed, I went on simply tell Spack to use Perl from system:
>>
>> perl:
>> paths:
>>  perl@5.26.2%gcc@9.2.0: /usr
>>
>> but I bumped into another issue:
>>
>> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4
>>
>> *==>* libsigsegv is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>>
>> *==>* m4 is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt
>>
>> *==>* perl@5.16.3 : externally installed in /usr
>>
>> *==>* perl@5.16.3 : already registered in DB
>>
>> *==>* autoconf is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/autoconf-2.69-2vk2foufmuyjm2gh47u6nouxezza3p6p
>>
>> *==>* automake is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/automake-1.16.1-z52jybnv7ass3otkgegjazvdbbughw2q
>>
>> *==>* libtool is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libtool-2.4.6-mr3m4npcnryydzctugoebk2zuoav7zte
>>
>> *==>* adol-c is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/adol-c-develop-xioth2pegguh6rb6mzfzk7zhvb2kgeue
>>
>> *==>* pkgconf is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/pkgconf-1.6.1-qtpkfoaa5ae54s4icmqie5hbtz6murqx
>>
>> *==>* ncurses is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/ncurses-6.1-awd5putjsuzsddipc35vxiupdjicseao
>>
>> *==>* zlib is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/zlib-1.2.11-fa7l75havytsbgz77sh6yyzvqgmmm5dj
>>
>> *==>* openssl is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openssl-1.1.1c-ou63dp5nv43t2vudcv44rc753i7yecl2
>>
>> *==>* *Installing* *cmake*
>>
>> *==>* Searching for binary cache of cmake
>>
>> *==>* Warning: No Spack mirrors are currently configured
>>
>> *==>* No binary for cmake found: installing from source
>>
>> *==>* Using cached archive:
>> /home/deal.ii/spack/var/spack/cache/cmake/cmake-3.9.4.tar.gz
>>
>> *==>* Staging archive:
>> /tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/cmake-3.9.4.tar.gz
>>
>> *==>* Created stage in
>> /tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

mand.o cmForEachCommand.o
cmFunctionCommand.o cmGeneratedFileStream.o cmGeneratorExpression.o
cmGeneratorExpressionContext.o cmGeneratorExpressionDAG

Checker.o cmGeneratorExpressionEvaluationFile.o
cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o
cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o
cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyC

ommand.o cmGetFilenameComponentCommand.o cmGetPropertyCommand.o
cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o
cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o
cmGlobalUnixMakefileGenerator3.o cmHexFi

leConverter.o cmIfCommand.o cmIncludeCommand.o
cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o
cmInstallCommand.o cmInstallCommandArguments.o
cmInstallDirectoryGenerator.o cmInstallExportGenerator.o
cmInstallFilesCommand.o

cmInstallFilesGenerator.o cmInstallGenerator.o
cmInstallScriptGenerator.o cmInstallTargetGenerator.o
cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o
cmLinkLineComputer.o cmListCommand.o cmListFileCache.o cmLocalCommo

nGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o
cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o
cmMakefile.o cmMakefileExecutableTargetGenerator.o
cmMakefileLibraryTargetGenerator.o cmMakefileTargetGene

rator.o cmMakefileUtilityTargetGenerator.o
cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o
cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o
cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsComman

d.o cmPathLabel.o cmPolicies.o cmProcessOutput.o
cmProjectCommand.o cmProperty.o cmPropertyDefinition.o
cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o
cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateAr

gumentsCommand.o cmSetCommand.o
cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o
cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o
cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o
cmSourceFileLocati

on.o cmState.o cmStateDirectory.o cmStateSnapshot.o
cmStringCommand.o cmSubdirCommand.o cmSystemTools.o cmTarget.o
cmTargetLinkLibrariesCommand.o cmTargetPropertyComputer.o cmTest.o
cmTestGenerator.o cmTimestamp.o cmTryCompileCommand.o cmT

ryRunCommand.o cmUnexpectedCommand.o cmUnsetCommand.o
cmVersion.o cmWhileCommand.o cmWorkingDirectory.o cmake.o cmakemain.o
cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmExprLexer.o
cmExprParser.o cmListFileLexer.o Directory

.o EncodingCXX.o FStream.o Glob.o RegularExpression.o
SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o -o
cmake

 197
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/spack-src/Bootstrap.cmk/cmake:
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfb

q4/spack-src/Bootstrap.cmk/cmake)

 198
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/spack-src/Bootstrap.cmk/cmake:
/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4

/spack-src/Bootstrap.cmk/cmake)

 199
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/spack-src/Bootstrap.cmk/cmake:
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfb

q4/spack-src/Bootstrap.cmk/cmake)

 200
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/spack-src/Bootstrap.cmk/cmake:
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by
/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfb

q4/spack-src/Bootstrap.cmk/cmake)

 201-

  >> 202Error when bootstrapping CMake:

 203Problem while running initial CMake

 204-


See build log for details:


/tmp/deal.ii/spack-stage/cmake-3.9.4-jy2ih5ctlebz57xqk7kvgzv22tabfbq4/spack-build-out.txt




Is it perhaps due to a conflict between cmake and the gcc compiler
versions? Can you perhaps address me how to sort this out?

I appreciate,
Alberto



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

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



On Wed, Oct 2, 2019 at 1:19 PM Alberto Salvadori 
wrote:

> Thank you so much W and D,
> As you pointed out there seems to be a mistake in the most recent version
> of perl during installation.
> I will point this out in 

Re: [deal.II] Re: error during installation with spack on CentOS7

[Alberto Salvadori]

Thank you so much W and D,
As you pointed out there seems to be a mistake in the most recent version
of perl during installation.
I will point this out in the proper communities.

As Denis proposed






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

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



On Wed, Oct 2, 2019 at 6:26 AM Denis Davydov  wrote:

> Hi Alberto,
>
> Such issues should ideally be reported to Perl, because that's the issue
> with their package. Or at least to Spack in a hope that the community can
> come up with some patch to workaround the build issue in Perl.
>
> For you to go on simply tell Spack to use Perl from system:
>
> perl:
> paths:
>  perl@5.26.2%gcc@9.2.0: /usr
>
> As for the Blas/Lapack, IMO there is no reason to use system provided one
> in your case.
> You get more control of threading, compiler flags, etc through Spack and
> it does not take ages to build either.
>
> p.s. there are some examples of config files for Spack on various HPC
> systems, if that helps:
>
> https://github.com/spack/spack-configs
> https://github.com/eth-cscs/production/tree/master/spack/daint
> https://ceed.exascaleproject.org/ceed-1.0/
> https://gitlab.dkrz.de/m300488/icon-bootstrap/tree/master/config/sites
>
>
> Denis.
>
> On Tuesday, October 1, 2019 at 7:02:43 PM UTC+2, Alberto Salvadori wrote:
>>
>> Dear community
>>
>> I have been trying to install deal.ii on a linux machine equipped with
>> CentOS7. As very clearly explained in "
>> https://github.com/dealii/dealii/wiki/deal.II-in-Spack#check-before-build
>> "
>> I have installed the latest version of gcc, openmpi, cmake.
>>
>> [deal.ii@localhost spack]$ gcc --version
>>
>> gcc (GCC) 9.2.0
>>
>> Copyright (C) 2019 Free Software Foundation, Inc.
>>
>> This is free software; see the source for copying conditions.  There is NO
>>
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> [deal.ii@localhost spack]$ mpirun --version
>>
>> mpirun (Open MPI) 3.1.4
>>
>> [deal.ii@localhost spack]$ cmake --version
>>
>> cmake version 3.15.3
>>
>> Noticing the incompatibility with cmake, I run
>>
>> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4
>>
>>
>>
>>
>> but I got this error:
>>
>>
>>
>> *==>* libsigsegv is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>>
>> *==>* m4 is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt
>>
>> *==>* pkgconf is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/pkgconf-1.6.1-qtpkfoaa5ae54s4icmqie5hbtz6murqx
>>
>> *==>* ncurses is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/ncurses-6.1-awd5putjsuzsddipc35vxiupdjicseao
>>
>> *==>* readline is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/readline-7.0-tftx53fdsvjjtfzsfadhzrplo7w2yf46
>>
>> *==>* gdbm is already installed in
>> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gdbm-1.18.1-chqdjuttuqyeyrmsnm6yistdpigsguwq
>>
>> *==>* *Installing* *perl*
>>
>> *==>* Searching for binary cache of perl
>>
>> *==>* Warning: No Spack mirrors are currently configured
>>
>> *==>* No binary for perl found: installing from source
>>
>> *==>* Using cached archive:
>> /home/deal.ii/spack/var/spack/cache/perl/perl-5.26.2.tar.gz
>>
>> *==>* Using cached archive:
>> /home/deal.ii/spack/var/spack/cache/perl/cpanm-5.26.2.tar.gz
>>
>> *==>* Using cached archive:
>> /home/deal.ii/spack/var/spack/cache/perl/perl-5.26.1-guard_old_libcrypt_fix.patch
>>
>> *==>* Staging archive:
>> /tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/perl-5.26.2.tar.gz
>>
>> *==>* Created stage in
>> /tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3
>>
>> *==>* Staging archive:
>> /tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3/App-cpanminus-1.7042.tar.gz
>>
>> *==>* Created stage in
>> /tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3

[deal.II] error during installation with spack on CentOS7

[Alberto Salvadori]

Dear community

I have been trying to install deal.ii on a linux machine equipped with 
CentOS7. As very clearly explained in 
" https://github.com/dealii/dealii/wiki/deal.II-in-Spack#check-before-build 
"
I have installed the latest version of gcc, openmpi, cmake.

[deal.ii@localhost spack]$ gcc --version

gcc (GCC) 9.2.0

Copyright (C) 2019 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[deal.ii@localhost spack]$ mpirun --version

mpirun (Open MPI) 3.1.4

[deal.ii@localhost spack]$ cmake --version

cmake version 3.15.3

Noticing the incompatibility with cmake, I run

[deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4




but I got this error:



*==>* libsigsegv is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463

*==>* m4 is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt

*==>* pkgconf is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/pkgconf-1.6.1-qtpkfoaa5ae54s4icmqie5hbtz6murqx

*==>* ncurses is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/ncurses-6.1-awd5putjsuzsddipc35vxiupdjicseao

*==>* readline is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/readline-7.0-tftx53fdsvjjtfzsfadhzrplo7w2yf46

*==>* gdbm is already installed in 
/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gdbm-1.18.1-chqdjuttuqyeyrmsnm6yistdpigsguwq

*==>* *Installing* *perl*

*==>* Searching for binary cache of perl

*==>* Warning: No Spack mirrors are currently configured

*==>* No binary for perl found: installing from source

*==>* Using cached archive: 
/home/deal.ii/spack/var/spack/cache/perl/perl-5.26.2.tar.gz

*==>* Using cached archive: 
/home/deal.ii/spack/var/spack/cache/perl/cpanm-5.26.2.tar.gz

*==>* Using cached archive: 
/home/deal.ii/spack/var/spack/cache/perl/perl-5.26.1-guard_old_libcrypt_fix.patch

*==>* Staging archive: 
/tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/perl-5.26.2.tar.gz

*==>* Created stage in 
/tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3

*==>* Staging archive: 
/tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3/App-cpanminus-1.7042.tar.gz

*==>* Created stage in 
/tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3

*==>* Moving resource stage

source : 
/tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src/

destination : 
/tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src/cpanm/cpanm

*==>* Applied patch 
https://src.fedoraproject.org/rpms/perl/raw/004cea3a67df42e92ffdf4e9ac36d47a3c6a05a4/f/perl-5.26.1-guard_old_libcrypt_fix.patch

*==>* Building perl [Package]

*==>* Executing phase: 'configure'

*==>* Executing phase: 'build'

*==>* Error: ProcessError: Command exited with status 2:

'make' '-j12'


17 errors found in build log:

 5085
LD_LIBRARY_PATH=/tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src
 
./miniperl -Ilib make_ext.pl lib/auto/PerlIO/encoding/encoding.so  
MAKE="make" LIBPERL_A=libperl.so LINKTYPE=dynamic

 5086mv Base64.xsc Base64.c

 5087cc -c   -D_REENTRANT -D_GNU_SOURCE 
-DAPPLLIB_EXP="/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/lib/perl5"
 
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/home/

 
deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gdbm-1.18.1-chqdjuttuqyeyrmsnm6yistdpigsguwq/include
 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall 
-Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings 
-O2  

  -DVERSION=\"3.15\" -DXS_VERSION=\"3.15\" -fPIC "-I../.."   
Base64.c

 5088In file included from ../../perl.h:5644,

 5089 from IO.xs:12:

 5090IO.xs: In function 'XS_IO__Poll__poll':

  >> 5091IO.xs:321:51: error: invalid application of 'sizeof' to 
incomplete type 'struct pollfd'

 5092  321 | SV *tmpsv = sv_2mortal(NEWSV(999,nfd * 
sizeof(struct pollfd)));

 5093  |   
^~

 5094../../embed.h:596:46: note: in definition of macro 'sv_2mortal'

 5095  596 | #define sv_2mortal(a)  Perl_sv_2mortal(aTHX_ a)

 5096  |  ^

 5097../../handy.h:2258:22: note: in expansion of macro 'newSV'

 5098 2258 | #define NEWSV(x,len) newSV(len)

 5099  |  ^

 5100IO.xs:321:28: note: in expansion of macro 'NEWSV'

 5101  321 | SV *tmpsv = sv_2mortal(NE

Re: [deal.II] Extracting volume data to the boundary

[Alberto Salvadori]

Thank you very much, Luca.

Alberto Salvadori
Associate Professor 
DIMI, University of Brescia, Italy


> On 11 Sep 2019, at 08:38, luca.heltai  wrote:
> 
> Alberto, 
> 
> be aware of the fact that, when you extract the boundary mesh, the 
> orientation of the cells may be different w.r.t. to the corresponding face on 
> the volumetric mesh. In other words, using 
> 
> FEValues  codim_one(…);
> FEFaceValuescodim_zero(…);
> 
> codim_one.reinit(codim_one_cell);
> codim_zero.reinit(codmi_zero_cell, corresponding_face);
> 
> in general, you will *NOT* get the same ordering of the quadrature points, 
> and of the dof indices.
> 
> In the past, we proceeded by constructing a dof_map between codim zero and 
> codim one (instead of trying to assemble together fe values coming from grids 
> with different dimensions), or by constructing (by hand) the permutation of 
> the dof indices.
> 
> As far as your question is concerned:
> 
>  c1_to_c0 = GridGenerator::extract_boundary_mesh(triangulation, c1_tria);
> 
>  // map volume mesh face -> codimension 1 mesh cell
>  for (auto c1_cell : c1_tria.active_cell_iterators())
>c0_to_c1[c1_to_c0[c1_cell]] = c1_cell;
> 
>  // generate a mapping that maps codimension-1 cells
>  // to codimension-0 cells and faces
>  for (auto cell :
>   triangulation
> .active_cell_iterators()) // disp_dof.active_cell_iterators())
>for (unsigned int f = 0; f < GeometryInfo::faces_per_cell; ++f)
>  if (cell->face(f)->at_boundary())
>{
>  auto c1_cell  = c0_to_c1[cell->face(f)];
>  c1_to_c0_cells_and_faces[c1_cell] = {cell, f};
>}
> 
> 
> L.
> 
> 
>> On 10 Sep 2019, at 12:15, Alberto Salvadori  
>> wrote:
>> 
>> Thank you very much, Wolfgang, crystal clear as always.
>> 
>> It is still unclear to me, though, how to reinit() the FEFaceValues 
>> for the cell making use of the 
>> map returned by the extract_boundary_mesh() function. I learned to reinit 
>> FEFaceValues as:
>> 
>> fe_face_values.reinit (cell, face_number);
>> 
>> Is there a "simple way" to get the (volume) cell iterator and the 
>> face_number from the 
>> parallel::shared::Triangulation::face_iterator in the map returned by 
>> the extract_boundary_mesh() function? 
>> 
>> Or shall I use a different way to reinit FEFaceValues?
>> 
>> Thank you
>> 
>> Alberto
>> 
> 
> -- 
> 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/1DD9B280-CD2F-4C83-81FE-3FC00A522B91%40gmail.com.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/941628FF-A719-47F7-BF8F-5D55966EAD98%40unibs.it.

Re: [deal.II] Re: Extracting volume data to the boundary

[Alberto Salvadori]

Thank you very much, Wolfgang, crystal clear as always.

It is still unclear to me, though, how to reinit() the FEFaceValues
for the cell making use of the
map returned by the extract_boundary_mesh() function. I learned to reinit
FEFaceValues as:

fe_face_values.reinit (cell, face_number);

Is there a "simple way" to get the (volume) cell iterator and the
face_number from the
parallel::shared::Triangulation::face_iterator in the map returned by
the extract_boundary_mesh() function?

Or shall I use a different way to reinit FEFaceValues?

Thank you

Alberto



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

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



On Mon, Sep 9, 2019 at 7:09 PM Wolfgang Bangerth 
wrote:

>
> > In solving a Laplace-Beltrami problem on an advecting surface one should
> > identify the Gauss points on the manifold dim-1 cell and retrieve at
> > such locations relevant information from the solution of the advection
> > problem, using the dim dof_handler of the volume. I wonder how to
> > connect a manifold dim-1 cell to the volumetric cell it was extracted
> > from. The GridGenerator::extract_boundary_mesh method seem to provide
> > some information, since "it returns A map that for each cell of the
> > surface mesh (key) returns an iterator to the corresponding face of a
> > cell of the volume mesh (value). " . I am not sure how I can use this
> > map to link a manifold cell to the corresponding volume cell.
>
> Alberto,
> the way this is supposed to be used is as follows:
>
> When you are assembling the linear system for the surface problem, you
> will have an FEValues object for the surface shape functions.
> You initialize it with a Quadrature.
>
> But then you also need to evaluate the volume solution on the same
> quadrature points. You do this by creating an FEFaceValues object,
> which requires you to also provide a Quadrature object -- which
> you want to choose the same as above.
>
> Now, if you need the volume solution when assembling something for the
> surface problem, you are sitting on a cell of the surface mesh; use the
> map returned by the extract_boundary_mesh() function to obtain what the
> corresponding face of the volume mesh is and reinit() the FEFaceValues
> for that cell. You can then use the FEFaceValues object to evaluate the
> volume solution at the same quadrature points as you use for the
> FEValues object of the surface mesh. The only thing you may have to pay
> attention to is that the surface cell may be inverted compared to the
> volume cell's face -- in which case the quadrature points of the two
> objects match, but are in a different order. You'll have to translate
> between these permutations then.
>
> 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/a60b9b5e-fef3-fd88-5e54-65bed698a5bc%40colostate.edu
> .
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/CABcATpdDUXf0bY%3DLW9%2BCeBe7JEGZR2dn2-hxLqTushwT2a0zJw%40mail.gmail.com.

[deal.II] Re: Extracting volume data to the boundary

[Alberto Salvadori]

 "  << std::flush;

*for* (; 
manifoldcells_to_volumecells_it!=manifoldcells_to_volumecells_end; 
++manifoldcells_to_volumecells_it)

  *this*->pcout <<  "[ " << manifoldcells_to_volumecells_it->first->*id*() 
<< ", " << manifoldcells_to_volumecells_it->second->*id*() << " ], " << std
::flush;

*this*->pcout <<  "\n done. \n"  << std::flush;



  }

  

  *// debug*

  *// std::exit( 0 );*

  

}

 
Comments and suggestions are very welcome.
Thank you in advance

Alberto


Il giorno sabato 7 settembre 2019 12:09:30 UTC+2, Alberto Salvadori ha 
scritto:
>
> Dear community
>
> I apologize if the question was too generic. I attempt here to be more 
> precise, asking for some suggestions.
>
> In solving a Laplace-Beltrami problem on an advecting surface one should 
> identify the Gauss points on the manifold dim-1 cell and retrieve at such 
> locations relevant information from the solution of the advection problem, 
> using the dim dof_handler of the volume. I wonder how to connect a manifold 
> dim-1 cell to the volumetric cell it was extracted from. The 
> GridGenerator::extract_boundary_mesh method seem to provide some 
> information, since "it returns A map that for each cell of the surface mesh 
> (key) returns an iterator to the corresponding face of a cell of the volume 
> mesh (value). " . I am not sure how I can use this map to link a manifold 
> cell to the corresponding volume cell. 
>
> Any help is very much appreciated. Thanks!
>
> Alberto
>
>
>
> Il giorno martedì 3 settembre 2019 18:36:59 UTC+2, Alberto Salvadori ha 
> scritto:
>>
>> Dear community
>>
>> I am trying to find a good way to deal with the following problem.
>>
>> I am interested in a Laplace-Beltrami simulation (say with unknown scalar 
>> field c) on a surface that advects (with displacement field u) enclosesing 
>> a volume of say elastic material.
>> The two problems are per se uncoupled, but for the geometrical evolution. 
>> In this regard, one may solve separately for displacements in the volume 
>> and for c on the surface, once the latter is informed on the displacement 
>> field (and related gradients) on the surface nodes (and Gauss points). 
>> Extracting the surface mesh from the volume is quite simple. Which is 
>> though the best way to extract (project) the displacement solution on the 
>> boundary? Any suggestion/ hint?
>>
>> Many thanks,
>> Alberto
>>
>
-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/57f2de0e-b449-4cbd-9332-3c66a1b078e7%40googlegroups.com.

[deal.II] Re: Extracting volume data to the boundary

[Alberto Salvadori]

Dear community

I apologize if the question was too generic. I attempt here to be more 
precise, asking for some suggestions.

In solving a Laplace-Beltrami problem on an advecting surface one should 
identify the Gauss points on the manifold dim-1 cell and retrieve at such 
locations relevant information from the solution of the advection problem, 
using the dim dof_handler of the volume. I wonder how to connect a manifold 
dim-1 cell to the volumetric cell it was extracted from. The 
GridGenerator::extract_boundary_mesh method seem to provide some 
information, since "it returns A map that for each cell of the surface mesh 
(key) returns an iterator to the corresponding face of a cell of the volume 
mesh (value). " . I am not sure how I can use this map to link a manifold 
cell to the corresponding volume cell. 

Any help is very much appreciated. Thanks!

Alberto



Il giorno martedì 3 settembre 2019 18:36:59 UTC+2, Alberto Salvadori ha 
scritto:
>
> Dear community
>
> I am trying to find a good way to deal with the following problem.
>
> I am interested in a Laplace-Beltrami simulation (say with unknown scalar 
> field c) on a surface that advects (with displacement field u) enclosesing 
> a volume of say elastic material.
> The two problems are per se uncoupled, but for the geometrical evolution. 
> In this regard, one may solve separately for displacements in the volume 
> and for c on the surface, once the latter is informed on the displacement 
> field (and related gradients) on the surface nodes (and Gauss points). 
> Extracting the surface mesh from the volume is quite simple. Which is 
> though the best way to extract (project) the displacement solution on the 
> boundary? Any suggestion/ hint?
>
> Many thanks,
> Alberto
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/df1ce3d5-ecbe-41f8-907e-805d334417fb%40googlegroups.com.

[deal.II] Extracting volume data to the boundary

[Alberto Salvadori]

Dear community

I am trying to find a good way to deal with the following problem.

I am interested in a Laplace-Beltrami simulation (say with unknown scalar 
field c) on a surface that advects (with displacement field u) enclosesing 
a volume of say elastic material.
The two problems are per se uncoupled, but for the geometrical evolution. 
In this regard, one may solve separately for displacements in the volume 
and for c on the surface, once the latter is informed on the displacement 
field (and related gradients) on the surface nodes (and Gauss points). 
Extracting the surface mesh from the volume is quite simple. Which is 
though the best way to extract (project) the displacement solution on the 
boundary? Any suggestion/ hint?

Many thanks,
Alberto

-- 


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/b339eeb5-0246-4f1d-bf7d-ab39dfa630fd%40googlegroups.com.

Re: [deal.II] Re: Application for the use in continuum mechanics

[Alberto Salvadori]

HI Lukas

We at m4lab (m4lab.unibs.it) have been writing a Constitutive model library and 
a set of “steps”, with the same style of deal.ii steps 18 and 44. 

So far, we did not made them public but if this may interest you we can 
definitely share the code and then will see. 

Did you look into PRISMS at Michigan state? Looks similar to what you are 
looking for.

Alberto

Alberto Salvadori
Associate Professor 
DIMI, University of Brescia, Italy


> On 16 Aug 2019, at 10:57, Lukas Lamm  wrote:
> 
> Hey Lucas,
> 
> thanks for your response. I was actually searching for some application 
> somehow similar to FE software like e.g. FEAP or Deadalon, where you can e.g. 
> easily implement any desired material model but do not have to care about the 
> whole assembly and solution process. At least not if you do not explicitly 
> want to. Writing it by myself would not be a problem I guess, but would still 
> be some effort. Therefore, I thought that maybe someone alse is already 
> working on such a package and I could participate in the development process.
> 
> Best regards,
> Lukas
> 
> 
> Am Freitag, 16. August 2019 10:11:24 UTC+2 schrieb Lucas Campos:
>> 
>> Dear Lukas,
>> 
>> I am working with Continuum Mechanics, although I would not call my research 
>> "more advanced" than the stuff in tutorial-44, at least from a computational 
>> point of view. Mostly, growing materials. Could you be a bit more specific 
>> on your needs?
>> 
>> Bests,
>> Lucas
>> 
>>> On Thursday, 15 August 2019 09:45:12 UTC+2, Lukas Lamm wrote:
>>> Dear dealii community,
>>> 
>>> 
>>> 
>>> first of all I would like to thank you for this wonderful piece of work you 
>>> all have produced. It is by far the most well designed and documented open 
>>> source FE library I have seen so far.
>>> 
>>> 
>>> 
>>> I am working in the field of computational continuum mechanics and was 
>>> wondering, if anyone of you know about (or is even working on) an 
>>> application built on top of dealii for the use in continuum mechanics. 
>>> Something like tutorial 44, but more sophisticated and advanced. If there 
>>> is anything out there, I would be really happy to recieve a short feedback 
>>> with links to github etc.
>>> 
>>> 
>>> 
>>> Thank you very much for your help.
>>> 
>>> 
>>> 
>>> Mit freundlichen Grüßen / kind regards,
>>> 
>>> 
>>> 
>>> Lukas Lamm, M. Sc.
>>> 
>>> Research Associate / Ph.D. candidate
>>> 
>>>  RWTH Aachen University
>>> Institute of Applied Mechanics
>>> Mies-van-der-Rohe-Str. 1 Room 308d
>>> D-52074 Aachen
>>> 
>>> Phone: +49(0)241 80 25006
>>> Mail: luka...@ifam.rwth-aachen.de 
>>> Web:www.ifam.rwth-aachen.de
> 
> -- 
> 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/ca8fda63-788b-419f-94fc-705ef3ec85f9%40googlegroups.com.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/4E88D7CA-B6AC-4324-95A3-30526E9080B9%40unibs.it.

Re: [deal.II] Re: deal.II User and Developer Workshop: August 6-9, 2019

[Alberto Salvadori]

> Dear Wolfgang and Timo,

I believe this is a very good idea. Since I cannot attend the workshop I do 
support Steve's request.

Cheers 
Alberto

Alberto Salvadori
Associate Professor 
DIMI, University of Brescia, Italy


> On 20 Jun 2019, at 19:32, Stephen DeWitt  wrote:
> 
> Dear Wolfgang and Timo,
> Would it be possible to record some or all of the presentations at the 
> workshop? Due to a conflict I won't be able to attend, but I would still be 
> very interested in hearing the talks/discussions at the workshop.
> 
> Best,
> Steve
> 
>> On Wednesday, April 10, 2019 at 12:18:43 AM UTC-4, Wolfgang Bangerth wrote:
>> 
>> Dear deal.II users and developers, 
>> 
>> The 
>> Seventh deal.II Users' and Developers' workshop 
>> will be held August 6-9, 2019 in Fort Collins, Colorado, USA. The 
>> intent of this workshop is to discuss applications and tools using 
>> deal.II, as well as future directions of the library itself. 
>> 
>> We invite proposals for talks and discussion topics by users and 
>> existing developers in the following areas: 
>>   - Use cases and applications of the library. 
>>   - What users think would be useful directions for the library to go into, 
>> things that are missing, and possibly getting people together who can 
>> help 
>> implement those parts. 
>>   - Newer parts of the library (e.g., geometry descriptions, large parallel 
>> computations, etc.) and how these could help in your programs. 
>> A significant part of the time will be set aside for "hackathon"- or "code 
>> jam"-style sessions where people can ask questions, work on their codes 
>> with others, and receive help from experienced users. 
>> 
>> Registration: 
>> For workshop and registration information, see 
>>https://dealii.org/workshop-2019/ 
>> 
>> Deadline for registration: May 5, 2019. Participation is capped at 
>> around 60. 
>> 
>> Travel support: 
>> A limited amount of (domestic) travel support is available courtesy of the 
>> National Science Foundation, and will be given on a first come first serve 
>> basis, with preference to undergraduate and graduate students. If you need 
>> support, please state so in your registration. 
>> 
>> The organizers 
>>Wolfgang Bangerth (Colorado State University, bang...@colostate.edu) 
>>Timo Heister (University of Utah, hei...@sci.utah.edu) 
>> 
>> -- 
>>  
>> 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/c4e5da4d-1103-4a1c-9f44-abc3fb009981%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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/9A709672-2993-4F72-8E9C-66A42E3D61E3%40unibs.it.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Post doc position at the University of Brescia

[Alberto Salvadori]

Dear community,

There is an open call for a post-doc position at the University of Brescia, 
Italy, at the m4lab ( multiscale mechanics and multi physics of materials). The 
candidate will work with international colleagues on the deal.ii implementation 
of crystal plasticity models for high strength steels. 

The position, which runs for one year and will be renewed afterwards, is 
sponsored by a major steel maker company . 

Interested candidates are invited to send an email to

alberto.salvad...@unibs.it

At their earliest convenience.

Kind regards,

Alberto
-- 


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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

Very good, thanks!

Sent from my iPad

> On 24 Oct 2018, at 11:08, Denis Davydov  wrote:
> 
> Hi Alberto,
> 
> I figured out what's happening. The issue you see is NOT related to what me 
> and JP suggested.
> It is a separate issues related to constraints on compilers from 
> suite-sparse. I created a PR in spack to clarify this:
> https://github.com/spack/spack/pull/9622/ 
> Once it's merged, you would not see the "conretization" error, but you should 
> see that you can't build the most recent suite-sparse with older GCC.
> The end solution would be the same: 
> (i) you need to choose suite-sparse@5.1.0 which can be built with GCC 4.8.5
> (ii) you need to choose older version of PETSc which support older versions 
> of suite-sparse.
> 
> Regards,
> Denis.
> 
>> On Monday, October 22, 2018 at 7:50:45 AM UTC+2, Alberto Salvadori wrote:
>> Dear community
>> 
>> I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
>> After typing
>> 
>> spack install --test=root dealii
>> 
>> I see this error:
>> 
>> ==> Error: An unsatisfiable version constraint has been detected for spec:
>> 
>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>> arch=linux-centos7-x86_64 
>> 
>> 
>> while trying to concretize the partial spec:
>> 
>> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease 
>> ~cuda cuda_arch= 
>> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>>  arch=linux-centos7-x86_64 
>> ^adol-c@2.6.4:
>> ^arpack-ng+mpi
>> ^mpi
>> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
>> threads=none ~virtual_machine arch=linux-centos7-x86_64 
>> ^assimp
>> 
>> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
>> ^bzip2
>> ^diffutils
>> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
>> arch=linux-centos7-x86_64 
>> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
>> arch=linux-centos7-x86_64 
>> ^ncurses
>> ^pkgconfig
>> ^openssl
>> ^perl@5.14.0:
>> ^gdbm
>> ^readline
>> ^gmsh+netgen+oce+tetgen
>> ^gmp
>> ^autoconf
>> ^m4@1.4.6:
>> ^automake
>> ^libtool@2.4.2:
>> ^netgen
>> ^oce
>> ^tetgen
>> ^hdf5@1.8.9:+hl+mpi
>> ^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
>> arch=linux-centos7-x86_64 
>> ^metis@5:~int64+real64
>> ^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64 
>> ^nanoflann
>> ^netcdf+mpi
>> ^p4est
>> ^sundials~pthread
>> ^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
>> ^glm
>> ^matio
>> 
>> 
>> dealii requires suite-sparse version :5.1.0, but spec asked for 5.3.0
>> 
>> I wonder which is the source of the error and which files ( 
>> ~/.spack/linux/packages.yaml perhaps?)
>> shall I edit to sort out the issue.
>> 
>> Many thanks in advance
>> 
>> Alberto
>> 
>> 
>> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

Hi Denis,
thanks! Here is my history file.

   90  cd Pubblici/
   91  mkdir spack
   94  cd spack/
   95  git clone https://github.com/spack/spack.git .
   96  git checkout develop
   97  git reset --hard e38f39e4eafeaa6daed580cece935141e5d8f04b
   98  spack install dealii
   99  cd ..
  100  nano .spack/linux/packages.yaml
  101  cd Pubblici/spack/
  102  spack install dealii
  103  ls -lta
  104  cd share/
  105  ls
  106  cd spack/
  107  ls
  108  cd
/home/alberto.salvadori/Pubblici/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/dealii-9.0.1-jdludrcm25brf6vxyb5l6dqnmjigzvyq
  109  ls -lta
  110  ls share/


You see that there are two calls "spack install dealii" since I had to edit
the file ".spack/linux/packages.yam" in order to install petsc 3.10
Hope this helps

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori


On Tue, Oct 23, 2018 at 9:02 AM Denis Davydov  wrote:

> Alberto,
>
> Did you reset Spack to the current recommended version,
> namely e38f39e4eafeaa6daed580cece935141e5d8f04b  (I edited the wiki 7 days
> ago)?
> I double checked that 9.0.1 has no issues with concretization there with
> empty packages.yaml settings.
>
> My guess would be that
> (i) either you used older version where the conflict between PETSc and
> Trilinos is not resolved or
> (ii) you have extra preferences in your packages.yaml that cause this
> conflict
>
> Regards,
> Denis.
>
> On Monday, October 22, 2018 at 8:20:03 AM UTC+2, Alberto Salvadori wrote:
>>
>> Thank you, Praveen.
>>
>> While installing deal.ii all detailed instructions on the spack wiki page
>> have been followed. I cloned spack from git (I thus assume it is the latest
>> version) and made no modifications (yet :-) ) to the
>>  “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on
>> opensuse a couple of weeks ago without this issue.
>>
>> Shall I attach my  “.spack/linux/packages.yaml”  here?
>>
>> Alberto
>>
>>
>> *Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
>> Territorio, Ambiente e di Matematica (DICATAM)
>>  Universita` di Brescia, via Branze 43, 25123 Brescia
>>  Italy
>>  tel 030 3711239
>>  fax 030 3711312
>>
>> e-mail:
>>  alberto@unibs.it
>> web-pages:
>>  http://m4lab.unibs.it/faculty.html
>>  http://dicata.ing.unibs.it/salvadori
>>
>>
>> On Mon, Oct 22, 2018 at 8:08 AM Praveen C  wrote:
>>
>>> When I check spec on my opensuse machine, dealii@9.0.1 wants to use
>>> suite-sparse@5.3.0
>>>
>>> Have you perhaps already set some versions in your
>>> “.spack/linux/packages.yaml” file ?
>>>
>>> What does your file look like ?
>>>
>>> Also, you may want to update your spack to see it that fixes it.
>>>
>>> Thanks
>>> praveen
>>>
>>> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori 
>>> wrote:
>>>
>>> Dear community
>>>
>>> I am installing deal.ii (latest release) on a CentOS7 equipped machine.
>>> After typing
>>>
>>> spack install --test=root dealii
>>>
>>> I see this error:
>>>
>>> ==> Error: An unsatisfiable version constraint has been detected for spec:
>>>
>>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>>> arch=linux-centos7-x86_64
>>>
>>>
>>> while trying to concretize the partial spec:
>>>
>>> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease 
>>> ~cuda cuda_arch= 
>>> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>>>  arch=linux-centos7-x86_64
>>> ^adol-c@2.6.4:
>>> ^arpack-ng+mpi
>>> ^mpi
>>> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
>>> threads=none ~virtual_machine arch=linux-centos7-x86_64
>>> ^assimp
>>> 
>>> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
>>> ^bzip2
>>> ^diffutils
>>> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
>>> arch=linux-centos7-x86_64
>>> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
>>>

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

J-P  and Praveen,

Thanks for your help. Spack installation for deal.ii  worked out well. Petsc 
3.10 or later is required, I used 3.10. 

Alberto

Alberto Salvadori
Associate Professor 
DIMI, University of Brescia, Italy


> On 22 Oct 2018, at 09:28, Jean-Paul Pelteret  wrote:
> 
>> Shall I edit “.spack/linux/packages.yaml” file ?
> 
> Yes, since you’re already using this file to constrain other packages I would 
> suggest adding
> 
>   petsc:
> version: [3.9.4]
>   suite-sparse:
> version: [5.1.0]
> 
> to that list. You should check to see if the version of PETSc can be safely 
> incremented upwards - I’ve taken a conservative guess as to which version is 
> safe to use.
> 
>> On 22 Oct 2018, at 08:57, Alberto Salvadori  
>> wrote:
>> 
>> Thank you J-P.
>> Can you please remind me how to do what you suggest? Shall I edit 
>> “.spack/linux/packages.yaml” file ?
>> 
>> 
>> Alberto Salvadori
>>  Dipartimento di Ingegneria Civile, Architettura, Territorio, Ambiente e di 
>> Matematica (DICATAM)
>>  Universita` di Brescia, via Branze 43, 25123 Brescia
>>  Italy
>>  tel 030 3711239
>>  fax 030 3711312
>> 
>> e-mail: 
>>  alberto.salvad...@unibs.it
>> web-pages:
>>  http://m4lab.unibs.it/faculty.html
>>  http://dicata.ing.unibs.it/salvadori
>> 
>> 
>>> On Mon, Oct 22, 2018 at 8:43 AM Jean-Paul Pelteret  
>>> wrote:
>>> Hi Alberto,
>>> 
>>> As best I recall, their is a problem with a hidden clash in the 
>>> dependencies between the latest PETSc and Trilinos versions. (I thought 
>>> that there was an issue/PR on github/spack, but I couldn’t find it right 
>>> now.) The former wants a new version of SuiteSparse while the latter does 
>>> not yet support it. I think that the solution is to specify an older 
>>> version of PETSc when building with both PETSc and Trilinos.
>>> 
>>> Best,
>>> J-P
>>> 
>>>> On 22 Oct 2018, at 08:19, Alberto Salvadori  
>>>> wrote:
>>>> 
>>>> Thank you, Praveen.
>>>> 
>>>> While installing deal.ii all detailed instructions on the spack wiki page 
>>>> have been followed. I cloned spack from git (I thus assume it is the 
>>>> latest version) and made no modifications (yet :-) ) to the  
>>>> “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on 
>>>> opensuse a couple of weeks ago without this issue.
>>>> 
>>>> Shall I attach my  “.spack/linux/packages.yaml”  here?
>>>> 
>>>> Alberto 
>>>> 
>>>> Alberto Salvadori
>>>>  Dipartimento di Ingegneria Civile, Architettura, Territorio, Ambiente e 
>>>> di Matematica (DICATAM)
>>>>  Universita` di Brescia, via Branze 43, 25123 Brescia
>>>>  Italy
>>>>  tel 030 3711239
>>>>  fax 030 3711312
>>>> 
>>>> e-mail: 
>>>>  alberto.salvad...@unibs.it
>>>> web-pages:
>>>>  http://m4lab.unibs.it/faculty.html
>>>>  http://dicata.ing.unibs.it/salvadori
>>>> 
>>>> 
>>>>> On Mon, Oct 22, 2018 at 8:08 AM Praveen C  wrote:
>>>>> When I check spec on my opensuse machine, dealii@9.0.1 wants to use 
>>>>> suite-sparse@5.3.0
>>>>> 
>>>>> Have you perhaps already set some versions in your 
>>>>> “.spack/linux/packages.yaml” file ?
>>>>> 
>>>>> What does your file look like ?
>>>>> 
>>>>> Also, you may want to update your spack to see it that fixes it.
>>>>> 
>>>>> Thanks
>>>>> praveen
>>>>> 
>>>>>> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori 
>>>>>>  wrote:
>>>>>> 
>>>>>> Dear community
>>>>>> 
>>>>>> I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
>>>>>> After typing
>>>>>> 
>>>>>> spack install --test=root dealii
>>>>>> 
>>>>>> I see this error:
>>>>>> 
>>>>>> ==> Error: An unsatisfiable version constraint has been detected for 
>>>>>> spec:
>>>>>> 
>>>>>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>>>>>> arch=linux-centos7-x86_64 
>>>>>> 
>>>>>> 
>>>>>> while trying t

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

Thank you J-P.
Can you please remind me how to do what you suggest? Shall I
edit “.spack/linux/packages.yaml” file ?



*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori


On Mon, Oct 22, 2018 at 8:43 AM Jean-Paul Pelteret 
wrote:

> Hi Alberto,
>
> As best I recall, their is a problem with a hidden clash in the
> dependencies between the latest PETSc and Trilinos versions. (I thought
> that there was an issue/PR on github/spack, but I couldn’t find it right
> now.) The former wants a new version of SuiteSparse while the latter does
> not yet support it. I think that the solution is to specify an older
> version of PETSc when building with both PETSc and Trilinos.
>
> Best,
> J-P
>
> On 22 Oct 2018, at 08:19, Alberto Salvadori 
> wrote:
>
> Thank you, Praveen.
>
> While installing deal.ii all detailed instructions on the spack wiki page
> have been followed. I cloned spack from git (I thus assume it is the latest
> version) and made no modifications (yet :-) ) to the
>  “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on
> opensuse a couple of weeks ago without this issue.
>
> Shall I attach my  “.spack/linux/packages.yaml”  here?
>
> Alberto
>
>
> *Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
> Territorio, Ambiente e di Matematica (DICATAM)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3711239
>  fax 030 3711312
>
> e-mail:
>  alberto.salvad...@unibs.it
> web-pages:
>  http://m4lab.unibs.it/faculty.html
>  http://dicata.ing.unibs.it/salvadori
>
>
> On Mon, Oct 22, 2018 at 8:08 AM Praveen C  wrote:
>
>> When I check spec on my opensuse machine, dealii@9.0.1 wants to use
>> suite-sparse@5.3.0
>>
>> Have you perhaps already set some versions in your
>> “.spack/linux/packages.yaml” file ?
>>
>> What does your file look like ?
>>
>> Also, you may want to update your spack to see it that fixes it.
>>
>> Thanks
>> praveen
>>
>> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori <
>> alberto.salvad...@unibs.it> wrote:
>>
>> Dear community
>>
>> I am installing deal.ii (latest release) on a CentOS7 equipped machine.
>> After typing
>>
>> spack install --test=root dealii
>>
>> I see this error:
>>
>> ==> Error: An unsatisfiable version constraint has been detected for spec:
>>
>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>> arch=linux-centos7-x86_64
>>
>>
>> while trying to concretize the partial spec:
>>
>> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease 
>> ~cuda cuda_arch= 
>> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>>  arch=linux-centos7-x86_64
>> ^adol-c@2.6.4:
>> ^arpack-ng+mpi
>> ^mpi
>> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
>> threads=none ~virtual_machine arch=linux-centos7-x86_64
>> ^assimp
>> 
>> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
>> ^bzip2
>> ^diffutils
>> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
>> arch=linux-centos7-x86_64
>> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
>> arch=linux-centos7-x86_64
>> ^ncurses
>> ^pkgconfig
>> ^openssl
>> ^perl@5.14.0:
>> ^gdbm
>> ^readline
>> ^gmsh+netgen+oce+tetgen
>> ^gmp
>> ^autoconf
>> ^m4@1.4.6:
>> ^automake
>> ^libtool@2.4.2:
>> ^netgen
>> ^oce
>> ^tetgen
>> ^hdf5@1.8.9:+hl+mpi
>> ^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
>> arch=linux-centos7-x86_64
>> ^metis@5:~int64+real64
>> ^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64
>> ^nanoflann
>> ^netcdf+mpi
>> ^p4est
>> ^sundials~pthread
>> ^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
>> ^glm
>> ^

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

Thank you, Praveen.

While installing deal.ii all detailed instructions on the spack wiki page
have been followed. I cloned spack from git (I thus assume it is the latest
version) and made no modifications (yet :-) ) to the
 “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on
opensuse a couple of weeks ago without this issue.

Shall I attach my  “.spack/linux/packages.yaml”  here?

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori


On Mon, Oct 22, 2018 at 8:08 AM Praveen C  wrote:

> When I check spec on my opensuse machine, dealii@9.0.1 wants to use
> suite-sparse@5.3.0
>
> Have you perhaps already set some versions in your
> “.spack/linux/packages.yaml” file ?
>
> What does your file look like ?
>
> Also, you may want to update your spack to see it that fixes it.
>
> Thanks
> praveen
>
> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori 
> wrote:
>
> Dear community
>
> I am installing deal.ii (latest release) on a CentOS7 equipped machine.
> After typing
>
> spack install --test=root dealii
>
> I see this error:
>
> ==> Error: An unsatisfiable version constraint has been detected for spec:
>
> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb arch=linux-centos7-x86_64
>
>
> while trying to concretize the partial spec:
>
> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease ~cuda 
> cuda_arch= 
> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>  arch=linux-centos7-x86_64
> ^adol-c@2.6.4:
> ^arpack-ng+mpi
> ^mpi
> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
> threads=none ~virtual_machine arch=linux-centos7-x86_64
> ^assimp
> 
> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
> ^bzip2
> ^diffutils
> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
> arch=linux-centos7-x86_64
> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
> arch=linux-centos7-x86_64
> ^ncurses
> ^pkgconfig
> ^openssl
> ^perl@5.14.0:
> ^gdbm
> ^readline
> ^gmsh+netgen+oce+tetgen
> ^gmp
> ^autoconf
> ^m4@1.4.6:
> ^automake
> ^libtool@2.4.2:
> ^netgen
> ^oce
> ^tetgen
> ^hdf5@1.8.9:+hl+mpi
> ^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
> arch=linux-centos7-x86_64
> ^metis@5:~int64+real64
> ^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64
> ^nanoflann
> ^netcdf+mpi
> ^p4est
> ^sundials~pthread
> ^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
> ^glm
> ^matio
>
>
> dealii requires suite-sparse version :5.1.0, but spec asked for 5.3.0
>
> I wonder which is the source of the error and which files ( 
> ~/.spack/linux/packages.yaml perhaps?)
> shall I edit to sort out the issue.
>
> Many thanks in advance
>
> Alberto
>
>
>
>
>
> 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.
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 
<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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Error in installing deal.ii with spack on CentOs7

[Alberto Salvadori]

Dear community

I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
After typing

spack install --test=root dealii

I see this error:

==> Error: An unsatisfiable version constraint has been detected for spec:

suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb arch=linux-centos7-x86_64 


while trying to concretize the partial spec:

dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease ~cuda 
cuda_arch= 
~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
 arch=linux-centos7-x86_64 
^adol-c@2.6.4:
^arpack-ng+mpi
^mpi
^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
threads=none ~virtual_machine arch=linux-centos7-x86_64 
^assimp

^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
^bzip2
^diffutils
^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
arch=linux-centos7-x86_64 
^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
arch=linux-centos7-x86_64 
^ncurses
^pkgconfig
^openssl
^perl@5.14.0:
^gdbm
^readline
^gmsh+netgen+oce+tetgen
^gmp
^autoconf
^m4@1.4.6:
^automake
^libtool@2.4.2:
^netgen
^oce
^tetgen
^hdf5@1.8.9:+hl+mpi
^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
arch=linux-centos7-x86_64 
^metis@5:~int64+real64
^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64 
^nanoflann
^netcdf+mpi
^p4est
^sundials~pthread
^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
^glm
^matio


dealii requires suite-sparse version :5.1.0, but spec asked for 5.3.0

I wonder which is the source of the error and which files ( 
~/.spack/linux/packages.yaml perhaps?)
shall I edit to sort out the issue.

Many thanks in advance

Alberto




-- 


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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] projecting values of the solution on the boundary

[Alberto Salvadori]

Thank you JP,

your hints are highly appreciated. I will work on creating my own data
structure, to see how complex and effective it can be. In the meanwhile
though I made some tests with "almost" zero volumes cohesive interfaces and
they are indeed simple and effective. So, if there is a chance to allow
designing these elements in deal.ii I guess it is beneficial. I became
aware that in many cases of interface problem using zero volume elements is
a natural choice and papers have been extensively written on how to
implement them in Abaqus or other commercial tools. If I can be of any help
in promoting the discussion on github I will definitely do.

Thank you again,

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori


On Mon, Aug 27, 2018 at 8:27 AM Jean-Paul Pelteret 
wrote:

> Hi Alberto,
>
> This is simply not possible. The deal.II triangulation contains as much
> information as it needs, and we do not associate a normal with a volume.
> Normals are computed internally (and not stored!) based not only on the
> geometry of each real but also the mapping associated with the cell face.
> So if we read this data in, and then you associated a non-flat manifold
> with a face then you’d end up with a mis-match between the read-in normal
> and that determined by the manifold definition and mapping.
>
> If it were possible to create a zero-thickness element, then one might
> simply create a rule as to what you consider the “normal” to be. So, when
> looping over the faces of the zero-thickness element (as one would do to
> perform surface integration) then one might simply only perform the
> integration on faces shared with, say, domain 1. This way the normal is
> well defined, and completely independent of how the grid is created.
>
> Best,
> J-P
>
> On 26 Aug 2018, at 12:07, Alberto Salvadori 
> wrote:
>
> As a short follow up of the former question, I wonder how to pass
> geometrical information to a triangulation, if they are not included in the
> file read by grid.in(). As an example connected to the problem described
> above, consider the notion of "normal" at point 1/2 (in 3D: normal at the
> surface that joins the two subdomains). One can easily identify a normal
> for each "zero-thickness" element based on the gmsh file numeration, but it
> looks to me that in the read.msh function the elm_number plays no role in
> the triangulation defined by deal.ii. If this is correct, how to pass the
> geometrical info to the deal.ii triangulation?
> Thank you very much for any suggestions,
> Alberto
>
> Il giorno venerdì 24 agosto 2018 14:39:41 UTC+2, Alberto Salvadori ha
> scritto:
>>
>> Thank you Wolgang and Jean Paul.
>>
>> In these days I made some implementation in the line you propose but I am
>> not happy with it and thus I am asking advices on a different path of
>> reasoning.
>>
>> In brief: I'd like to design an algorithm to solve a problem over two
>> separate domains connected by an interface. Think in 1D of  line 0_1
>> separated in two parts 0_1/2 and 1/2_1.
>> In the simplest case, a linear elastic problem on each subdomain with a
>> spring that joins the two sides located at point 1/2. The boundary
>> conditions of the two parts at point 1/2 are a linear combination of the
>> solutions on the two boundaries.
>> The weak form of this problem can easily be written and surface integrals
>> involving unknowns arise. I tried to solve this with the algorithm
>> suggested by Wolfgang, and it works fine for very small meshes. However,
>> this strategy would imply that for each cell on the boundary (at point 1/2
>> for the domain 0_1/2) one has to seek trough the whole triangulation for
>> the cell that corresponds to point 1/2 in the remaining part (1/2_1). This
>> procedure is very expensive, or at least that comes out to me. (By the way,
>> although the triangulation is parallel shared I can only see cells on the
>> same node: shall I use a specific iterator?).
>>
>> To circumvent the issue, one could define a zero-thickness element at
>> point 1/2 (called cohesive in the literature sometimes) because in such a
>> case the element brings in all the connectivities that are required and one
>> can still define the tangent stiffness matrix based on surface integrals. I
>> have been working on this idea but I run into a major problem in loading
>> the triangulation from gmsh, since elements with zero

[deal.II] Re: Publications based on deal.II

[Alberto Salvadori]

Dear Wolfgang,

we just published the paper:

A. Salvadori Et Al, "Modeling and Simulation of VEGF Receptors Recruitment 
in Angiogenesis," Mathematical Problems in Engineering, vol. 2018, Article 
ID 4705472, 10 pages, 2018. https://doi.org/10.1155/2018/4705472/. 

using and quoting deal.ii . 

Best and thanks again for your efforts, deal.ii is a great tool for 
numerical science indeed.

Alberto

Il giorno martedì 24 aprile 2018 19:41:14 UTC+2, Wolfgang Bangerth ha 
scritto:
>
>
> All, 
>
> as you may know, we try to list all publications based on deal.II at 
>   http://dealii.org/publications.html 
> We use this list to justify the effort we spend on writing this 
> software, both to our universities as well as the funding agencies that 
> support its development. 
>
> In anticipation of the next release, we would like to update this page. 
> If you have (or know of) a publication that uses deal.II for numerical 
> results and that isn't already listed, please let us know so we can put 
> it on there. For this purpose, publications also include MSc, Diploma or 
> PhD theses, or anything else that may seem appropriate. 
>
> Thanks! 
>Wolfgang 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>

-- 


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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] projecting values of the solution on the boundary

[Alberto Salvadori]

As a short follow up of the former question, I wonder how to pass 
geometrical information to a triangulation, if they are not included in the 
file read by grid.in(). As an example connected to the problem described 
above, consider the notion of "normal" at point 1/2 (in 3D: normal at the 
surface that joins the two subdomains). One can easily identify a normal 
for each "zero-thickness" element based on the gmsh file numeration, but it 
looks to me that in the read.msh function the elm_number plays no role in 
the triangulation defined by deal.ii. If this is correct, how to pass the 
geometrical info to the deal.ii triangulation?
Thank you very much for any suggestions,
Alberto

Il giorno venerdì 24 agosto 2018 14:39:41 UTC+2, Alberto Salvadori ha 
scritto:
>
> Thank you Wolgang and Jean Paul.
>
> In these days I made some implementation in the line you propose but I am 
> not happy with it and thus I am asking advices on a different path of 
> reasoning. 
>
> In brief: I'd like to design an algorithm to solve a problem over two 
> separate domains connected by an interface. Think in 1D of  line 0_1 
> separated in two parts 0_1/2 and 1/2_1. 
> In the simplest case, a linear elastic problem on each subdomain with a 
> spring that joins the two sides located at point 1/2. The boundary 
> conditions of the two parts at point 1/2 are a linear combination of the 
> solutions on the two boundaries.
> The weak form of this problem can easily be written and surface integrals 
> involving unknowns arise. I tried to solve this with the algorithm 
> suggested by Wolfgang, and it works fine for very small meshes. However, 
> this strategy would imply that for each cell on the boundary (at point 1/2 
> for the domain 0_1/2) one has to seek trough the whole triangulation for 
> the cell that corresponds to point 1/2 in the remaining part (1/2_1). This 
> procedure is very expensive, or at least that comes out to me. (By the way, 
> although the triangulation is parallel shared I can only see cells on the 
> same node: shall I use a specific iterator?).
>
> To circumvent the issue, one could define a zero-thickness element at 
> point 1/2 (called cohesive in the literature sometimes) because in such a 
> case the element brings in all the connectivities that are required and one 
> can still define the tangent stiffness matrix based on surface integrals. I 
> have been working on this idea but I run into a major problem in loading 
> the triangulation from gmsh, since elements with zero volume are not 
> considered to be good as for now. I wonder if one could get rid of this 
> control or if zero-volume condition is used all over deal.ii as a check of 
> something going wrong.
>
> In fact one could also move the nodes a bit to generate "almost" zero 
> volumes. In some cases it can be done easily, but in general this approach 
> is unfeasible for complex meshes.
>
> I appreciate your comments.
> Best
>
> Alberto
>
>
>
> Il giorno lunedì 13 agosto 2018 21:47:29 UTC+2, Wolfgang Bangerth ha 
> scritto:
>>
>> On 08/08/2018 02:03 AM, Jean-Paul Pelteret wrote: 
>> > Hi Alberto, 
>> > 
>> > I have dealt with a similar problem where I needed to transmit solution 
>> > values between two different problems that shared a common interface. 
>> If 
>> > I remember correctly, the way that I did this was to precompute the 
>> > positions at which I would need the solutions from problem 1 for 
>> problem 
>> > 2. In a post processing step for problem 1 I then computed this data up 
>> > front (cache it) and then fetch it from problem 2. This avoided the 
>> > issue of going to look for which cell in problem 1 a point in problem 2 
>> > lay. I did this all manually, but I guess that this approach could be 
>> > made simpler now that we have GridTools::compute_point_locations() 
>> > <
>> https://www.dealii.org/developer/doxygen/deal.II/namespaceGridTools.html#a8e8bb9211264d2106758ac4d7184117e>
>>  which 
>>
>> > allows a speedy lookup between a point and its containing cell. 
>> > 
>> > FEFieldFunction has a cache so you could also investigate using it 
>> > (maybe it wouldn’t be too slow for your case). It also has the 
>> > set_active_cell() 
>> > <
>> https://www.dealii.org/9.0.0/doxygen/deal.II/classFunctions_1_1FEFieldFunction.html#a0206a45c90d523792eea8bd725d14788>
>>  function 
>>
>> > so you could create a lookup between a point in problem 1 and a cell in 
>> > problem 2 again using GridTools::Cache 
>> > <
>> https://www.dealii.org/developer/doxygen/deal.II/classGrid

Re: [deal.II] projecting values of the solution on the boundary

[Alberto Salvadori]

Thank you Wolgang and Jean Paul.

In these days I made some implementation in the line you propose but I am 
not happy with it and thus I am asking advices on a different path of 
reasoning. 

In brief: I'd like to design an algorithm to solve a problem over two 
separate domains connected by an interface. Think in 1D of  line 0_1 
separated in two parts 0_1/2 and 1/2_1. 
In the simplest case, a linear elastic problem on each subdomain with a 
spring that joins the two sides located at point 1/2. The boundary 
conditions of the two parts at point 1/2 are a linear combination of the 
solutions on the two boundaries.
The weak form of this problem can easily be written and surface integrals 
involving unknowns arise. I tried to solve this with the algorithm 
suggested by Wolfgang, and it works fine for very small meshes. However, 
this strategy would imply that for each cell on the boundary (at point 1/2 
for the domain 0_1/2) one has to seek trough the whole triangulation for 
the cell that corresponds to point 1/2 in the remaining part (1/2_1). This 
procedure is very expensive, or at least that comes out to me. (By the way, 
although the triangulation is parallel shared I can only see cells on the 
same node: shall I use a specific iterator?).

To circumvent the issue, one could define a zero-thickness element at point 
1/2 (called cohesive in the literature sometimes) because in such a case 
the element brings in all the connectivities that are required and one can 
still define the tangent stiffness matrix based on surface integrals. I 
have been working on this idea but I run into a major problem in loading 
the triangulation from gmsh, since elements with zero volume are not 
considered to be good as for now. I wonder if one could get rid of this 
control or if zero-volume condition is used all over deal.ii as a check of 
something going wrong.

In fact one could also move the nodes a bit to generate "almost" zero 
volumes. In some cases it can be done easily, but in general this approach 
is unfeasible for complex meshes.

I appreciate your comments.
Best

Alberto



Il giorno lunedì 13 agosto 2018 21:47:29 UTC+2, Wolfgang Bangerth ha 
scritto:
>
> On 08/08/2018 02:03 AM, Jean-Paul Pelteret wrote: 
> > Hi Alberto, 
> > 
> > I have dealt with a similar problem where I needed to transmit solution 
> > values between two different problems that shared a common interface. If 
> > I remember correctly, the way that I did this was to precompute the 
> > positions at which I would need the solutions from problem 1 for problem 
> > 2. In a post processing step for problem 1 I then computed this data up 
> > front (cache it) and then fetch it from problem 2. This avoided the 
> > issue of going to look for which cell in problem 1 a point in problem 2 
> > lay. I did this all manually, but I guess that this approach could be 
> > made simpler now that we have GridTools::compute_point_locations() 
> > <
> https://www.dealii.org/developer/doxygen/deal.II/namespaceGridTools.html#a8e8bb9211264d2106758ac4d7184117e>
>  which 
>
> > allows a speedy lookup between a point and its containing cell. 
> > 
> > FEFieldFunction has a cache so you could also investigate using it 
> > (maybe it wouldn’t be too slow for your case). It also has the 
> > set_active_cell() 
> > <
> https://www.dealii.org/9.0.0/doxygen/deal.II/classFunctions_1_1FEFieldFunction.html#a0206a45c90d523792eea8bd725d14788>
>  function 
>
> > so you could create a lookup between a point in problem 1 and a cell in 
> > problem 2 again using GridTools::Cache 
> > <
> https://www.dealii.org/developer/doxygen/deal.II/classGridTools_1_1Cache.html>
>  (although 
>
> > I’m guessing that this is what it does internally). 
>
> This is indeed what you would do if you had separate meshes. The better 
> approach, of course, is to use the same mesh for both problems. In that 
> case, you can use this to obtain the gradients of the Poisson solution 
> un at the quadrature points on the faces where you need these values for 
> the second problem: 
>FEFaceValues poisson_fe_face_values (...); 
>std::vector> un_gradients (...); 
>std::vector un_dot_n_values (...); 
>
>for (cell=...) 
>  for (face=...) 
>if (face is interesting) 
>{ 
>  poisson_fe_face_values.reinit (cell, face); 
>  poisson_fe_face_values.get_function_gradients (poisson_solution, 
> un_gradients); 
>  for (q=0...) 
>un_dot_n_values[q] = un_gradients[q] * 
> poisson_fe_face_values.normal_vectors(q); 
>
>  ...do assembly for the second problem using the values of 
> (grad un).n just computed... 
>} 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.

[deal.II] projecting values of the solution on the boundary

[Alberto Salvadori]

Dear community,

I am asking some advices on the following issue. I am solving a simple 
problem, say a Poisson problem in the unknown field u, and a more involved 
problem separately. This second problem requires the values of u in the 
Neumann boundary conditions.

Accordingly, I guess one could solve the Laplacian first and calculate the 
numerical solution for u, say un. Afterwards one builds a solver for the 
more complex operator and in the Neumann part of the code - that may look 
like this for parallel::shared triangulations:

  for (unsigned int face_number=0; 
face_number::faces_per_cell; 
++face_number)

if (

cell->face(face_number)->at_boundary()

&&

cell->face(face_number)->boundary_id() == 2// Neumann 
boundaries

)

{

  

  fe_face_values.reinit (cell, face_number);

  

  // define points and normals

  

  std::vector< Point >points  = 
fe_face_values.get_quadrature_points();

  std::vector< Tensor<1,dim> > normals = 
fe_face_values.get_all_normal_vectors();

  

  // calculate neumann values

  

  for (unsigned int q_point=0; q_point mech_neumann_value;

neumann_bc_for_mech.bc_value( points[q_point], 
normals[q_point], mech_neumann_value );


 .

 

one needs the value of the field un at points  points[q_point] to be passed 
to neumann_bc_for_mech.bc_value.
Which is an effective way to calculate this amount ?

Thank you.

Alberto


-- 


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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Error in installing deal.ii with spack on linux openSuse

[Alberto Salvadori]

Thank you!

Alberto Salvadori
Associate Professor 
DICATAM, University of Brescia, Italy


> On 19 Feb 2018, at 16:06, Bruno Turcksin  wrote:
> 
> Alberto,
> 
>> On Monday, February 19, 2018 at 9:56:25 AM UTC-5, Alberto Salvadori wrote:
>> dealii requires cmake version :3.9.99, but spec asked for 3.10.1
>> 
> deal.II 8.5 does not support cmake 3.10 so you need to force spack to use a 
> lower version. Something like this should work spack dealii ^cmake@3.9.1
> 
> Best,
> 
> Bruno 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Error in installing deal.ii with spack on linux openSuse

[Alberto Salvadori]

Dear community,

I am trying to install deal.ii on a linux machine, equipped with openSuse 
( openSUSE 12.3 (x86_64)

VERSION = 12.3

CODENAME = Dartmouth)
via spack. I am having the following error: 


spack install dealii

*==>* Error: An unsatisfiable version constraint has been detected for spec:


cmake@3.10.1%gcc@4.7~doc+ncurses+openssl+ownlibs~qt 
arch=linux-opensuse12-x86_64 

^ncurses

^pkgconfig

^openssl

^zlib@1.2.11%gcc@4.7+optimize+pic+shared 
arch=linux-opensuse12-x86_64 



while trying to concretize the partial spec:


dealii@8.5.1%gcc@4.7~adol-c+arpack~assimp build_type=DebugRelease ~cuda 
cuda_arch= 
~doc~gmsh+gsl+hdf5~int64+metis+mpi~nanoflann+netcdf+oce~optflags+p4est+petsc+python~scalapack+slepc~sundials+trilinos
 
arch=linux-opensuse12-x86_64 

^arpack-ng+mpi

^mpi

^openblas@0.2.20%gcc@4.7 cpu_target= ~ilp64+pic+shared 
threads=none ~virtual_machine arch=linux-opensuse12-x86_64 

^bzip2

^metis@5:~int64+real64

^cmake@3.10.1%gcc@4.7~doc+ncurses+openssl+ownlibs~qt 
arch=linux-opensuse12-x86_64 

^ncurses

^pkgconfig

^openssl

^zlib@1.2.11%gcc@4.7+optimize+pic+shared 
arch=linux-opensuse12-x86_64 

^netcdf+mpi

^hdf5@1.8.9:+hl

^m4



dealii requires cmake version :3.9.99, but spec asked for 3.10.1

Does anyone have any suggestion? 

Thank you!
Alberto



-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: AW: [deal.II] step-42 clarification

[Alberto Salvadori]

Thank you, Timo. Your remarks have been very useful.
It turned out that I made a mistake in the way the mesh was prepared,
 specifically some hanging nodes were not properly dealt with.
This caused also a related issue, that I shared here some time ago (Nov.
25).

This leads to another question, that I take the opportunity to ask. Suppose
that a run is too long for a time slot allocated on a large scale computer.
In such a case, one wants to restart the computations
from a given time. To this aim, the history of the computations up to a
certain time shall be stored. All data stored in cell->user_pointer(), data
of the loads and mesh.
How can one store information on the latter, - as for the partition and the
hanging nodes - correctly? I understand that saving the mesh in a "ucd" or
alternative form may not be the right strategy.

Thank you very much.
Alberto








*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Fri, Jan 19, 2018 at 3:39 PM, Timo Heister  wrote:

> > in the code and re-implemented it. In serial version, all works fine so
> far.
> > However, when running in parallel, I am seeing an issue in the method
> > PlasticityContactProblem::update_solution_and_constraints.
> >
> > In particular, it turns out that the value of
> >
> > const unsigned int index_z = dof_indices[q_point];
> >
> > might be out of the range of
>
> If you do a loop over all locally owned and locally relevant cells
> than all dof values of a ghosted vector should exist. If you see an
> error, something else must be incorrect (like the IndexSets).
>
> >   PETScWrappers::MPI::Vector lambda( this->locally_relevant_dofs,
> this->mpi_communicator);
>
> This looks suspicious. Does this really create a ghosted vector in
> PETSc? I thought this would fail (at least in debug mode).
>
> Finally, it looks like you modified it to only look at locally owned
> cells to build constraints. The problem with this is that processors
> also need to know about constraints on ghost cells, not only locally
> owned cells. You no longer compute them, which means the solution
> might become incorrect around processor boundaries. It probably
> (hopefully?) works without adaptivity because each locally owned DoF
> is within at least one locally owned cell, but imagine a case where a
> dof on a ghost cells is constrained and interacts with a hanging node
> the current processor owns. You will not handle this case correctly.
>
> I don't quite remember if there is an easy way to do this, but I
> remember writing a debug function that checks if a ConstraintMatrix is
> consistent in parallel. This was a while back, but I can try to find
> it.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: AW: [deal.II] step-42 clarification

[Alberto Salvadori]

>is_locally_owned())  // MY OWN CODE

  {

for (unsigned int face=0; face::faces_per_cell;
++face)



  // the Contact boundary is set to value 3, i.e. set_boundary_id
(3);



  if (cell->face(face)->at_boundary()

  &&

  cell->face(face)->boundary_id() == 3)

  {


fe_values_face.reinit(cell, face);

cell->face(face)->get_dof_indices(dof_indices);

for (unsigned int q_point=0; q_pointfe.face_system_to_component_index(q_point).first;

  const unsigned int index_X2 = dof_indices[q_point];



  // MY OWN CODE: component has been changed to 1 since the
direction of contact is X2 for the cell.



  if ((component == 1) && (dof_touched[index_X2] == false))

  {


dof_touched[index_X2] = true;

const Point this_support_point =
fe_values_face.quadrature_point(q_point);

const double obstacle_value =
this->obstacle->value(this_support_point,
1);



const double solution_here =
this->accumulated_displacement(index_X2);
// solution(index_X2);



// I believe it should be undeformed_gap >=0, i.e. :

const double undeformed_gap = this_support_point(1) -
obstacle_value;  // rather than obstacle_value - this_support_point(1);



double e_modulus;

if (  cell->material_id() == 0 ) e_modulus = this
->cytoplasm_model.youngmodulus();

else if (  cell->material_id() == 1 ) e_modulus = this
->nucleus_model.youngmodulus();

else e_modulus = 1;


if ( lambda.in_local_range(index_X2) &&
diag_mass_matrix_vector_relevant.in_local_range(index_X2) )

{



  lambda(index_X2);

  diag_mass_matrix_vector_relevant(index_X2);

  this->hanging_node_constraints.is_constrained(index_X2);



  const double c = 100.0 * e_modulus;

  if ((lambda(index_X2) /
diag_mass_matrix_vector_relevant(index_X2)

   +

   c * ( - solution_here - undeformed_gap )   // I
believe it should be this, rather than (solution_here - undeformed_gap)

   > 0)

  &&


!(this->hanging_node_constraints.is_constrained(index_X2))
)

  {

this->contact_constraints.add_line( index_X2 );   // it
was this->all_constraints.add_line(index_X2);

this->contact_constraints.set_inhomogeneity(index_X2, -
undeformed_gap); // it was this->all_constraints.set_inhomogeneity // I
believe it should be this, rather than undeformed_gap);

distributed_solution( index_X2 ) = - undeformed_gap;  //
I believe it should be this, rather than undeformed_gap;

this->active_set.add_index( index_X2 );

  }

};



  }

}

  }

  }

}




  // At the end of this function, we exchange data between processors
updating those ghost elements in the solution variable that have been
written by other processors.



  distributed_solution.compress(VectorOperation::insert);

  this->accumulated_displacement = distributed_solution;



  // We then merge the constraints from hanging nodes into the
ConstraintMatrix object that already contains the active set.



  this->contact_constraints.close();// it was
this->all_constraints.close();


  this->all_constraints.merge(this->hanging_node_constraints);

  this->all_constraints.merge(this->contact_constraints);


  this->pcout << "   Size of active set: " <<
Utilities::MPI::sum((this->active_set
& this->locally_owned_dofs).n_elements(), this->mpi_communicator) <<
std::endl;



}



*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Wed, Jan 17, 2018 at 11:01 PM, Frohne, Joerg <
fro...@mathematik.uni-siegen.de> wrote:

> >>On 01/17/2018 02:45 PM, Frohne, Joerg wrote:
> >> obviously this is a mistake. I checked the source files which we have
> used for results in corresponding paper.
> >> There I have found the following coding:
> >>
> >>resid_old = resid;
> >>
> >>resid_vector = system_rhs_newton;
> >>resid_vector.compress(VectorOperation::insert);
> >>
> >>int is_my_set_changed = (active_set == active_set_old) ? 0 :

[deal.II] step-42 clarification

[Alberto Salvadori]

Dear community,

I am studying with pleasure step-42 and I got a bit confused in the method 
PlasticityContactProblem::solve_newton. At the very end of it, we find 
these instructions:

old_active_set = active_set;
previous_residual_norm = residual_norm;
 
if (Utilities::MPI::sum 
((active_set
 
== old_active_set) ? 0 : 1,
mpi_communicator) == 0)
{
pcout << " Active set did not change!" << std::endl;
if (residual_norm < 1e-10)
break;
}


Now, I am a bit confused by the if statement and I am clearly missing 
something. The first instruction makes old_active_set equal to active_set. 
Accordingly, wouldn't active_set == old_active_set  always be true? What am 
I missing?

Thanks for your help

Alberto

-- 

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] mesh refinement on a multilayerd hyperball (for Mie scattering problem)

[Alberto Salvadori]

Dear community,

this might be a little "off topic" but perhaps of interest anyway.

I am using the multilayerd hyperball proposed by Konstantin Ladutenko in 
the 
post 
https://groups.google.com/forum/#!searchin/dealii/sphere$20mesh%7Csort:date/dealii/pvqNQUM3eyM/o0USYKbGBQAJ.
I find it a neat way of meshing a sphere, particularly I am interested in 
meshing an "egg" with a stiffer nucleus. 

However I noticed that when the mesh is refined and coarsened as in this 
example,


  Vector error_per_cell (this->triangulation.n_active_cells());

  

  KellyErrorEstimator::estimate (this->dof_handler,

  QGauss(2),

  typename FunctionMap::type(),

  this->accumulated_displacement, // 
incremental_displacement,

  error_per_cell,

  ComponentMask(),

  0,

  MultithreadInfo::n_threads(),

  this->this_mpi_process);

  

  

  

  const unsigned int n_local_cells = 
this->triangulation.n_locally_owned_active_cells 
();

  

  PETScWrappers::MPI::Vector

  distributed_error_per_cell (this->mpi_communicator,

  this->triangulation.n_active_cells(),

  n_local_cells);

  

  for (unsigned int i=0; itriangulation,

   error_per_cell,

   0.35, 0.03);

  

  this->triangulation.execute_coarsening_and_refinement ();

  

mesh inconsistencies arise (see figures). Typically, if the inner part of 
the "egg" in not refined concurrently with the outer shell, a gap is 
created. Did anyone notice this issue before? Perhaps any suggestion for 
solving it?
The meshing code is in the 
post 
https://groups.google.com/forum/#!searchin/dealii/sphere$20mesh%7Csort:date/dealii/pvqNQUM3eyM/o0USYKbGBQAJ.

Thank you
Alberto




-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] deal.II on Mac OS Sierra

[Alberto Salvadori]

Hi Pawan,

This issue has been dealt with in 

https://groups.google.com/forum/m/#!topic/dealii/KypFL9X0bVo

Best,
Alberto




> On Oct 25, 2017, at 3:22 AM, Pawan Takhar  wrote:
> 
> I am a new user of deal.II. I installed 8.5.0 on Mac OS Sierra a few months 
> ago. I used .dmg and cmake .dmg files and set the environment variables as 
> suggested on website. The program was running fine but at some time, maybe 
> after update of Xcode, I have started getting the following error. I have 
> performed a fresh installation on a different computer, but still this error 
> does not go away. The error originates when I run the make in command window.
> 
> cmake .  runs without any problem. When I run make I get the following 
> warnings and errors. Please help. 
> 
> Thanks,
> Pawan
> 
> In file included from 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/step-1.cc:22:
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/grid/tria.h:31:1:
>  warning: 
> 
>   unknown warning group '-Wunused-but-set-parameter', ignored
> 
>   [-Wunknown-warning-option]
> 
> DEAL_II_DISABLE_EXTRA_DIAGNOSTICS
> 
> ^
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/base/config.h:307:66:
>  note: 
> 
>   expanded from macro 'DEAL_II_DISABLE_EXTRA_DIAGNOSTICS'
> 
> _Pragma("GCC diagnostic ignored \"-Winfinite-recursion\"")   \
> 
>  ^
> 
> :60:25: note: expanded from here
> 
>  GCC diagnostic ignored "-Wunused-but-set-parameter"
> 
> ^
> 
> In file included from 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/step-1.cc:22:
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/grid/tria.h:31:1:
>  warning: 
> 
>   unknown warning group '-Wunused-but-set-variable', ignored
> 
>   [-Wunknown-warning-option]
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/base/config.h:311:66:
>  note: 
> 
>   expanded from macro 'DEAL_II_DISABLE_EXTRA_DIAGNOSTICS'
> 
> _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")  \
> 
>  ^
> 
> :61:25: note: expanded from here
> 
>  GCC diagnostic ignored "-Wunused-but-set-variable"
> 
> ^
> 
> In file included from 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/step-1.cc:22:
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/grid/tria.h:31:1:
>  warning: 
> 
>   unknown warning group '-Wexpansion-to-defined', ignored
> 
>   [-Wunknown-warning-option]
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/base/config.h:312:66:
>  note: 
> 
>   expanded from macro 'DEAL_II_DISABLE_EXTRA_DIAGNOSTICS'
> 
> _Pragma("GCC diagnostic ignored \"-Wunused-but-set-variable\"")  \
> 
>  ^
> 
> :61:25: note: expanded from here
> 
>  GCC diagnostic ignored "-Wexpansion-to-defined"
> 
> ^
> 
> In file included from 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/step-1.cc:22:
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/grid/tria.h:31:1:
>  warning: 
> 
>   unknown warning group '-Wmisleading-indentation', ignored
> 
>   [-Wunknown-warning-option]
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/include/deal.II/base/config.h:314:66:
>  note: 
> 
>   expanded from macro 'DEAL_II_DISABLE_EXTRA_DIAGNOSTICS'
> 
> _Pragma("GCC diagnostic ignored \"-Wignored-attributes\"")   \
> 
>  ^
> 
> :61:25: note: expanded from here
> 
>  GCC diagnostic ignored "-Wmisleading-indentation"
> 
> ^
> 
> 4 warnings generated.
> 
> make[2]: *** No rule to make target 
> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Accelerate.framework',
>  needed by `step-1'.  Stop.
> 
> make[1]: *** [CMakeFiles/step-1.dir/all] Error 2
> 
> make: *** [all] Error 2
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 

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 

Re: [deal.II] Re: Deal for Mac OS 10.13

[Alberto Salvadori]

Sure, I will. Am I understanding properly that deal.ii is trying to use the
accelerate framework (I guess because of some lapack calls) when compiled
for MacOS?


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Wed, Oct 11, 2017 at 8:44 AM, Luca Heltai  wrote:

> Alberto,
>
> In the options of xcode, you should be able to install also the 10.12 sdk.
> Can you try that?
>
> Luca
>
> On 11 Oct 2017, at 08:30, Alberto Salvadori 
> wrote:
>
> Hi Daniel.
>
> After installation of High Sierra, Xcode9, upgrading cmake and using
> deal.ii/8.5.1 provided by Timo, I run usual regression tests that worked
> well under Xcode8.x.
> It turned out that they could not be linked anymore with this error (sorry
> for the code name):
>
> make[2]: *** No rule to make target `/Applications/Xcode.app/
> Contents/Developer/Platforms/MacOSX.platform/Developer/
> SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Accelerate.framework',
> needed by `crap_code'.  Stop.
>
> make[1]: *** [CMakeFiles/crap_code.dir/all] Error 2
>
> make: *** [all] Error 2
>
> The simplest code that I attempted to run was the hello world, which run
> fine without being linked to deal.ii libraries but that provided the very
> same error with deal.ii.
> Hope it helps
>
> Alberto
>
>
> Il giorno martedì 10 ottobre 2017 14:53:37 UTC+2, Daniel Arndt ha scritto:
>>
>> Alberto and Deepak,
>>
>> what exactly are the problems you are facing?
>> What kind of errors do you get?
>>
>> Best,
>> Daniel
>>
>
>
> 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.
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Deal for Mac OS 10.13

[Alberto Salvadori]

Hi Daniel.

After installation of High Sierra, Xcode9, upgrading cmake and using 
deal.ii/8.5.1 provided by Timo, I run usual regression tests that worked 
well under Xcode8.x.
It turned out that they could not be linked anymore with this error (sorry 
for the code name):

make[2]: *** No rule to make target 
`/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Accelerate.framework',
 
needed by `crap_code'.  Stop.

make[1]: *** [CMakeFiles/crap_code.dir/all] Error 2

make: *** [all] Error 2

The simplest code that I attempted to run was the hello world, which run 
fine without being linked to deal.ii libraries but that provided the very 
same error with deal.ii. 
Hope it helps

Alberto


Il giorno martedì 10 ottobre 2017 14:53:37 UTC+2, Daniel Arndt ha scritto:
>
> Alberto and Deepak,
>
> what exactly are the problems you are facing?
> What kind of errors do you get?
>
> Best,
> Daniel
>

-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Deal for Mac OS 10.13

[Alberto Salvadori]

Hi,

I had a similar problem. It looks like that deal.ii is currently not
compatible with Xcode 9. You can however install both Xcode9 (just rename
it) and an older version of Xcode8.x
This sorted out all issues to me. Hope it helps.

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Tue, Oct 10, 2017 at 12:36 PM, Deepak Kukrety 
wrote:

> Hi All
>
> Good day!
>
> I am trying to install Deal.ii on an iMac. I recently upgraded to the
> latest version of Mac OS, 10.13 and as far as I could understand the
> version of Deal.ii presently available is not compatible with the latest
> OS. Is there a workaround this situation or should I wait for a new Deal.ii
> release. If so, when is the new inhaler likely to be available.
>
> Thanks in advance
>
> Deepak
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

[Alberto Salvadori]

Great, thank you all.I'll think about it and see what I can come up with.

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Mon, Aug 21, 2017 at 6:18 PM, Jean-Paul Pelteret 
wrote:

>
> That's the way to go, unless you want to implement the
>> DataComponentInterpretation part as well as support in DataOutBase for
>> tensor-valued quantities.
>>
>
> This would be a nice feature to have, and I would definitely support
> having it included! The only problem is that, last time I checked, Tensor
> support on Paraview was only possible through one of two plugins
> <https://www.paraview.org/Wiki/ParaView/User_Created_Plugins>. Paraview
> needs to be built by hand to enable these plugins, which is not so nice :-/
> Also when I last tested these plugins they did work but were very
> computationally intensive, so in my experience it may be better to simply
> output scalar / vector data.
>
> J-P
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

[Alberto Salvadori]

Thank you Jean-Paul,

this works now pretty well. In fact, I had some problems in installing
version 8.5.0 that have been now overcame with Timo's 8.5.1 (see Getting
error during cmake configuration step and later during make run.
<https://groups.google.com/forum/#!searchin/dealii/cmake%7Csort:relevance/dealii/1Zrot_Ot70Q/W_bX4WS0AgAJ>
).
I dare to ask another question on exporting tensors for vtk. I understand
there is no data component interpretation for tensors (I mean anything like
DataComponentInterpretation::component_is_part_of_tensor) and I read that
in aspect 1.3 ASPECT 1.3 released.
<https://groups.google.com/forum/#!searchin/dealii/output$20tensors%7Csort:relevance/dealii/qoJwnOgg_zE/bKjbgzY66dQJ>
there
are "New visualization postprocessors that can output the shear stress and
full stress tensors". Is it a dedicated procedure for vtk?

Of course I can manage by projecting tensors on three orthogonal directions
and visualize as vectors, but I find this inelegant.

Thanks

Alberto




*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Fri, Aug 18, 2017 at 3:08 PM, Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> From the link in your previous post I presume that you're working with
> deal.II 8.4.1? The feature that I've referred to was introduced in version
> 8.5.0. In fact, I see now that the latest version of step-33
> <https://www.dealii.org/8.5.0/doxygen/deal.II/step_33.html#EulerEquationsPostprocessor>
> has been updated to demonstrate this new functionality. Does that help?
>
> Regards,
> Jean-Paul
>
> On Friday, August 18, 2017 at 2:30:12 PM UTC+2, Alberto Salvadori wrote:
>>
>> Thank you Jean-Paul.
>>
>> From the CommonInputs class
>> <https://www.dealii.org/8.5.0/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html>,
>> I understand that I can retrieve a pointer to the current cell by using
>> this instruction, provided that the right DoFHandler is passed:
>>
>> const typename hp::DoFHandler::cell_iterator
>> <https://www.dealii.org/8.5.0/doxygen/deal.II/group__Iterators.html#ga60277a8a3957ba4b41c1e76a87decd30>
>> current_cell = input_data.template get_cell >();
>>
>> which is indeed what I am looking for. However, I have no clue about the
>> input_data  variable, which is passed to the evaluate_vector_field function
>> in the example that computes the fluid norm of the stress, and how it
>> connects to the Post-process class that is described in step-33, i.e.
>>
>> template 
>> class BoussinesqFlowProblem::Postprocessor : public
>> DataPostprocessor
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html>
>> 
>> {
>> public:
>> Postprocessor (const unsigned int partition,
>> const double minimal_pressure);
>> virtual
>> void
>> compute_derived_quantities_vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#adf1b8b97f2b2f9c65d4c7b143f61865f>
>> (const std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classVector.html> > &uh,
>> const std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classTensor.html> > > &duh,
>> const std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classTensor.html> > >
>> &dduh,
>> const std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classPoint.html> >
>> &normals,
>> const std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classPoint.html> >
>> &evaluation_points,
>> std::vector
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classVector.html> >
>> &computed_quantities) const;
>> virtual std::vector get_names
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#a254f38bcdf4bdb5aa94231b695da7d55>
>> () const;
>> virtual
>> std::vector
>> get_data_component_interpretation
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#a4d808c941d39a0c41cc9ac4afa82d47e>
>> () const;
>> virtual UpdateFlags
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/group__feaccess.html#gaa94b67d2fdcc390690c523f28019e52f>
>> get_needed_update_flags
>> <https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#aadecdd040447b395164397ea1196f721>
>> () const;
>> pri

Re: [deal.II] Re: Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

[Alberto Salvadori]

Thank you Jean-Paul.

>From the CommonInputs class
<https://www.dealii.org/8.5.0/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html>,
I understand that I can retrieve a pointer to the current cell by using
this instruction, provided that the right DoFHandler is passed:

const typename hp::DoFHandler::cell_iterator
<https://www.dealii.org/8.5.0/doxygen/deal.II/group__Iterators.html#ga60277a8a3957ba4b41c1e76a87decd30>
current_cell = input_data.template get_cell >();

which is indeed what I am looking for. However, I have no clue about the
input_data  variable, which is passed to the evaluate_vector_field function
in the example that computes the fluid norm of the stress, and how it
connects to the Post-process class that is described in step-33, i.e.

template 
class BoussinesqFlowProblem::Postprocessor : public DataPostprocessor
<https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html>

{
public:
Postprocessor (const unsigned int partition,
const double minimal_pressure);
virtual
void
compute_derived_quantities_vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#adf1b8b97f2b2f9c65d4c7b143f61865f>
(const std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classVector.html> > &uh,
const std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classTensor.html> > > &duh,
const std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classTensor.html> > > &dduh,
const std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classPoint.html> > &normals,
const std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classPoint.html> >
&evaluation_points,
std::vector
<https://www.dealii.org/8.4.1/doxygen/deal.II/classVector.html> >
&computed_quantities) const;
virtual std::vector get_names
<https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#a254f38bcdf4bdb5aa94231b695da7d55>
() const;
virtual
std::vector
get_data_component_interpretation
<https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#a4d808c941d39a0c41cc9ac4afa82d47e>
() const;
virtual UpdateFlags
<https://www.dealii.org/8.4.1/doxygen/deal.II/group__feaccess.html#gaa94b67d2fdcc390690c523f28019e52f>
get_needed_update_flags
<https://www.dealii.org/8.4.1/doxygen/deal.II/classDataPostprocessor.html#aadecdd040447b395164397ea1196f721>
() const;
private:
const unsigned int partition;
const double minimal_pressure;
};

Can you perhaps provide some further information, to fill the gap?
Thank you,

Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Fri, Aug 18, 2017 at 12:38 PM, Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> It looks like one can already do this, although its somewhat obscurely
> documented. Here's a link to the documentation of the CommonInputs class
> <https://www.dealii.org/8.5.0/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html>,
> wherein you can find a documented example of computing some solution and
> cell dependent data. It seems to be a relatively new feature (circa 2016)
> and I didn't know about it, so I'm happy to have found out about it as well!
>
> Regards,
> Jean-Paul
>
> On Friday, August 18, 2017 at 11:16:40 AM UTC+2, Alberto Salvadori wrote:
>>
>> Dear all,
>>
>> I have been studying step-32 and I have found the class Postprocessor nice
>> and effective.
>> It is my understanding that the method compute_derived_quantities_vector 
>> within
>> the class operates at a call level, i.e. that beyond the hood the class
>> Postprocessor
>> implements loops over the triangulation.
>>
>> I wonder if there is a way to use the cell->user_pointer in the method
>> compute_derived_quantities_vector, i.e. if there is a way to access a
>> reference to the cell itself.
>>
>> This would be very useful in case of post-processing of data that depend
>> on the history at each Gauss point, which is indeed my case of interest.
>>
>> Thanks!
>> Alberto
>>
> --
> 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.
> For more options, visit https://grou

[deal.II] Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

[Alberto Salvadori]

Dear all,

I have been studying step-32 and I have found the class Postprocessor nice 
and effective. 
It is my understanding that the method compute_derived_quantities_vector within 
the class operates at a call level, i.e. that beyond the hood the class 
Postprocessor
implements loops over the triangulation. 

I wonder if there is a way to use the cell->user_pointer in the method 
compute_derived_quantities_vector, i.e. if there is a way to access a 
reference to the cell itself.

This would be very useful in case of post-processing of data that depend on 
the history at each Gauss point, which is indeed my case of interest.

Thanks!
Alberto

-- 

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] transitioning from parallel::shared::Triangulation to parallel::distributed::Triangulation

[Alberto Salvadori]

Hi deal.ii community,


I am bothering today about a code I have been writing in the shared 
triangulation framework and its transition to the parallel::distributed::
Triangulation framework.

The shared version works just fine, and so does the parallel if run with 1 
single process. I understand therefore that the numerics seem to work OK, 
but since I am having issues with more than one process, likely I am not 
understanding some fundamentals of the 
parallel::distributed::Triangulation 
framework.


In particular it seems that a call of type


std::vector< Vector< double > > old_solution_values ( 
quadrature_formula.size(), 
Vector< double >(dofs.GPDofs) );

fe_values.get_function_values ( locally_accumulated_displacement, 
old_solution_values );



provides nan, that propagates and make the code to fail. I wonder if this 
fact is due to DoFs that are not locally owned within cells that are indeed 
owned locally.

In such a case, I am doing an implementation which is not appropriate and I 
wonder how to accomplish it properly.

More details follows.


I appreciate your help as usual.


Alberto





The code is a standard 3 fields mechanics formulation, small strains. 

I have thus implemented a Newton Raphson scheme. The interesting part of 
the class definition is:



template 

class SmallStrainMechanicalProblem

{

public:

  

  SmallStrainMechanicalProblem ( const std::string, const unsigned = 1, 
const unsigned = 1 );

  ~SmallStrainMechanicalProblem ();

  

  void run ( unsigned, bool, bool=false );


private:



  // Main methods

...

 

  // quadrature point integrators

...

  


  // MPI data structure

  

  MPI_Comm mpi_communicator;

  

  const unsigned int n_mpi_processes;

  const unsigned int this_mpi_process;

  

  ConditionalOStream pcout;

  

  std::vector local_dofs_per_process;

  std::vector starting_index_per_process;

  std::vector ending_index_per_process;


  IndexSet locally_owned_dofs;

  IndexSet locally_relevant_dofs;

  unsigned int n_local_cells;


  // FEM member variables

  

  parallel::distributed::Triangulation   triangulation;

  DoFHandler  dof_handler;

  

  FESystemfe;

  

  ConstraintMatrix hanging_node_constraints;

  

  const QGauss   quadrature_formula;

  const QGauss face_quadrature_formula;

  

  LA::MPI::SparseMatrix system_matrix;

  LA::MPI::Vector   locally_relevant_solution;// stores 
owned elements and also ghost entries. Initiated in setup_system().

  LA::MPI::Vector   locally_incremental_displacement; // stores 
owned elements only. Initiated in setup_system(), in refine_initial_grid() 
and in create_coarse_grid()

  LA::MPI::Vector   locally_accumulated_displacement; // stores 
owned elements only. Initiated in setup_system(), in refine_initial_grid() 
and in create_coarse_grid()

  LA::MPI::Vector   system_rhs;

  

  // Constitutive laws

  ...

  // IO

  ...

  debug_parallel_IO dbgIO;

  

};


Here is the constructor:


template 

SmallStrainMechanicalProblem::SmallStrainMechanicalProblem (

 const std::
string pathstr,

 const 
unsigned poly_degree,

 const 
unsigned printEveryNSteps)

:

mpi_communicator (MPI_COMM_WORLD),

n_mpi_processes (Utilities::MPI::n_mpi_processes(mpi_communicator)),

this_mpi_process (Utilities::MPI::this_mpi_process(mpi_communicator)),

pcout (std::cout, this_mpi_process == 0),

starting_index_per_process( n_mpi_processes ),

ending_index_per_process( n_mpi_processes ),

triangulation(mpi_communicator,

  typename Triangulation::MeshSmoothing

  (Triangulation::smoothing_on_refinement |

   Triangulation::smoothing_on_coarsening)),

dof_handler (triangulation),

fe(FE_Q(poly_degree), dim, // displacement

   FE_DGPMonomial(poly_degree - 1), 1, // pressure

   FE_DGPMonomial(poly_degree - 1), 1), // dilatation

quadrature_formula (poly_degree + 1),

face_quadrature_formula (4),

PrintEveryNSteps( printEveryNSteps ),

mmIO( pathstr,  this_mpi_process ),

IO( pathstr + "IO",  this_mpi_process ),

dbgIO( pathstr,  this_mpi_process )

{

...

}


the setup:



template 

void SmallStrainMechanicalProblem::setup_system ()

{


  

  dof_handler.distribute_dofs (fe);

  

  locally_owned_dofs = dof_handler.locally_owned_dofs();

  DoFTools::extract_locally_relevant_dofs (dof_handler,locally_relevant_dofs
);

  

  local_dofs_per_process = dof_handler.n_locally_owned_dofs_per_processor();

  

  starting_index_per_process[ 0 ] = 0;

  ending_index_per_process[ 0 ] = local_dofs_per_process[ 0 ] - 1;

  for (unsigned ii=1; ii< n_mpi_processes; ii++)

  {

starting_index_per_process[ ii ] = local_dofs_per_process[ ii-1 ] + 
starting_index_per_process[ ii-1 ] ;

ending_index_per_process[ ii ] = local_

[deal.II] GridGenerator::extract_boundary_mesh for parallel::shared::Triangulation

[Alberto Salvadori]

Hi all,

I am trying to reproduce the code in Step 38 that extracts the boundary 
mesh, but I'd love to use a parallel::shared::Triangulation rather than a 
Triangulation 
 
class. In a nutshell, I did this:



template 

class SmallStrainBeltramiDiffusionAndMechanicalProblem

{

 

public:

  [ ... ]

private:

  [ ... ]

  // Surface manifold dimension


  static const unsigned int manifold_dim = dim-1;


  // FEM member variables  

  parallel::shared::Triangulation   triangulation;

  parallel::shared::Triangulation   
manifold_triangulation;

  DoFHandler  dof_handler;

  DoFHandler  manifold_dof_handler;

  MappingQmanifold_mapping;


[ ... ]
}


template 

void SmallStrainBeltramiDiffusionAndMechanicalProblem::create_coarse_grid 
( bool neumann )

{

 

  const Point center;


  GridGenerator::hyper_ball (triangulation, center, 1.);

  triangulation.refine_global ( 6 ); 

  GridGenerator::extract_boundary_mesh (triangulation, 
manifold_triangulation); //, boundary_ids);

[ ...] 


}

  
I got this error message:

**

*An error occurred in line <220> of file 
<../source/distributed/tria_base.cc> in function*

*virtual types::subdomain_id dealii::parallel::Triangulation<1, 
2>::locally_owned_subdomain() const*

*The violated condition was: *

*dim > 1*

*The name and call sequence of the exception was:*

*ExcNotImplemented()*

*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  2   libdeal_II.g.8.4.1.dylib0x000108b2c3f7 
_ZNK6dealii8parallel13TriangulationILi1ELi2EE23locally_owned_subdomainEv + 
231: 2   libdeal_II.g.8.4.1.dylib0x000108b2c3f7 
_ZNK6dealii8parallel13TriangulationILi1ELi2EE23locally_owned_subdomainEv *

*#1  3   libdeal_II.g.8.4.1.dylib0x0001081ce7f1 
_ZNK6dealii12CellAccessorILi1ELi2EE8is_ghostEv + 577: 3   
libdeal_II.g.8.4.1.dylib0x0001081ce7f1 
_ZNK6dealii12CellAccessorILi1ELi2EE8is_ghostEv *

*#2  4   libdeal_II.g.8.4.1.dylib0x000108b2cb8f 
_ZN6dealii8parallel13TriangulationILi1ELi2EE19update_number_cacheEv + 1455: 
4   libdeal_II.g.8.4.1.dylib0x000108b2cb8f 
_ZN6dealii8parallel13TriangulationILi1ELi2EE19update_number_cacheEv *

*#3  5   libdeal_II.g.8.4.1.dylib0x000108b33f6d 
_ZN6dealii8parallel6shared13TriangulationILi1ELi2EE20create_triangulationERKNSt3__16vectorINS_5PointILi2EdEENS4_9allocatorIS7_RKNS5_INS_8CellDataILi1EEENS8_ISE_RKNS_11SubCellDataE
 
+ 413: 5   libdeal_II.g.8.4.1.dylib0x000108b33f6d 
_ZN6dealii8parallel6shared13TriangulationILi1ELi2EE20create_triangulationERKNSt3__16vectorINS_5PointILi2EdEENS4_9allocatorIS7_RKNS5_INS_8CellDataILi1EEENS8_ISE_RKNS_11SubCellDataE
 *

*#4  6   libdeal_II.g.8.4.1.dylib0x000107c383b9 
_ZN6dealii13GridGenerator21extract_boundary_meshINS_8parallel6shared13TriangulationELi2ELi2EEENSt3__13mapINT_IXmiT0_Li1EEXT1_EE13cell_iteratorENS7_IXT0_EXT1_EE13face_iteratorENS5_4lessIS9_EENS5_9allocatorINS5_4pairIKS9_SB_EERKSA_RS8_RKNS5_3setIhNSC_IhEENSE_Ih
 
+ 4537: 6   libdeal_II.g.8.4.1.dylib0x000107c383b9 
_ZN6dealii13GridGenerator21extract_boundary_meshINS_8parallel6shared13TriangulationELi2ELi2EEENSt3__13mapINT_IXmiT0_Li1EEXT1_EE13cell_iteratorENS7_IXT0_EXT1_EE13face_iteratorENS5_4lessIS9_EENS5_9allocatorINS5_4pairIKS9_SB_EERKSA_RS8_RKNS5_3setIhNSC_IhEENSE_Ih
 *

*#5  7   heat-eq 0x000100058754 
_ZN20SmallStrainMechanics48SmallStrainBeltramiDiffusionAndMechanicalProblemILi2EE18create_coarse_gridEb
 
+ 196: 7   heat-eq 0x000100058754 
_ZN20SmallStrainMechanics48SmallStrainBeltramiDiffusionAndMechanicalProblemILi2EE18create_coarse_gridEb
 *

*#6  8   heat-eq 0x00010005432f 
_ZN20SmallStrainMechanics48SmallStrainBeltramiDiffusionAndMechanicalProblemILi2EE16do_timestep_zeroEjPK26TimeIntegrationDataManagerb
 
+ 191: 8   heat-eq 0x00010005432f 
_ZN20SmallStrainMechanics48SmallStrainBeltramiDiffusionAndMechanicalProblemILi2EE16do_timestep_zeroEjPK26TimeIntegrationDataManagerb
 *

*#7  9   heat-eq 0x0001000343cd 
_ZN20SmallStrainMechanics48SmallStrainBeltramiDiffusionAndMechanicalProblemILi2EE3runEjb
 
+ 717: 9  

Re: [deal.II] Re: component mask and Dirichlet bc application

[Alberto Salvadori]

Thank you Jean Paul,
very clear. Perhaps your notes could be added on the deal.II documentation
system, I believe this comprehensive description is not simple to been
acquired directly from the tutorials examples and class description.
Alberto


*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Thu, Jun 1, 2017 at 2:09 AM, Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> In my opinion both of the approaches that you've outlined are plausible
> ways of implementing Dirichlet constraints, but there are a couple of key
> differences that I can quickly outline. I'll refer to the approach listed
> in your first post as method 1 and the split approach in your second post
> as method 2.
>
> Method 1:
> - You need to create a union of component masks for the field components
> to be constrained. You can do this using ComponentMask::operator|
> <https://www.dealii.org/8.5.0/doxygen/deal.II/classComponentMask.html#a9070d2c18038c413113775e420cf9fef>,
> and there are examples of its use in the tutorials. So presumably
>
>> ComponentMask displacements_mask = fe.component_mask (displacements);
>
> would change to something like
>
>> const ComponentMask displacements_and_concentration_mask =
>> fe.component_mask (displacements) |  fe.component_mask (concentration);
>
> - You need to implement the definition of all constraints for a boundary
> into a single class, i.e. for the function
>
>> IncrementalDirichletBoundaryValues::vector_value (const Point
>> & p , Vector   & return_value) const
>
> all of the constrained components (as selected via the component mask) of
> return_value need to be sensibly defined.
> - With this monolithic approach (and unless you do something strange), you
> should never have conflicting definitions of a constraint on a boundary.
>
> Method 2:
> - You are first imposing one set of constraints, and then a second. This
> is now a sequential operation rather than a monolithic one as used in
> method 1.
> - You need only have one std::map
> boundary_values, sequentially interpolate all of the Dirichlet constraint
> definitions into the map and apply them once. This is more computationally
> efficient (you only modify the linear system once).
> - Applying multiple boundary conditions to subsets of DoFs on a boundary
> introduces the possibility of overwriting constraints (e.g. by accidentally
> selecting the same component of a ComponentMask twice). So you could
> introduce a bug where the second constraint definition dominates the first.
> There is a warning on this point in the documentation to
> VectorTools::interpolate_boundary_values
> <https://www.dealii.org/8.5.0/doxygen/deal.II/namespaceVectorTools.html#a9f3e3ae1396811f998cc35f94cbaa926>.
> This would normally only require consideration for DoFs shared between
> adjacent Dirichlet boundaries, but now some extra care must be taken in
> this situation.
>
> If it makes any difference, my personal preference is to use method 2.
> With this approach you can define interesting boundary conditions once and
> then easily mix and match which are applied to which components of
> different boundaries. But, of course, opinions would differ based on design
> philosophies and (perhaps) mathematical rigour related to the theory on
> boundary value problems.
>
> Best,
> J-P
>
> On Thursday, June 1, 2017 at 1:54:23 AM UTC+2, Alberto Salvadori wrote:
>>
>> I am adding here an attempt I made. It seems to work but since this was
>> more intuition rather than full understanding, I do appreciate your
>> comments.
>> So, this is what I did: basically, I created two Dirichlet boundary
>> conditions and two masks, and I applied conditions in sequence, like this:
>>
>>
>>   // Dirichlet bcs
>>
>>   // -
>>
>>
>>
>>   PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);
>>
>>
>>   // Dirichlet bc for displacements
>>
>>   {
>>
>>   std::map boundary_values;
>>
>>
>>   ComponentMask displacements_mask = fe.component_mask (displacements);
>>
>>   VectorTools::interpolate_boundary_values (dof_handler,
>>
>> 0,
>>
>>
>> IncrementalDirichletBoundaryValues( TIDM, NRit, GPDofs ),
>>
>> boundary_values,
>>
>>  

[deal.II] Re: component mask and Dirichlet bc application

[Alberto Salvadori]

I am adding here an attempt I made. It seems to work but since this was 
more intuition rather than full understanding, I do appreciate your 
comments.
So, this is what I did: basically, I created two Dirichlet boundary 
conditions and two masks, and I applied conditions in sequence, like this:


  // Dirichlet bcs

  // -

  

  PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);


  // Dirichlet bc for displacements

  {

  std::map boundary_values;


  ComponentMask displacements_mask = fe.component_mask (displacements);

  VectorTools::interpolate_boundary_values (dof_handler,

0,


IncrementalDirichletBoundaryValues( TIDM, NRit, GPDofs ),

boundary_values,

displacements_mask);

  

  MatrixTools::apply_boundary_values (boundary_values,

  system_matrix,

  tmp,

  system_rhs,

  false);

  }


  // Dirichlet bc for concentrations

  {

std::map boundary_values;



ComponentMask displacements_mask = fe.component_mask (concentration);

VectorTools::interpolate_boundary_values (dof_handler,

  0,

  
IncrementalDirichletBoundaryValuesForConcentration( TIDM, NRit, GPDofs 
),

  boundary_values,

  displacements_mask);



PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);

MatrixTools::apply_boundary_values (boundary_values,

system_matrix,

tmp,

system_rhs,

false);

  }


  incremental_displacement = tmp;


Within the classes IncrementalDirichletBoundaryValuesForConcentration
I have returned something like:

template 

void

IncrementalDirichletBoundaryValuesForConcentration::

vector_value (const Point & p ,

  Vector   & return_value) const

{

  

  static const unsigned intc_component = dim + 2;

  return_value( c_component ) = ... ;

}


Does it make sense?

Thanks
Alberto

Il giorno mercoledì 31 maggio 2017 17:48:13 UTC-4, Alberto Salvadori ha 
scritto:
>
> Dear all,
>
> your help is appreciated about how component mask and Dirichlet bc 
> application work. 
>
> I am implementing a SmallStrainDiffusionMechanicalProblem class, with 4 
> fields: displacements, pressure, dilatation, and concentration. 
>
> template 
>
> class SmallStrainDiffusionMechanicalProblem
>
> {
>
> ...
>
>
>   // dofs definiton and dofs block enumeration
>
>   //  dim = displacements dofs
>
>   //  1 = p
>
>   //  1 = J
>
>   //  1 = c ( interstitial concentration )
>
>   const unsigned int GPDofs = dim + 3;
>
>
>   static const unsigned intfirst_u_component = 0;
>
>   static const unsigned intp_component = dim;
>
>   static const unsigned intJ_component = dim + 1;
>
>   static const unsigned intc_component = dim + 2;
>
>
>   enum
>
>   {
>
> u_dof = 0,  // displacement block ( dim components )
>
> p_dof = 1,  // pressure block ( one component )
>
> J_dof = 2,  // dilatation block ( one component )
>
> c_dof = 3   // concentration block ( one component )
>
>   };
>
>   
>
> ...
>
> }
>
>
> In a former implementation that did not include concentration fields, in 
> order to impose bc to the vector solution incremental_displacement, I 
> have edited some code from the tutorials, like this:
>
>
>   const FEValuesExtractors::Vector displacements (first_u_component);
>
>   const FEValuesExtractors::Scalar pressure(p_component);
>
>   const FEValuesExtractors::Scalar dilatation(J_component);
>
>   const FEValuesExtractors::Scalar concentration(c_component);
>
> ..
>
>   std::map boundary_values;
>
>
>   ComponentMask displacements_mask = fe.component_mask (displacements);
>
>   VectorTools::interpolate_boundary_values (dof_handler,
>
> 0,
>
> 
> IncrementalDirichletBoundaryValues( TIDM, NRit, GPDofs ),
>
> boundary_values,
>
> displacements_mask);
>
>   
>
>   PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);
>
>   MatrixTools::apply_boundary_values 

[deal.II] component mask and Dirichlet bc application

[Alberto Salvadori]

Dear all,

your help is appreciated about how component mask and Dirichlet bc 
application work. 

I am implementing a SmallStrainDiffusionMechanicalProblem class, with 4 
fields: displacements, pressure, dilatation, and concentration. 

template 

class SmallStrainDiffusionMechanicalProblem

{

...


  // dofs definiton and dofs block enumeration

  //  dim = displacements dofs

  //  1 = p

  //  1 = J

  //  1 = c ( interstitial concentration )

  const unsigned int GPDofs = dim + 3;


  static const unsigned intfirst_u_component = 0;

  static const unsigned intp_component = dim;

  static const unsigned intJ_component = dim + 1;

  static const unsigned intc_component = dim + 2;


  enum

  {

u_dof = 0,  // displacement block ( dim components )

p_dof = 1,  // pressure block ( one component )

J_dof = 2,  // dilatation block ( one component )

c_dof = 3   // concentration block ( one component )

  };

  

...

}


In a former implementation that did not include concentration fields, in 
order to impose bc to the vector solution incremental_displacement, I have 
edited some code from the tutorials, like this:


  const FEValuesExtractors::Vector displacements (first_u_component);

  const FEValuesExtractors::Scalar pressure(p_component);

  const FEValuesExtractors::Scalar dilatation(J_component);

  const FEValuesExtractors::Scalar concentration(c_component);

..

  std::map boundary_values;


  ComponentMask displacements_mask = fe.component_mask (displacements);

  VectorTools::interpolate_boundary_values (dof_handler,

0,


IncrementalDirichletBoundaryValues( TIDM, NRit, GPDofs ),

boundary_values,

displacements_mask);

  

  PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);

  MatrixTools::apply_boundary_values (boundary_values,

  system_matrix,

  tmp,

  system_rhs,

  false);

  incremental_displacement = tmp;

I would now impose Dirichlet bc on both displacements and concentrations 
and assume that the Dirichlet boundary for both fields is the same. Shall I 
therefore change the mask, I assume. Can it be done like this? 

ComponentMask displacements_mask = fe.component_mask (displacements, 
concentrations);

or shall two masks be defined or even else?

Many thanks!
Alberto


-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

[Alberto Salvadori]

Thank you Daniel and Jean-Paul.

Indeed I am using PETSc wrappers and the columns manipulation is not
active. And indeed if I run a little less academic example, i.e. more than
a single element, CG converges. Just to know, in case of a single element
CG does not, likely this is not unexpected. The error message is quite
self-explanatory (note that the solution is actually zero...):

**

*Exception on processing: *


**

*An error occurred in line <151> of file <../source/lac/petsc_solver.cc> 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: *

*false*

*The name and call sequence of the exception was:*

*SolverControl::NoConvergence (solver_control.last_step(),
solver_control.last_value())*

*Additional Information: *

*Iterative method reported convergence failure in step 0. The residual in
the last step was nan.*


*This error message can indicate that you have simply not allowed a
sufficiently large number of iterations for your iterative solver to
converge. This often happens when you increase the size of your problem. In
such cases, the last residual will likely still be very small, and you can
make the error go away by increasing the allowed number of iterations when
setting up the SolverControl object that determines the maximal number of
iterations you allow.*


*The other situation where this error may occur is when your matrix is not
invertible (e.g., your matrix has a null-space), or if you try to apply the
wrong solver to a matrix (e.g., using CG for a matrix that is not symmetric
or not positive definite). In these cases, the residual in the last
iteration is likely going to be large.*

**


*Aborting!*

**

*Program ended with exit code: 1*

I am again very grateful with deal.II community, this is a great plus and I
hope one day to contribute, once my expertise will allow me to. Final
questions to close this call:

1 - Can I manage the exception in a way that in case CG does not converge I
can try GMRes rather than aborting? Is the usual try-catch instruction
working?
2 - I see that the class PETScWrappers implements both BiCGStab and GMRes.
Can you pinpoint to an example?

Thanks
Alberto



*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Thu, Apr 20, 2017 at 5:20 AM, Daniel Arndt <
daniel.ar...@iwr.uni-heidelberg.de> wrote:

> Alberto,
>
> Now I understand your concern. The boolean flag that is passed as the
>> final parameter to MatrixTools::apply_boundary_values
>> <https://www.dealii.org/8.5.0/doxygen/deal.II/namespaceMatrixTools.html#a9ad0eb7a8662628534586716748d62fb>
>> determines whether column elimination is performed. You've set it to false,
>> so this is not done and the RHS is unaltered. So switching it to true (the
>> default) should preserve the symmetry of the system and make the necessary
>> adjustments to the RHS vector.
>>
> While this is true in general, for PETSc and Trilinos matrices only the
> case "eliminate_columns = false" is implemented [1].
> This means that your system matrix will not be symmetric if you are using
> MatrixTools::apply_boundary_values, but a CG will likely still work [2,
> Global elimination].
>
> Best,
> Daniel
>
> [1] https://www.dealii.org/developer/doxygen/deal.II/
> namespaceMatrixTools.html#a96d8a143c787e0dca41ce6168152dc04
> [2] https://www.dealii.org/developer/doxygen/deal.II/
> namespaceMatrixTools.html
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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 Go

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

[Alberto Salvadori]

Dear Jean-Paul,

thanks for your reply.

I see your point. It was my understanding (wrong, I guess) that in imposing
Dirichlet BC deal.II would modify the rows but also the columns, adjusting
the rhs accordingly. In this way, the symmetry of the system matrix would
have been preserved. I see now that this is not happening, in all cases, is
it correct? Then my question is about the solver, can we still use CG as a
solver if the system matrix looses symmetry? Does deal.II make some further
elaboration?

Thank you again

Alberto





*Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura,
Territorio, Ambiente e di Matematica (DICATAM)
 Universita` di Brescia, via Branze 43, 25123 Brescia
 Italy
 tel 030 3711239
 fax 030 3711312

e-mail:
 alberto.salvad...@unibs.it
web-pages:
 http://m4lab.unibs.it/faculty.html
 http://dicata.ing.unibs.it/salvadori

On Tue, Apr 18, 2017 at 11:10 AM, Jean-Paul Pelteret 
wrote:

> Dear Alberto,
>
> The correctness of my answer depends on the numbering assigned to the
> degrees-of-freedom, which is something that you've not mentioned above. But
> from what I can discern the 9th row relates to the pressure test function,
> so K_{8,[0-7]} are the components from the coupling block K_{pu}, K_{88} is
> K_{pp} and K_{89} is K_{pJ}. Since these degree's of freedom are not
> constrained, this row should remain untouched after boundary values are
> applied. So, to me, nothing necessarily appears amiss on row 9 (as you've
> indicated).
>
> Do you agree with this?
>
> Kind regards,
> Jean-Paul
>
> On Tuesday, April 18, 2017 at 12:32:44 PM UTC+2, Alberto Salvadori wrote:
>>
>> Hi,
>>
>> sorry for asking your help again, that I really appreciated.
>> Today's issue is about imposing boundary conditions for a three-fields
>> formulation.
>>
>> In brief, I defined a 4 nodes square element, of type:
>>
>> fe(FE_Q(poly_degree), dim, // displacement
>>
>>FE_DGPMonomial(poly_degree - 1), 1, // pressure
>>
>>FE_DGPMonomial(poly_degree - 1), 1), // dilatation
>>
>> with  poly_degree = 1.
>>
>> While debugging on a single element, which has 10 dofs in 2D ( 4x2
>> displacements + 1 pressure + 1 dilatation), I aim at imposing Dirichlet
>> boundary conditions on displacements, whereas body forces are zero.
>>
>> The cell matrix and the cell_rhs are the following.
>>
>> *Cell matrix = *
>>
>> *{  0.7037,   0.0278,  -0.2037,  -0.4722,  -0.1481,   0.4722,  -0.3519,
>> -0.0278,  -1.,   0.}, *
>>
>> *{  0.0278,   0.7037,   0.4722,  -0.1481,  -0.4722,  -0.2037,  -0.0278,
>> -0.3519,  -1.,   0.}, *
>>
>> *{ -0.2037,   0.4722,   0.7037,  -0.0278,  -0.3519,   0.0278,  -0.1481,
>> -0.4722,   1.,   0.}, *
>>
>> *{ -0.4722,  -0.1481,  -0.0278,   0.7037,   0.0278,  -0.3519,   0.4722,
>> -0.2037,  -1.,   0.}, *
>>
>> *{ -0.1481,  -0.4722,  -0.3519,   0.0278,   0.7037,  -0.0278,  -0.2037,
>> 0.4722,  -1.,   0.}, *
>>
>> *{  0.4722,  -0.2037,   0.0278,  -0.3519,  -0.0278,   0.7037,  -0.4722,
>> -0.1481,   1.,   0.}, *
>>
>> *{ -0.3519,  -0.0278,  -0.1481,   0.4722,  -0.2037,  -0.4722,   0.7037,
>> 0.0278,   1.,   0.}, *
>>
>> *{ -0.0278,  -0.3519,  -0.4722,  -0.2037,   0.4722,  -0.1481,   0.0278,
>> 0.7037,   1.,   0.}, *
>>
>> *{ -1.,  -1.,   1.,  -1.,  -1.,   1.,   1.,
>> 1.,   0.,  -4.}, *
>>
>> *{  0.,   0.,   0.,   0.,   0.,   0.,   0.,
>> 0.,  -4.,   6.6667}, *
>>
>> *Cell rhs =0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00
>> 0.000e+00 0.000e+00 0.000e+00 0.000e+00 *
>>
>> They seem to be correct. After calling
>>
>>   system_matrix.compress(VectorOperation::add);
>>
>>   system_rhs.compress(VectorOperation::add);
>>
>> the system matrix coincides with the cell matrix, the same for the rhs.
>> To impose BCs I followed the scheme of step-18, as follows:
>>
>>   std::map boundary_values;
>>
>>
>>   ComponentMask displacements_mask = fe.component_mask (displacements);
>>
>>   VectorTools::interpolate_boundary_values (dof_handler,
>>
>> 0,
>>
>> IncrementalDirichletBoundary
>> Values( TIDM, NRit, GPDofs ),
>>
>> boundary_values,
>>
>> displacements_mask);
>>
>>
>>
>>   PETScWrappers::MPI::Vecto

[deal.II] imposing boundary conditions for a three-fields formulation

[Alberto Salvadori]

Hi, 

sorry for asking your help again, that I really appreciated. 
Today's issue is about imposing boundary conditions for a three-fields 
formulation.

In brief, I defined a 4 nodes square element, of type:

fe(FE_Q(poly_degree), dim, // displacement

   FE_DGPMonomial(poly_degree - 1), 1, // pressure

   FE_DGPMonomial(poly_degree - 1), 1), // dilatation

with  poly_degree = 1.

While debugging on a single element, which has 10 dofs in 2D ( 4x2 
displacements + 1 pressure + 1 dilatation), I aim at imposing Dirichlet 
boundary conditions on displacements, whereas body forces are zero. 

The cell matrix and the cell_rhs are the following.

*Cell matrix = *

*{  0.7037,   0.0278,  -0.2037,  -0.4722,  -0.1481,   0.4722,  -0.3519,  
-0.0278,  -1.,   0.}, *

*{  0.0278,   0.7037,   0.4722,  -0.1481,  -0.4722,  -0.2037,  -0.0278,  
-0.3519,  -1.,   0.}, *

*{ -0.2037,   0.4722,   0.7037,  -0.0278,  -0.3519,   0.0278,  -0.1481,  
-0.4722,   1.,   0.}, *

*{ -0.4722,  -0.1481,  -0.0278,   0.7037,   0.0278,  -0.3519,   0.4722,  
-0.2037,  -1.,   0.}, *

*{ -0.1481,  -0.4722,  -0.3519,   0.0278,   0.7037,  -0.0278,  -0.2037,   
0.4722,  -1.,   0.}, *

*{  0.4722,  -0.2037,   0.0278,  -0.3519,  -0.0278,   0.7037,  -0.4722,  
-0.1481,   1.,   0.}, *

*{ -0.3519,  -0.0278,  -0.1481,   0.4722,  -0.2037,  -0.4722,   0.7037,   
0.0278,   1.,   0.}, *

*{ -0.0278,  -0.3519,  -0.4722,  -0.2037,   0.4722,  -0.1481,   0.0278,   
0.7037,   1.,   0.}, *

*{ -1.,  -1.,   1.,  -1.,  -1.,   1.,   1.,   
1.,   0.,  -4.}, *

*{  0.,   0.,   0.,   0.,   0.,   0.,   0.,   
0.,  -4.,   6.6667}, *

*Cell rhs =0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 
0.000e+00 0.000e+00 0.000e+00 0.000e+00 *

They seem to be correct. After calling

  system_matrix.compress(VectorOperation::add);

  system_rhs.compress(VectorOperation::add);

the system matrix coincides with the cell matrix, the same for the rhs. To 
impose BCs I followed the scheme of step-18, as follows:

  std::map boundary_values;


  ComponentMask displacements_mask = fe.component_mask (displacements);

  VectorTools::interpolate_boundary_values (dof_handler,

0,


IncrementalDirichletBoundaryValues( TIDM, NRit, GPDofs ),

boundary_values,

displacements_mask);

  

  PETScWrappers::MPI::Vector tmp (locally_owned_dofs,mpi_communicator);

  MatrixTools::apply_boundary_values (boundary_values,

  system_matrix,

  tmp,

  system_rhs,

  false);

  incremental_displacement = tmp;

where the class IncrementalDirichletBoundaryValues implements the Dirichlet 
BC and GPDofs = 4. 
The boundary values after VectorTools::interpolate_boundary_values turn out 
to be:

*boundary_values = -0.0500,  -0.0500,  -0.0500,   0.0500,   0.0500,  
-0.0500,   0.0500,   0.0500,   0.,   0., *

*tmp = -0.0500,  -0.0500,  -0.0500,   0.0500,   0.0500,  -0.0500,   0.0500, 
  0.0500,   0.,   0., *

which are pretty much what I expected. However, after MatrixTools
::apply_boundary_values  the system matrix and the rhs are as follows, 

* System matrix = *

*{  0.7037,   0.,   0.,   0.,   0.,   0.,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.7037,   0.,   0.,   0.,   0.,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.7037,   0.,   0.,   0.,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.,   0.7037,   0.,   0.,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.,   0.,   0.7037,   0.,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.,   0.,   0.,   0.7037,   0.,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.,   0.,   0.,   0.,   0.7037,   
0.,   0.,   0.}, *

*{  0.,   0.,   0.,   0.,   0.,   0.,   0.,   
0.7037,   0.,   0.}, *

*{ -1.,  -1.,   1.,  -1.,  -1.,   1.,   1.,   
1.,   0.,  -4.}, *

*{  0.,   0.,   0.,   0.,   0.,   0.,   0.,   
0.,  -4.,   6.6667}, *

*System_rhs = -0.0352,  -0.0352,  -0.0352,   0.0352,   0.0352,  -0.0352,   
0.0352,   0.0352,   0.,   0., *

The* System_rhs *seems correct, but the matrix, particularly the 9th row, 
does not, but I am not sure why.

Many thanks in advance,
Alberto

-- 

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://g

Re: [deal.II] Separate components from the solution vector

[Alberto Salvadori]

Thanks Wolfgang,
step-22 is exactly what I was looking for. 
It works just fine, now.
Alberto

Il giorno lunedì 17 aprile 2017 10:43:56 UTC-4, Wolfgang Bangerth ha 
scritto:
>
> On 04/17/2017 08:37 AM, Alberto Salvadori wrote: 
> > Thanks Wolfgang. 
> > What you surmised is exactly what it is happening, see the error message 
> below. 
> > I have no run-time errors in running this code 
> > 
> >   
> conststd::vector 
> > 
> > data_component_interpretation(dim+2, 
> > DataComponentInterpretation::component_is_part_of_vector); 
> > 
> >   data_out.add_data_vector(system_solution, 
> > 
> >std::vector (dim+2, 
> "displacement"), 
> > 
> >DataOut::type_dof_data, 
> > data_component_interpretation); 
> > 
> > 
> > but I believe it is not what I want. I suppose that the data_out 
> contains now 
> > 4 components for each node, two displacements, plus pressure and 
> dilatation. 
> > I'd love to export displacements 
> > and the other two separately, but I am not sure how to achieve this. 
> Doing this: 
> > 
> >   data_out.add_data_vector(system_solution, 
> > 
> >std::vector (dim, 
> "displacement"), 
> > 
> >DataOut::type_dof_data, 
> > data_component_interpretation); 
> > 
> > 
> > provides an run-time error, which makes sense. 
>
> Just provide the missing components to the data_out_interpretation -- take 
> a 
> look at step-22 how this looks like. 
>
> Why do you want to output things separately? Why not have everything in 
> one 
> output file? (It's possible to extract individual components using a 
> DataPostprocessor, but I don't usually understand why one would want to do 
> that.) 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>
-- 

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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Separate components from the solution vector

[Alberto Salvadori]

Thanks Wolfgang.
What you surmised is exactly what it is happening, see the error message 
below.
I have no run-time errors in running this code

  const std::vector

data_component_interpretation(dim+2, DataComponentInterpretation::
component_is_part_of_vector);

  data_out.add_data_vector(system_solution,

   std::vector (dim+2, "displacement"),

   DataOut::type_dof_data, 
data_component_interpretation);

but I believe it is not what I want. I suppose that the data_out contains 
now 4 components for each node, two displacements, plus pressure and 
dilatation. I'd love to export displacements 
and the other two separately, but I am not sure how to achieve this. Doing 
this:

  data_out.add_data_vector(system_solution,

   std::vector (dim, "displacement"),

   DataOut::type_dof_data, 
data_component_interpretation);

provides an run-time error, which makes sense. 
Thanks,
Alberto



**

*An error occurred in line <984> of file 
<../source/numerics/data_out_dof_data.cc> in function*

*void dealii::DataOut_DoFData, 2, 
2>::add_data_vector(const VectorType &, const std::vector &, 
const dealii::DataOut_DoFData::DataVectorType, const 
std::vector &) 
[VectorType = dealii::Vector]*

*The violated condition was: *

*names.size() == dofs->get_fe().n_components()*

*The name and call sequence of the exception was:*

*Exceptions::DataOut::ExcInvalidNumberOfNames (names.size(), 
dofs->get_fe().n_components())*

*Additional Information: *

*You have to give one name per component in your data vector. The number 
you gave was 2, but the number of components is 4.*


Il giorno lunedì 17 aprile 2017 10:24:23 UTC-4, Wolfgang Bangerth ha 
scritto:
>
> On 04/17/2017 08:09 AM, Alberto Salvadori wrote: 
> >   DataOut data_out; 
> > 
> >   data_out.attach_dof_handler(dof_handler); 
> > 
> > 
> > 
> >   // displacement output 
> > 
> > 
> >   
> conststd::vector 
> > 
> > data_component_interpretation(dim, 
> > DataComponentInterpretation::component_is_part_of_vector); 
> > 
> >   data_out.add_data_vector(system_solution, 
> > 
> >std::vector (dim, 
> "displacement"), 
> > 
> >DataOut::type_dof_data, 
> > data_component_interpretation); 
> > 
> > 
> > 
> > is inappropriate as it stands, since the system_solution contains u,p,J 
> and I 
> > want to extract u, p and J separately. Any hint? 
>
> Alberto -- what happens if you do this? I suspect that if the DoFHandler 
> you 
> attach above has components for both u,p,J and I, then passing in a 
> data_component_interpretation that only contains 'dim' elements will not 
> work 
> -- you need to account for *all* vector components of the finite element 
> upon 
> which the DoFhandler is built. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>
-- 

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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Separate components from the solution vector

[Alberto Salvadori]

Hi,

thanks in advance for your suggestions.

I have been working on a small strain version of the three-fields 
formulation proposed in step 44. To this aim, I have been extended step 18, 
including some non linear material models.
It is my understanding that there are two ways of assembling and solving 
the system. One way simply extends the data structure of step 18, by using 
a different FESystem and solving a larger linear system at the end.
The second way is using block data-structures and solving via Shur 
complement. I aim at doing both, to get to learn.

The first strategy seems a little easier. I defined the FESystem following 
step 44

fe(FE_Q(poly_degree), dim, // displacement

   FE_DGPMonomial(poly_degree - 1), 1, // pressure

   FE_DGPMonomial(poly_degree - 1), 1), // dilatation

and with some minor adjustments I got to solve the system. I am having a 
little trouble in output data, since I want to separate displacements, 
pressure, and dilatation from the solution vector and I am not sure how 
this can be achieved.
This set of instructions:

  DataOut data_out;

  data_out.attach_dof_handler(dof_handler);

  

  // displacement output


  const std::vector

data_component_interpretation(dim, DataComponentInterpretation::
component_is_part_of_vector);

  data_out.add_data_vector(system_solution,

   std::vector (dim, "displacement"),

   DataOut::type_dof_data, 
data_component_interpretation);



is inappropriate as it stands, since the system_solution contains u,p,J and 
I want to extract u, p and J separately. Any hint?
Thanks 

Alberto

-- 

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.
For more options, visit https://groups.google.com/d/optout.