Re: [deal.II] Re: How to build dealii into a single static-linked executable?

[Wolfgang Bangerth]

On 08/08/2018 10:28 AM, Bruno Turcksin wrote:




Static linking should be avoided unless you need to. For example, if you are 
on a Cray you probably have to do static linking. Honestly, all the advantages 
given in the blog are not real advantages in practice (good luck compiling 
your application on you desktop and then running it on a cluster).


In particular, you will find that linking your application against the deal.II 
(statically linked) library takes forever: several minutes. That's acceptable 
if you want to do it only once, when your application is fully developed. ut 
if you are still changing things, you will come to realize that that's going 
to strain your patience.


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

[deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

[Sambit Das]

Hi All,


I have a question about resolving chains of constraints in a 
ConstraintMatrix class object after calling close() in a parallel 
distributed case:


I created a ConstraintMatrix with both periodic and hanging node 
constraints, and called close().

Then I picked a constrained degree of freedom, lets say with global dof id 
= “i” and printed the constraint equation pairs (j,a_ij) corresponding to 
“i” on the processor for which “i” is locally owned as well as the 
processors for which “i” is a ghost. I expected the constraint equation to 
be the same for owning processor and the ghost processor, however we have 
encountered a case where printing the constraint equation entries shows 
different 
“j” for owning and ghost processorsalthough a_ij are same. When we printed 
the coordinates of “j” which were different, we found that those two nodes 
to be periodic images of each other.


Should I except the constraint equation to be the same for the owning 
processor and the ghost processors?


Thank you,

Sambit

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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] deal.II Newsletter #43

[Rene Gassmoeller]

Hello everyone!

This is deal.II newsletter #43.
It automatically reports recently merged features and discussions about the 
deal.II finite element library.


## Below you find a list of recently proposed or merged features:

#7043: doc: fix formatting of pre block (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/7043

#7042: Consider periodic neighbors during grid refinement in serial (proposed 
by masterleinad) https://github.com/dealii/dealii/pull/7042

#7038: Make C++17 support independent of the special math functions. (proposed 
by drwells; merged) https://github.com/dealii/dealii/pull/7038

#7036: Cuda constraints for matrix-free (proposed by Rombur) 
https://github.com/dealii/dealii/pull/7036

#7035: Use CamelCase in namespaces (proposed by dangars; merged) 
https://github.com/dealii/dealii/pull/7035

#7034: Add transformation function between bases in matrix-free (proposed by 
kronbichler; merged) https://github.com/dealii/dealii/pull/7034

#7032: Add interleaved dof storage for DG to MatrixFree (proposed by 
kronbichler) https://github.com/dealii/dealii/pull/7032

#7031: Add Triangulation::active_face_iterators(). (proposed by drwells; 
merged) https://github.com/dealii/dealii/pull/7031

#7030: Add initlog to grid tests (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/7030

#7029: Remove unused variables in LA::d::Vector::import (proposed by 
masterleinad; merged) https://github.com/dealii/dealii/pull/7029

#7028: Reduce output of cell_categorization_02 (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/7028

#7027:  Check for consistent manifold ids in 2D when creating a Triangulation 
(proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7027

#7026: Fix formatting of our coding conventions. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/7026

#7025: Make an argument of GridGenerator::merge_triangulations() a reference. 
(proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7025

#7024: Provide test for higher order VTU output  (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/7024

#7022: Fix bug in import in LinearAlgebra::distributed::Vector (proposed by 
Rombur; merged) https://github.com/dealii/dealii/pull/7022

#7020: Add HDF5 classes (proposed by dangars) 
https://github.com/dealii/dealii/pull/7020

#7019: Use common type in AssertIndexRange for the comparison (proposed by 
masterleinad; merged) https://github.com/dealii/dealii/pull/7019

#7018: Fix doxygen documentation for 
DataOutBase::VtkFlags::write_higher_order_cells (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/7018

#7017: fix cell_vectorization_category with MG (proposed by davydden; merged) 
https://github.com/dealii/dealii/pull/7017

#7016: Fix restrictions and warnings for some tests (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/7016

#7015: Add support for high-order VTU output (proposed by agrayver; merged) 
https://github.com/dealii/dealii/pull/7015

#7012:  Allow merging multiple Triangulation objects at once  (proposed by 
masterleinad; merged) https://github.com/dealii/dealii/pull/7012

#7004: Document new VTK extensions and restrictions. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/7004

#7002: Applies variable size transfer to 'ParticleHandler'. (proposed by 
marcfehling; merged) https://github.com/dealii/dealii/pull/7002

#6959: Add a script that counts lines of code. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/6959

#6904: Implement The Bernardi-Raugel Finite Element (proposed by 
GrahamBenHarper; merged) https://github.com/dealii/dealii/pull/6904

#6900: Update step 9 (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/6900

#6241: ScaLAPACKMatrix: copy functions (proposed by BenBrands; merged) 
https://github.com/dealii/dealii/pull/6241


## And this is a list of recently opened or closed discussions:

#7041: improvement to periodic BC (opened) 
https://github.com/dealii/dealii/issues/7041

#7040: Dead link in online documentation (opened) 
https://github.com/dealii/dealii/issues/7040

#7039: Revise names in internal::EvaluatorTensorProduct (opened) 
https://github.com/dealii/dealii/issues/7039

#7037: CUDA support (opened) https://github.com/dealii/dealii/issues/7037

#7033: Valid boundary ids when creating a Triangualation (opened) 
https://github.com/dealii/dealii/issues/7033

#7023: Document steps to best visualise higher-order output in Paraview 
(opened) https://github.com/dealii/dealii/issues/7023

#7021: Update tutorials about higher order VTK output (opened) 
https://github.com/dealii/dealii/issues/7021

#7014: Apple LLVM 9.1.0 C++17 issues (opened and closed) 
https://github.com/dealii/dealii/issues/7014

#7009: cell_vectorization_category on GMG (closed) 
https://github.com/dealii/dealii/issues/7009

#7007: 

[deal.II] Re: Normal flux as essential boundary condition

[Daniel Arndt]

Konrad,

VectorTools::project_boundary_ 
> values_div_conforming
>   
>
> is
>  
> then according to my understanding a pure projection (as the name suggests) 
> of vector valued functions to the Raviart-Thomas space. This is clearly a 
> helpful function (for even more than just boundaries) but not in 
> prescribing flux or traction boundary conditions since, as you mentioned, 
> this implicitly requires knowledge of the face normal but this is imo not 
> desired from the user perspective (complicated or changing domains?). For 
> traction BCs it is even more complicated since that means you need to 
> prescribe stress tensors. This unfortunately makes it difficult to 
> prescribe such BCs. 
>
> The strategy that I chose works for the lowest order Raviart-Thomas 
> element but what about higher order (because the dofs are edge moment?)?
>
Actually, it should be quite simple to make modify 
VectorTools::project_boundary_values_div_conforming such that 
(scalar-valued) flux boundary conditions can be applied.
The only places where the boundary function currently enters is in 
VectorTools::internal::compute_face_projection_div_conforming(https://github.com/dealii/dealii/blob/master/include/deal.II/numerics/vector_tools.templates.h#L6400).
In particular, it is only used for multiplying with the normal vector 
immediately after.
You could try to copy the relevant parts out of 
include/deal.II/numerics/vector_tools.templates.h. We are of course also 
happy to take contributions in that direction.
If you need help with that, don't hesitate to ask.

Best,
Daniel

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

[deal.II] Re: How to build dealii into a single static-linked executable?

[Bruno Turcksin]

Di,

On Wednesday, August 8, 2018 at 12:13:16 PM UTC-4, 程迪 wrote:
>
> I noticed that static linking might be more appropriate for very large 
> scale computing. ref: 
> https://ro-che.info/articles/2016-09-09-static-binaries-scientific-computing
>
Static linking should be avoided unless you need to. For example, if you 
are on a Cray you probably have to do static linking. Honestly, all the 
advantages given in the blog are not real advantages in practice (good luck 
compiling your application on you desktop and then running it on a cluster).

But how to compile dealii into a single static-linked executable?
>
Here is the relevant documentation 
https://www.dealii.org/9.0.0/users/cmake.html#configurebuild Again, do it 
only if you have a good reason :-)

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.

[deal.II] How to build dealii into a single static-linked executable?

[程迪]

Hi, everyone.

I noticed that static linking might be more appropriate for very large 
scale computing. ref: 
https://ro-che.info/articles/2016-09-09-static-binaries-scientific-computing

But how to compile dealii into a single static-linked executable?

The cmake file should have some options. But I am not clear which part is 
doing the linking.

Di.

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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] implemention of periodic boundary condition

[Jean-Paul Pelteret]

Dear Chucui,

Thanks for the explanation - clearly I was wrong with regards to exactly how 
much complexity could be stripped from this example. Anyway, I think that 
Daniel has made the critical observation as to where the fault may lie. 
Hopefully his suggestion will sort this out for you.

Best,
Jean-Paul

> On 08 Aug 2018, at 16:38, chucui1...@gmail.com wrote:
> 
> Dear Jean-Paul,
> 
> Thank you very much for your patience, when I print some information like 
> this:
> 
> template 
> void Problem::run ()
> {
> [...]
>   setup_dofs ();
> std::cout << "test-1 "<< std::endl;  
> VectorTools::project (dof_handler_0, constraints_phi, 
> QGauss(degree+2),
> SolutionsPhi(),
> phi_0);  
> std::cout << "test-2 " << std::endl;  
> VectorTools::project (dof_handler_2, constraints_q, 
> QGauss(degree+2),
> SolutionsQ(),
> q_0);  
>  std::cout << "test-3 " << std::endl;   
> assemble_system_1 (phi_0);
>  std::cout << "test-4" << std::endl;   
> assemble_rhs_1 (phi_0, q_0);
>  std::cout << "test-5" << std::endl; 
> 
> and the output is
> 
> Linking CXX executable Case0-3
> [ 50%] Built target Case0-3
> [100%] Run with Debug configuration
>Number of active cells: 16384
>Number of degrees of freedom: 98818 (16641+16641+65536)
> test-1 
> test-2 
> test-3 
> 
> 
> An error occurred in line <1764> of file 
>  
> in function
> void 
> dealii::SparseMatrix::add(dealii::SparseMatrix::size_type, 
> dealii::SparseMatrix::size_type, number) [with number = double; 
> dealii::SparseMatrix::size_type = unsigned int]
> The violated condition was: 
> (index != SparsityPattern::invalid_entry) || (value == number())
> Additional information: 
> You are trying to access the matrix entry with index <0,1>, but this 
> entry does not exist in the sparsity pattern of this matrix.
> 
> 
> So it can't run when arrive at "assemble_system_1", so "setup-dof()",  
> "assemble_system_1()", "run()" are left—— this is LittleCase0-3.cc
> if only "setup_dof()", "run()" are left——this is LittleCase0-4.cc
> 
> Hope this is a minimal example. Thank you very much!
> 
> Best,
> Chucui
> 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> 
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.

Re: [deal.II] How to use intellisense to parse dealii code using visual studio remotely?

[Jean-Paul Pelteret]

Hi there,

I’m really happy to hear that you managed to work this out for yourself, and 
thanks a lot for posting your solution! I’m sure that will be very useful to 
our other Visual Studio users in the future.

Best,
Jean-Paul

> On 08 Aug 2018, at 17:07, 程迪  wrote:
> 
> 
> Hi everyone,
> 
> I just figured it out. According to 
> https://github.com/Microsoft/VSLinux/issues/272 ,the intellisense works if 
> CMakeSettings.json file is like this: 
> {
> // See https://go.microsoft.com//fwlink//?linkid=834763 for more 
> information about this file.
> "environments": [
> {
> "environment": "IS_includes", // this is used for intelliSense
> // ${env.USERPROFILE} == c:\Users\
> // ${env.LOCALAPPDATA} == c:\Users\\AppData\Local
> "INCLUDE": 
> "${env.INCLUDE};${env.USERPROFILE}\\dealII\\dealii_lib\\include;${env.LOCALAPPDATA}\\Microsoft\\Linux\\Header
>  Cache\\1.0\\919434520\\usr\\include"
> }
> ],
> "configurations": [
> {
> "name": "Linux-Debug",
> "generator": "Unix Makefiles",
> "remoteMachineName": "192.168.99.100",
> "configurationType": "Debug",
> "remoteCMakeListsRoot": "/var/tmp/src/${workspaceHash}/${name}",
> "cmakeExecutable": "/opt/cmake/3.12.0/bin/cmake",
> "buildRoot": 
> "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
> "installRoot": 
> "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}",
> "remoteBuildRoot": 
> "/var/tmp/build/${workspaceHash}/build/${name}",
> "remoteInstallRoot": 
> "/var/tmp/build/${workspaceHash}/install/${name}",
> "remoteCopySources": true,
> "remoteCopySourcesOutputVerbosity": "Normal",
> "remoteCopySourcesConcurrentCopies": "10",
> "remoteCopySourcesMethod": "sftp",
> "remoteCopyBuildOutput": true,
> "cmakeCommandArgs": "",
> "buildCommandArgs": "",
> "ctestCommandArgs": "",
> "inheritEnvironments": [ "linux_x64", "IS_includes" ]
> },
> 
> 
> 
> On Wednesday, August 8, 2018 at 1:09:58 AM UTC-4, 程迪 wrote:
> Hi, everyone.
> 
> I am trying to use visual studio 2017 linux dev workloads to compile and 
> debug tutorial step1 remotely on docker container. I want to use intellisense 
> of vs to help me. But I cannot figure out how.
> 
> Here is my steps:
> 
> 1. I followed 
> (https://docs.microsoft.com/en-us/cpp/linux/download-install-and-setup-the-linux-development-workload
>  
> )
>  to install and configured visual studio 2017 CE
> 
> 2. I installed docker engine on windows using virtualbox and boot2docker. And 
> I recreated the docker machine to use more cpus.
> # stop`default` docker machine
> docker-machine stop default
> # delet`default` docker machine，and all images
> docker-machine rm default
> # create `default` docker machine
> docker-machine create -d virtualbox --virtualbox-cpu-count=4 
> --virtualbox-memory=4096 --virtualbox-disk-size=5 default
> # Restart docker
> docker-machine stop
> exit
> 3. create a docker container:
> docker run --name dealii_vs -w /home/dealii -i -t -d -v 
> /c/Users/cheng:/home/dealii/shared -p 192.168.99.100:8022:22  -p 
> 192.168.99.100:8023-8025:8023-8025 --cap-add=SYS_PTRACE dealii/dealii:latest
> # --cap-add=SYS_PTRACE is necessary for gdbserver.
> docker exec -u root -it dealii_vs bash # use root to do something inside
> 4. configure inside of the docker container
> apt-get update 
> apt-get install openssh-server gdb gdbserver zip vim-nox -y  # download some 
> software, vim-nox is not necessary.
> # newer cmake, vs2017 need cmake 3.8+
> wget https://cmake.org/files/v3.12/cmake-3.12.0-Linux-x86_64.sh 
> 
> # install to /opt/cmake/3.12.0
> mkdir -p /opt/cmake/3.12.0
> ./cmake-3.12.0-Linux-x86_64.sh  
> --skip-license --prefix=/opt/cmake/3.12.0 --exclude-subdir
> 
> # modify sshd to auto load some env_vars.
> # vs 2017 is using ssh to run commands remotely in `non-interactive` shell, 
> which won't load `~/.bashrc` or docker's `ENV`
> # however, opensshd has an option to load some env_vars even in 
> `non-interactive` shell
> cat >>/etc/ssh/sshd_config < # add by Di Cheng
> PermitUserEnvironment yes
> EOF
> # add environment variable, almost identical to output of `docker exec 
> dealii_vs env`
> mkdir -p /home/dealii/.ssh
> touch /home/dealii/.ssh/environment
> cat >/home/dealii/.ssh/environment < LANG=en_US.UTF-8
> LANGUAGE=en_US:en
> LC_ALL=en_US.UTF-8
> HOME=/home/dealii
> USER=dealii
> CC=mpicc
> CXX=mpicxx
> FC=mpif90
> FF=mpif77
> ARPACK_DIR=/home/dealii/libs/arpack-ng-master
> HDF5_DIR=/home/dealii/libs/hdf5-1.8.15-patch1
> 

[deal.II] Re: How to use intellisense to parse dealii code using visual studio remotely?

[程迪]

Hi everyone,

I just figured it out. According to 
https://github.com/Microsoft/VSLinux/issues/272 ,the intellisense works if 
CMakeSettings.json file is like this: 
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more 
information about this file.
"environments": [
{
"environment": "IS_includes", // this is used for intelliSense
// ${env.USERPROFILE} == c:\Users\
// ${env.LOCALAPPDATA} == c:\Users\\AppData\Local
"INCLUDE": 
"${env.INCLUDE};${env.USERPROFILE}\\dealII\\dealii_lib\\include;${env.LOCALAPPDATA}\\Microsoft\\Linux\\Header
 
Cache\\1.0\\919434520\\usr\\include"
}
],
"configurations": [
{
"name": "Linux-Debug",
"generator": "Unix Makefiles",
"remoteMachineName": "192.168.99.100",
"configurationType": "Debug",
"remoteCMakeListsRoot": "/var/tmp/src/${workspaceHash}/${name}",
"cmakeExecutable": "/opt/cmake/3.12.0/bin/cmake",
"buildRoot": 
"${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"installRoot": 
"${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}",
"remoteBuildRoot": 
"/var/tmp/build/${workspaceHash}/build/${name}",
"remoteInstallRoot": 
"/var/tmp/build/${workspaceHash}/install/${name}",
"remoteCopySources": true,
"remoteCopySourcesOutputVerbosity": "Normal",
"remoteCopySourcesConcurrentCopies": "10",
"remoteCopySourcesMethod": "sftp",
"remoteCopyBuildOutput": true,
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "linux_x64", "IS_includes" ]
},



On Wednesday, August 8, 2018 at 1:09:58 AM UTC-4, 程迪 wrote:
>
> Hi, everyone.
>
> I am trying to use visual studio 2017 linux dev workloads to compile and 
> debug tutorial step1 remotely on docker container. I want to use 
> intellisense of vs to help me. But I cannot figure out how.
>
> Here is my steps:
>
> 1. I followed (
> https://docs.microsoft.com/en-us/cpp/linux/download-install-and-setup-the-linux-development-workload)
>  
> to install and configured visual studio 2017 CE
>
> 2. I installed docker engine on windows using virtualbox and boot2docker. 
> And I recreated the docker machine to use more cpus.
> # stop`default` docker machine
> docker-machine stop default
> # delet`default` docker machine，and all images
> docker-machine rm default
> # create `default` docker machine
> docker-machine create -d virtualbox --virtualbox-cpu-count=4 
> --virtualbox-memory=4096 --virtualbox-disk-size=5 default
> # Restart docker
> docker-machine stop
> exit
> 3. create a docker container:
> docker run --name dealii_vs -w /home/dealii -i -t -d -v 
> /c/Users/cheng:/home/dealii/shared -p 192.168.99.100:8022:22  -p 
> 192.168.99.100:8023-8025:8023-8025 --cap-add=SYS_PTRACE dealii/dealii:latest
> # --cap-add=SYS_PTRACE is necessary for gdbserver.
> docker exec -u root -it dealii_vs bash # use root to do something inside
> 4. configure inside of the docker container
> apt-get update 
> apt-get install openssh-server gdb gdbserver zip vim-nox -y  # download 
> some software, vim-nox is not necessary.
> # newer cmake, vs2017 need cmake 3.8+
> wget https://cmake.org/files/v3.12/cmake-3.12.0-Linux-x86_64.sh
> # install to /opt/cmake/3.12.0
> mkdir -p /opt/cmake/3.12.0
> ./cmake-3.12.0-Linux-x86_64.sh --skip-license --prefix=/opt/cmake/3.12.0 
> --exclude-subdir
>
> # modify sshd to auto load some env_vars.
> # vs 2017 is using ssh to run commands remotely in `non-interactive` 
> shell, which won't load `~/.bashrc` or docker's `ENV`
> # however, opensshd has an option to load some env_vars even in 
> `non-interactive` 
> shell
> cat >>/etc/ssh/sshd_config < # add by Di Cheng
> PermitUserEnvironment yes
> EOF
> # add environment variable, almost identical to output of `docker exec 
> dealii_vs env`
> mkdir -p /home/dealii/.ssh
> touch /home/dealii/.ssh/environment
> cat >/home/dealii/.ssh/environment < LANG=en_US.UTF-8
> LANGUAGE=en_US:en
> LC_ALL=en_US.UTF-8
> HOME=/home/dealii
> USER=dealii
> CC=mpicc
> CXX=mpicxx
> FC=mpif90
> FF=mpif77
> ARPACK_DIR=/home/dealii/libs/arpack-ng-master
> HDF5_DIR=/home/dealii/libs/hdf5-1.8.15-patch1
> OPENCASCADE_DIR=/home/dealii/libs/oce-OCE-0.17
> P4EST_DIR=/home/dealii/libs/p4est-2.0
> METIS_DIR=/home/dealii/libs/parmetis-4.0.3
> PARMETIS_DIR=/home/dealii/libs/parmetis-4.0.3
> PETSC_DIR=/home/dealii/libs/petsc-3.6.4
> SLEPC_DIR=/home/dealii/libs/slepc-3.6.0
> SUPERLU_DIR=/home/dealii/libs/superlu_dist_5.1.2
> TRILINOS_DIR=/home/dealii/libs/trilinos-release-12-10-1
> DEAL_II_DIR=/home/dealii/dealii-master
>
> PATH=/opt/cmake/3.12.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> EOF
> # cat /home/dealii/.ssh/environment
>
> echo "dealii:dealii" | chpasswd # modify password
> apt-get clean 

Re: [deal.II] UMAT subroutine in dealii.

[Mahesh Prasad]

Dear Jean-Paul,

Sorry for the format of my previous post. It was incomplete and I sent it 
by mistake. 
Yes, just last week I did exactly that. Calling the Fortran subroutine from 
C++ and it works. Before moving forward I wanted to know if someone else in 
the community is already working on this.
Anyways, I will now begin working on interfacing the input/output variables.
 
Also, here's a better description of the UMAT input parameters: 
http://www.brown.edu/Departments/Engineering/Courses/En2340/Programming/ABAQUS/Usermat.for

Thank you all for your help.

Best regards,
Mahesh Prasad.
On Wednesday, August 8, 2018 at 3:57:53 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Dear Mahesh,
>
> I guess this is less of a “deal.II” question and more of a C++ question. 
> It is possible to call a Fortran function from C++ code - if you do a 
> google search for “c++ calling fortran routine” you get numerous helpful 
> links showing how it would be done in concept, e.g. 
>
> https://wiki.calculquebec.ca/w/C%2B%2B_:_appels_Fortran/en
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortranAndC.html
> http://neurophys.wisc.edu/comp/docs/not017/
>
> So since its possible to make such a call, the question is whether or not 
> you are able to provide all of the input data expected by the UMAT. It 
> would be entirely up to you to reproduce the specific FE formulation that 
> leads to this statement of the stress-strain relationship. I guess that 
> providing information for the nonlinear solver state, strain, material 
> parameters, and storage of the internal variables would be somewhat 
> trivial. Its unclear as to what exactly the inputs vs outputs to/from this 
> function are, and what parameters like “ !rotation increment matrix” 
> represent (is this because ABAQUS has elasticity formulation in terms of an 
> objective stress rate?), so I cannot comment further on what you’d 
> nominally be able to provide to the called function.
>
> I hope that this helps you further.
> Best,
> Jean-Paul
>  
>
> On 08 Aug 2018, at 15:18, Mahesh Prasad  > wrote:
>
> Dear Wolfgang,
>
> It is as you mentioned, the STRAIN is provided as an input to the UMAT. 
> UMAT then updates the STRESS and returns it as an output.
> I have attached an image of the UMAT subroutine for your reference. This 
> is a very general outline. Please don't worry about all the parameters 
> which are present in the subroutine definition. 
> The most important parameters are:
> integer ndi!number of stress components 
>   integer nshr   !number of engineering shear stress components 
>   integer ntens  !size of the stress array (ndi + nshr) 
>   integer nstatv !number state variables 
>   integer nprops !number of material constants 
>   integer layer  !layer number 
>   integer kspt   !section point number within the current layer 
>   integer kstep  !step number 
>   integer noel   !element number 
>   integer npt!integration point number 
>   integer kinc   !increment number 
>
> c---
>  
>   real(8) drpldt!jacobian drpl_dt 
>   real(8) dtime !time increment dt 
>   real(8) temp  !temperature at t0 
>   real(8) dtemp !increment of temperature. 
>   real(8) celent!characteristic element length 
>   real(8) sse   !specific elastic strain energy 
>   real(8) spd   !specific plastic dissipation 
>   real(8) scd   !specific creep dissipation 
>   real(8) rpl   !volumetric heat generation per unit time 
>   real(8) pnewdt!dt_next/dt_now 
>
> c---
>  
>   real(8) ddsdde(ntens,ntens)  !jacobian ds_de 
>   real(8) statev(nstatv)   !state variables 
>   real(8) props (nprops)   !material constants  
>   real(8) ddsddt(ntens)!jacobian ds_dt 
>   real(8) drplde(ntens)!jacobian drpl_de 
>   real(8) stress(ntens)!stress tensor 
>   real(8) stran (ntens)!strains at t0 
>   real(8) dstran(ntens)!strain increments 
>   real(8) dfgrd0(3,3)  !deformation gradient at t0 
>   real(8) dfgrd1(3,3)  !deformation gradient at t0+dt 
>   real(8) drot  (3,3)  !rotation increment matrix 
>   real(8) coords(3)!coordinates of this point 
>   real(8) time  (2)!1:step time; 2:total time, At t0 
>   real(8) predef(1)!predefined field variables at t0 
>   real(8) dpred (1)!incr of predefined field vrbs
>
>
> On Wednesday, August 8, 2018 at 6:52:56 AM UTC+2, Wolfgang Bangerth wrote:
>>
>> On 08/07/2018 03:31 AM, Mahesh Prasad wrote: 
>> > 
>> > Thank you for the suggestions. I have already looked through the 
>> > "Applications" and found that "PRISMS-Plasticity" is working on similar 
>> lines 
>> > (Crystal Plasticity FEM). 
>> > The nature of 

Re: [deal.II] implemention of periodic boundary condition

[Daniel Arndt]

Chucui,

it is clearly suspicious that you don't use any of your ConstraintMatrix 
objects in the assembly loops.
Instead of calling 

system_matrix.add(local_dof_indices[i],
 local_dof_indices[j],
 local_matrix(i, j));

you should use 

constraints.distribute_local_to_global(local_matrix, local_dof_indices, 
system_matrix)

In case that you also have inhomogeneous boundary conditions, this is in 
general not sufficient
and you should asemble the respective right hand sides in the same loop you 
construct the matrix.
Then, call

constraints.distribute_local_to_global(cell_matrix, cell_rhs, 
local_dof_indices, system_matrix, system_rhs);

The error you are getting is only slightly related to using periodic 
boundary conditions. By saying

DoFTools::make_sparsity_pattern(dof_handler, dsp, constraints, false);

you are telling the sparsity pattern (or the matrix) that you will never 
write to the constraint entries.
This assumption is true, when you use 
constraints.distribute_local_to_global, but not when you copy the matrix 
entries manually 
(without taking the constraints into account at all).

Best,
Daniel

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

[deal.II] Re: implemention of periodic boundary condition

[chucui1016]

Dear Jean-Paul,

Thank you very much for your patience, when I print some information like 
this:

template 
void Problem::run ()
{
[...]
  setup_dofs ();
std::cout << "test-1 "<< std::endl;  
VectorTools::project (dof_handler_0, constraints_phi, 
QGauss(degree+2),
SolutionsPhi(),
phi_0);  
std::cout << "test-2 " << std::endl;   
   
VectorTools::project (dof_handler_2, constraints_q, 
QGauss(degree+2),
SolutionsQ(),
q_0);  
 std::cout << "test-3 " << std::endl;   
assemble_system_1 (phi_0);
 std::cout << "test-4" << std::endl;   
assemble_rhs_1 (phi_0, q_0);
 std::cout << "test-5" << std::endl; 

and the output is

Linking CXX executable Case0-3
[ 50%] Built target Case0-3
[100%] Run with Debug configuration
   Number of active cells: 16384
   Number of degrees of freedom: 98818 (16641+16641+65536)
test-1 
test-2 
test-3 


An error occurred in line <1764> of file 
 
in function
void 
dealii::SparseMatrix::add(dealii::SparseMatrix::size_type, 
dealii::SparseMatrix::size_type, number) [with number = double; 
dealii::SparseMatrix::size_type = unsigned int]
The violated condition was: 
(index != SparsityPattern::invalid_entry) || (value == number())
Additional information: 
You are trying to access the matrix entry with index <0,1>, but this 
entry does not exist in the sparsity pattern of this matrix.


So it can't run when arrive at "assemble_system_1", so "setup-dof()", 
 "assemble_system_1()", "run()" are left—— this is LittleCase0-3.cc
if only "setup_dof()", "run()" are left——this is LittleCase0-4.cc

Hope this is a minimal example. Thank you very much!

Best,
Chucui


-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 

// Then we need to include the header file for the sparse direct solver
// UMFPACK:
#include 

// This includes the library for the incomplete LU factorization that will be
// used as a preconditioner in 3D:
#include 

// This is C++:
#include 
#include 
#include 

// As in all programs, the namespace dealii is included:
namespace Step22
{
  using namespace dealii;


  template 
  class Problem
  {
  public:
Problem (const unsigned int degree);
void run ();

  private:
void setup_dofs ();

void assemble_system_1 (const Vector phi_0);

const unsigned int   degree;

Triangulation   triangulation;
Triangulation   triangulation_active;

FESystemfe;
FE_Qfe_phi;
FE_Qfe_mu;
FE_DGQ  fe_q;
DoFHandler  dof_handler;
DoFHandler  dof_handler_0;
DoFHandler  dof_handler_1;
DoFHandler  dof_handler_2;

ConstraintMatrix constraints;
ConstraintMatrix constraints_phi;
ConstraintMatrix constraints_mu;
ConstraintMatrix constraints_q;

BlockSparsityPattern  sparsity_pattern;


BlockSparseMatrix system_matrix;
BlockSparseMatrix system_matrix_1;
BlockSparseMatrix free_energy_matrix;

Vector phi_0, q_0;

BlockVector solution;
BlockVector old_solution;
BlockVector older_solution;
BlockVector system_rhs;
BlockVector system_rhs_1;
BlockVector solution_1;

double time_step, time;
const double D, eps, lambda;//, s;
unsigned int timestep_number;

ConvergenceTable convergence_table;

  };
  

  
template 
  class SolutionsPhi : public Function
  {
  public:
SolutionsPhi () : Function() {}

virtual double value (const Point   

Re: [deal.II] implemention of periodic boundary condition

[Jean-Paul Pelteret]

Dear Chucui,

Thanks for giving this a go. This is better than before, but I think that you 
still misinterpret what a minimal working example is. This is a 1000 line piece 
of code, but I estimate only 100 lines of code are required to reproduce the 
problem. If the problem arises in the first call to setup_dofs(), which to the 
best of my understanding it does, then you really don’t need anything other than
- the set of calls used to create the Triangulation, and 
- the call to setup_dofs() itself. 

So could you please remove everything below the call to setup_dofs() in run(), 
and everything related to the assembly, solving the linear system, exact 
solution, etc. Forget about solving the original problem -- really try to make 
this compact while reproducing the error message hit when creating the sparse 
matrix. Then we will have a focussed piece of code that we can use to debug the 
issue, and if there is something to be changed in the library we will add this 
code to the test suite and would naturally give you attribution for it.

Best,
Jean-Paul

P.S. A huge plus would be to strip all of the remaining functional code out of 
the Problem class and have it all in the run() function. This would be nice, 
but is not entirely necessary.

> On 08 Aug 2018, at 15:40, chucui1...@gmail.com wrote:
> 
> Dear Daniel,
> 
> I'm sorry to make this mistake, (and thank Jean-Paul very much). The newest 
> code focus on build the sparsity pattern in "setup_dof()", while other parts 
> (assemble_system(), assemble_rhs(), run() ) need to be left to make the code 
> work and maintain the structure of 3 components of the blockvector solution.
> 
> Thank you much!
> 
> Best,
> Chucui
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> 
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.

Re: [deal.II] UMAT subroutine in dealii.

[Jean-Paul Pelteret]

Dear Mahesh,

I guess this is less of a “deal.II” question and more of a C++ question. It is 
possible to call a Fortran function from C++ code - if you do a google search 
for “c++ calling fortran routine” you get numerous helpful links showing how it 
would be done in concept, e.g. 

https://wiki.calculquebec.ca/w/C%2B%2B_:_appels_Fortran/en
http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortranAndC.html
http://neurophys.wisc.edu/comp/docs/not017/

So since its possible to make such a call, the question is whether or not you 
are able to provide all of the input data expected by the UMAT. It would be 
entirely up to you to reproduce the specific FE formulation that leads to this 
statement of the stress-strain relationship. I guess that providing information 
for the nonlinear solver state, strain, material parameters, and storage of the 
internal variables would be somewhat trivial. Its unclear as to what exactly 
the inputs vs outputs to/from this function are, and what parameters like “ 
!rotation increment matrix” represent (is this because ABAQUS has elasticity 
formulation in terms of an objective stress rate?), so I cannot comment further 
on what you’d nominally be able to provide to the called function.

I hope that this helps you further.
Best,
Jean-Paul
 
> On 08 Aug 2018, at 15:18, Mahesh Prasad  wrote:
> 
> Dear Wolfgang,
> 
> It is as you mentioned, the STRAIN is provided as an input to the UMAT. UMAT 
> then updates the STRESS and returns it as an output.
> I have attached an image of the UMAT subroutine for your reference. This is a 
> very general outline. Please don't worry about all the parameters which are 
> present in the subroutine definition. 
> The most important parameters are:
> integer ndi!number of stress components 
>   integer nshr   !number of engineering shear stress components 
>   integer ntens  !size of the stress array (ndi + nshr) 
>   integer nstatv !number state variables 
>   integer nprops !number of material constants 
>   integer layer  !layer number 
>   integer kspt   !section point number within the current layer 
>   integer kstep  !step number 
>   integer noel   !element number 
>   integer npt!integration point number 
>   integer kinc   !increment number 
> c--- 
>   real(8) drpldt!jacobian drpl_dt 
>   real(8) dtime !time increment dt 
>   real(8) temp  !temperature at t0 
>   real(8) dtemp !increment of temperature. 
>   real(8) celent!characteristic element length 
>   real(8) sse   !specific elastic strain energy 
>   real(8) spd   !specific plastic dissipation 
>   real(8) scd   !specific creep dissipation 
>   real(8) rpl   !volumetric heat generation per unit time 
>   real(8) pnewdt!dt_next/dt_now 
> c--- 
>   real(8) ddsdde(ntens,ntens)  !jacobian ds_de 
>   real(8) statev(nstatv)   !state variables 
>   real(8) props (nprops)   !material constants  
>   real(8) ddsddt(ntens)!jacobian ds_dt 
>   real(8) drplde(ntens)!jacobian drpl_de 
>   real(8) stress(ntens)!stress tensor 
>   real(8) stran (ntens)!strains at t0 
>   real(8) dstran(ntens)!strain increments 
>   real(8) dfgrd0(3,3)  !deformation gradient at t0 
>   real(8) dfgrd1(3,3)  !deformation gradient at t0+dt 
>   real(8) drot  (3,3)  !rotation increment matrix 
>   real(8) coords(3)!coordinates of this point 
>   real(8) time  (2)!1:step time; 2:total time, At t0 
>   real(8) predef(1)!predefined field variables at t0 
>   real(8) dpred (1)!incr of predefined field vrbs
> 
> 
> On Wednesday, August 8, 2018 at 6:52:56 AM UTC+2, Wolfgang Bangerth wrote:
> On 08/07/2018 03:31 AM, Mahesh Prasad wrote: 
> > 
> > Thank you for the suggestions. I have already looked through the 
> > "Applications" and found that "PRISMS-Plasticity" is working on similar 
> > lines 
> > (Crystal Plasticity FEM). 
> > The nature of the problem is : Multi-scale simulations using Crystal 
> > Plasticity FEM. 
> > 
> > Over the years we have developed the UMAT subroutine that describes our 
> > material models. So, instead of implementing them from scratch in dealii we 
> > would like to have an interface that communicates between the UMAT and 
> > dealii.  So, my question is: Has anyone tried to link the UMAT subroutines 
> > with dealii ? i.e., The UMAT (fortran 90) has to be called at each 
> > integration 
> > point. If not, How do I go about linking the fortran code with dealii ? 
> 
> Mahesh, 
> since few of us will be familiar with how exactly ABAQUS interfaces with 
> externally written routines, can you explain what these UMAT functions take 
> as 
> 

[deal.II] Re: implemention of periodic boundary condition

[chucui1016]

Dear Daniel,

I'm sorry to make this mistake, (and thank Jean-Paul very much). The newest 
code focus on build the sparsity pattern in "setup_dof()", while other 
parts (assemble_system(), assemble_rhs(), run() ) need to be left to make 
the code work and maintain the structure of 3 components of the blockvector 
solution.

Thank you much!

Best,
Chucui

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 

// Then we need to include the header file for the sparse direct solver
// UMFPACK:
#include 

// This includes the library for the incomplete LU factorization that will be
// used as a preconditioner in 3D:
#include 

// This is C++:
#include 
#include 
#include 

// As in all programs, the namespace dealii is included:
namespace Step22
{
  using namespace dealii;


  template 
  class Problem
  {
  public:
Problem (const unsigned int degree);
void run ();

  private:
void setup_dofs ();
void assemble_system (const BlockVector old_solution,
  const BlockVector older_solution);
void assemble_rhs (const double time,
   const BlockVector old_solution,
   const BlockVector older_solution);
void solve ();

double free_energy_compute (const BlockVector solution);

void assemble_system_1 (const Vector phi_0);
void assemble_rhs_1 (const Vector phi_0, const Vector q_0);
void solve_1 ();

const unsigned int   degree;

Triangulation   triangulation;
Triangulation   triangulation_active;

FESystemfe;
FE_Qfe_phi;
FE_Qfe_mu;
FE_DGQ  fe_q;
DoFHandler  dof_handler;
DoFHandler  dof_handler_0;
DoFHandler  dof_handler_1;
DoFHandler  dof_handler_2;

ConstraintMatrix constraints;
ConstraintMatrix constraints_phi;
ConstraintMatrix constraints_mu;
ConstraintMatrix constraints_q;

BlockSparsityPattern  sparsity_pattern;


BlockSparseMatrix system_matrix;
BlockSparseMatrix system_matrix_1;
BlockSparseMatrix free_energy_matrix;

Vector phi_0, q_0;

BlockVector solution;
BlockVector old_solution;
BlockVector older_solution;
BlockVector system_rhs;
BlockVector system_rhs_1;
BlockVector solution_1;

double time_step, time;
const double D, eps, lambda;//, s;
unsigned int timestep_number;

ConvergenceTable convergence_table;

  };
  

  
template 
  class SolutionsPhi : public Function
  {
  public:
SolutionsPhi () : Function() {}

virtual double value (const Point   ,
  const unsigned int  component = 0) const;
virtual Tensor<1,dim> gradient (const Point   ,
const unsigned int  component = 0) const;
  };
  
  
  template 
  double SolutionsPhi::value (const Point   ,
   const unsigned int component) const
  {
 //if (component == 0)
 double phi_value = 0;

  Tensor<1,dim> r;

  r[0] = std::sqrt((p[0] - 0.3 + 0.01) * (p[0] - 0.3 + 0.01) + (p[1] - 0.5) * (p[1] - 0.5)) ;
  r[1] = std::sqrt((p[0] - 0.7 - 0.01) * (p[0] - 0.7 - 0.01) + (p[1] - 0.5) * (p[1] - 0.5)) ;
  
  if ((r[0] >= (0.2 + 0.01)) && (r[1] >= (0.2 + 0.01)))
   {phi_value = -1;
   }
  else if (r[0] < (0.2 + 0.01))
{phi_value = std::tanh((0.2-std::sqrt((p[0]-0.3+0.01) * (p[0]-0.3+0.01) + (p[1] -0.5) * (p[1] -0.5)))/0.01);
}
   else if (r[1] < (0.2 + 0.01))
 {phi_value = std::tanh((0.2-std::sqrt((p[0]-0.7-0.01) * (p[0]-0.7-0.01) + (p[1] -0.5) * (p[1] -0.5)))/0.01);
 } 
else
 

Re: [deal.II] UMAT subroutine in dealii.

[Mahesh Prasad]

Dear Wolfgang,

It is as you mentioned, the STRAIN is provided as an input to the UMAT. 
UMAT then updates the STRESS and returns it as an output.
I have attached an image of the UMAT subroutine for your reference. This is 
a very general outline. Please don't worry about all the parameters which 
are present in the subroutine definition. 
The most important parameters are:
integer ndi!number of stress components 
  integer nshr   !number of engineering shear stress components 
  integer ntens  !size of the stress array (ndi + nshr) 
  integer nstatv !number state variables 
  integer nprops !number of material constants 
  integer layer  !layer number 
  integer kspt   !section point number within the current layer 
  integer kstep  !step number 
  integer noel   !element number 
  integer npt!integration point number 
  integer kinc   !increment number 
c--- 

  real(8) drpldt!jacobian drpl_dt 
  real(8) dtime !time increment dt 
  real(8) temp  !temperature at t0 
  real(8) dtemp !increment of temperature. 
  real(8) celent!characteristic element length 
  real(8) sse   !specific elastic strain energy 
  real(8) spd   !specific plastic dissipation 
  real(8) scd   !specific creep dissipation 
  real(8) rpl   !volumetric heat generation per unit time 
  real(8) pnewdt!dt_next/dt_now 
c--- 

  real(8) ddsdde(ntens,ntens)  !jacobian ds_de 
  real(8) statev(nstatv)   !state variables 
  real(8) props (nprops)   !material constants  
  real(8) ddsddt(ntens)!jacobian ds_dt 
  real(8) drplde(ntens)!jacobian drpl_de 
  real(8) stress(ntens)!stress tensor 
  real(8) stran (ntens)!strains at t0 
  real(8) dstran(ntens)!strain increments 
  real(8) dfgrd0(3,3)  !deformation gradient at t0 
  real(8) dfgrd1(3,3)  !deformation gradient at t0+dt 
  real(8) drot  (3,3)  !rotation increment matrix 
  real(8) coords(3)!coordinates of this point 
  real(8) time  (2)!1:step time; 2:total time, At t0 
  real(8) predef(1)!predefined field variables at t0 
  real(8) dpred (1)!incr of predefined field vrbs


On Wednesday, August 8, 2018 at 6:52:56 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 08/07/2018 03:31 AM, Mahesh Prasad wrote: 
> > 
> > Thank you for the suggestions. I have already looked through the 
> > "Applications" and found that "PRISMS-Plasticity" is working on similar 
> lines 
> > (Crystal Plasticity FEM). 
> > The nature of the problem is : Multi-scale simulations using Crystal 
> > Plasticity FEM. 
> > 
> > Over the years we have developed the UMAT subroutine that describes our 
> > material models. So, instead of implementing them from scratch in dealii 
> we 
> > would like to have an interface that communicates between the UMAT and 
> > dealii.  So, my question is: Has anyone tried to link the UMAT 
> subroutines 
> > with dealii ? i.e., The UMAT (fortran 90) has to be called at each 
> integration 
> > point. If not, How do I go about linking the fortran code with dealii ? 
>
> Mahesh, 
> since few of us will be familiar with how exactly ABAQUS interfaces with 
> externally written routines, can you explain what these UMAT functions 
> take as 
> input, and which information they return? 
>
> I suspect that they probably receive the strain as input and return the 
> stress 
> as output, but it would be good to know for sure. It may also be that it's 
> the 
> derivative tensor, of course, which may actually be more useful in 
> practice. 
>
> Best 
>   WB 
>
> -- 
>  
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] implemention of periodic boundary condition

[Jean-Paul Pelteret]

Dear Chucui,

I think that what Daniel was asking for was the absolute minimum size test case 
that reproduces the error in building the sparsity pattern. I interpreted (and 
he’s welcome to correct me) that wants to help you find out why you hit this 
error:

An error occurred in line <1764> of file 
 in 
function
void 
dealii::SparseMatrix::add(dealii::SparseMatrix::size_type, 
dealii::SparseMatrix::size_type, number) [with number = double; 
dealii::SparseMatrix::size_type = unsigned int]
The violated condition was: 
(index != SparsityPattern::invalid_entry) || (value == number())
Additional information: 
You are trying to access the matrix entry with index <0,1>, but this entry 
does not exist in the sparsity pattern of this matrix.

So you can remove a lot of the code that would only be used after the sparsity 
pattern was successfully built. That would be a great help and would accelerate 
the process of getting an answer to your question.

Best,
Jean-Paul

> On 08 Aug 2018, at 15:05, chucui1...@gmail.com wrote:
> 
> Chucui

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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: implemention of periodic boundary condition

[chucui1016]

Dear Daniel,

Thank you very much! The LittleCase0-3.cc is my work case with the same 
problem as I say.

Simply describe what this code work for: to solve



from



where the three variables have periodic boundary conditions on the domain 
[0,1]*[0,1]. So the weak form has no part of boundary integral.

Thank you very much!

Best,
Chucui

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 

// Then we need to include the header file for the sparse direct solver
// UMFPACK:
#include 

// This includes the library for the incomplete LU factorization that will be
// used as a preconditioner in 3D:
#include 

// This is C++:
#include 
#include 
#include 

// As in all programs, the namespace dealii is included:
namespace Step22
{
  using namespace dealii;


  template 
  class Problem
  {
  public:
Problem (const unsigned int degree);
void run ();

  private:
void setup_dofs ();
void assemble_system (const BlockVector old_solution,
  const BlockVector older_solution);
void assemble_rhs (const double time,
   const BlockVector old_solution,
   const BlockVector older_solution);
void solve ();
void output_results_in_routine (const unsigned int timestep_number)  const;
void output_results (const unsigned int refinement_cycle) const;
void output_results_phi ()  const;
void output_results_q ()  const;
void output_results_initial ()  const;

void refine_mesh ();
void process_solution(const double time);
double free_energy_compute (const BlockVector solution);

void assemble_system_1 (const Vector phi_0);
void assemble_rhs_1 (const Vector phi_0, const Vector q_0);
void solve_1 ();

const unsigned int   degree;

Triangulation   triangulation;
Triangulation   triangulation_active;

FESystemfe;
FE_Qfe_phi;
FE_Qfe_mu;
FE_DGQ  fe_q;
DoFHandler  dof_handler;
DoFHandler  dof_handler_0;
DoFHandler  dof_handler_1;
DoFHandler  dof_handler_2;

ConstraintMatrix constraints;
ConstraintMatrix constraints_phi;
ConstraintMatrix constraints_mu;
ConstraintMatrix constraints_q;

BlockSparsityPattern  sparsity_pattern;
//BlockSparsityPattern  sparsity_pattern_mu;

BlockSparseMatrix system_matrix;
BlockSparseMatrix system_matrix_1;
BlockSparseMatrix free_energy_matrix;

//SparseMatrix system_matrix_mu_0;
Vector phi_0, q_0;

BlockVector solution;
BlockVector old_solution;
BlockVector older_solution;
BlockVector system_rhs;
BlockVector system_rhs_1;
BlockVector solution_1;

double time_step, time;
const double D, eps, lambda;//, s;
unsigned int timestep_number;

ConvergenceTable convergence_table;

  };
  

  
template 
  class SolutionsPhi : public Function
  {
  public:
SolutionsPhi () : Function() {}

virtual double value (const Point   ,
  const unsigned int  component = 0) const;
virtual Tensor<1,dim> gradient (const Point   ,
const unsigned int  component = 0) const;
  };
  
  
  template 
  double SolutionsPhi::value (const Point   ,
   const unsigned int component) const
  {
 //if (component == 0)
 double phi_value = 0;
// phi_value = 

[deal.II] Re: implemention of periodic boundary condition

[Daniel Arndt]

Chucui,

In first sight this looks reasonable. In particular, it is important to 
consider the constraints when building the sparsity pattern.
Can you build a minimal working example that shows the problem?

Best,
Daniel

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

[deal.II] Re: implemention of periodic boundary condition

[chucui1016]

Dear Daniel,

Thank you very much for your rapid reply! I use overload 

 as 
you say, and it can run before assemble_system, the relevant part of my 
code is
  template 
  void Problem::run ()
  {
   
const unsigned int n_cycles = 1;
double entropy = 0;

for (unsigned int cycle=0; cycle::active_cell_iterator
cell = triangulation.begin_active();
cell != triangulation.end();
++cell)
{
for (unsigned int f=0; f::faces_per_cell; 
++f)
{
   if (cell->face(f)->at_boundary())
   {  
  if (std::fabs(cell->face(f)->center()(0) - 
(2.25)) < 1e-12)
  
  cell->face(f)->set_boundary_id (1);
  else if(std::fabs(cell->face(f)->center()(1) - 
(0)) < 1e-12)
   
   cell->face(f)->set_boundary_id (2);
   else if(std::fabs(cell->face(f)->center()(1) 
- (2.25)) < 1e-12)
 
 cell->face(f)->set_boundary_id (3);
 else 
if(std::fabs(cell->face(f)->center()(0) - (0)) < 1e-12)
  {
  cell->face(f)->set_boundary_id 
(0);
  }  
   } 
   }
}
 
 }
else
{
//triangulation.refine_global (1);
}
   setup_dofs ();
   std::cout << "start" << cycle << std::endl;  

   
VectorTools::project (dof_handler_phi, constraints, 
QGauss(degree+2),
InitialValues_phi(),
phi_0);   
VectorTools::project (dof_handler_e, constraints, 
QGauss(degree+2),
InitialValues_e(),
e_0);  
std::cout << "phi_0" << cycle << std::endl;
//VectorTools::project (dof_handler_U, constraints_U, 
QGauss(degree+2),
//InitialValues_U(),
//U_n);
//std::cout << "U_0" << cycle << std::endl;  
VectorTools::project (dof_handler_q, constraints_q, 
QGauss(degree+2),
InitialValues_q(),
q_0);  
std::cout << "q_0" << cycle << std::endl; 
assemble_system_1 (phi_0, e_0);
[...]
and my setup_dofs ():
  template 
  void Problem::setup_dofs ()
  {
std::vector block_component (4);
block_component[0] = 0;
block_component[1] = 1; 
block_component[2] = 2;
block_component[3] = 3;

dof_handler.distribute_dofs (fe);
//DoFRenumbering::component_wise (dof_handler);
DoFRenumbering::component_wise (dof_handler, block_component);
constraints.clear ();
const ComponentMask component_mask = ComponentMask();
DoFTools::make_periodicity_constraints(dof_handler,0,1,0, constraints, 
component_mask);
DoFTools::make_periodicity_constraints(dof_handler,2,3,1, constraints, 
component_mask);

constraints.close (); 

std::vector dofs_per_block (4); 
DoFTools::count_dofs_per_block (dof_handler, dofs_per_block, 
block_component);

const unsigned int n_phi = dofs_per_block[0],
   n_e = dofs_per_block[1],
   n_U = dofs_per_block[2],
   n_q = dofs_per_block[3];
system_matrix_1.clear ();
   
BlockDynamicSparsityPattern dsp (4,4);
dsp.block(0,0).reinit (n_phi, n_phi);
dsp.block(1,0).reinit (n_e, n_phi);  
dsp.block(2,0).reinit (n_U, n_phi);
dsp.block(3,0).reinit (n_q, n_phi); 
 
dsp.block(0,1).reinit (n_phi, n_e);
dsp.block(1,1).reinit (n_e, n_e);
dsp.block(2,1).reinit (n_U, n_e);
dsp.block(3,1).reinit (n_q, n_e); 

dsp.block(0,2).reinit (n_phi, n_U);
dsp.block(1,2).reinit (n_e, n_U);  
dsp.block(2,2).reinit (n_U, n_U);
dsp.block(3,2).reinit (n_q, n_U); 
 
dsp.block(0,3).reinit (n_phi, n_q);
dsp.block(1,3).reinit (n_e, n_q);
dsp.block(2,3).reinit (n_U, n_q);
dsp.block(3,3).reinit (n_q, n_q); 

dsp.collect_sizes();

DoFTools::make_sparsity_pattern (dof_handler, dsp, constraints, false);
sparsity_pattern.copy_from (dsp);

system_matrix_1.reinit (sparsity_pattern);
[...]
the output and error is
start0
phi_00
q_00


An error occurred in line <1764> of file 
 in 
function
void 
dealii::SparseMatrix::add(dealii::SparseMatrix::size_type, 
dealii::SparseMatrix::size_type, number) 

[deal.II] Re: implemention of periodic boundary condition

[chucui1016]

Dear Daniel,

Thank you very much for your rapid reply! I use overload 

 as 
you say, and it can run before assemble_system, the relevant part of my 
code is
  template 
  void Problem::run ()
  {
   
const unsigned int n_cycles = 1;
double entropy = 0;

for (unsigned int cycle=0; cycle::active_cell_iterator
cell = triangulation.begin_active();
cell != triangulation.end();
++cell)
{
for (unsigned int f=0; f::faces_per_cell; 
++f)
{
   if (cell->face(f)->at_boundary())
   {  
  if (std::fabs(cell->face(f)->center()(0) - 
(2.25)) < 1e-12)
  
  cell->face(f)->set_boundary_id (1);
  else if(std::fabs(cell->face(f)->center()(1) - 
(0)) < 1e-12)
   
   cell->face(f)->set_boundary_id (2);
   else if(std::fabs(cell->face(f)->center()(1) 
- (2.25)) < 1e-12)
 
 cell->face(f)->set_boundary_id (3);
 else 
if(std::fabs(cell->face(f)->center()(0) - (0)) < 1e-12)
  {
  cell->face(f)->set_boundary_id 
(0);
  }  
   } 
   }
}
 
 }
else
{
//triangulation.refine_global (1);
}
   setup_dofs ();
   std::cout << "start" << cycle << std::endl;  

   
VectorTools::project (dof_handler_phi, constraints, 
QGauss(degree+2),
InitialValues_phi(),
phi_0);   
VectorTools::project (dof_handler_e, constraints, 
QGauss(degree+2),
InitialValues_e(),
e_0);  
std::cout << "phi_0" << cycle << std::endl;
//VectorTools::project (dof_handler_U, constraints_U, 
QGauss(degree+2),
//InitialValues_U(),
//U_n);
//std::cout << "U_0" << cycle << std::endl;  
VectorTools::project (dof_handler_q, constraints_q, 
QGauss(degree+2),
InitialValues_q(),
q_0);  
std::cout << "q_0" << cycle << std::endl; 
assemble_system_1 (phi_0, e_0);
[...]
and my setup_dofs ():
  template 
  void StokesProblem::setup_dofs ()
  {
std::vector block_component (4);
block_component[0] = 0;
block_component[1] = 1; 
block_component[2] = 2;
block_component[3] = 3;

dof_handler.distribute_dofs (fe);
//DoFRenumbering::component_wise (dof_handler);
DoFRenumbering::component_wise (dof_handler, block_component);
constraints.clear ();
const ComponentMask component_mask = ComponentMask();
DoFTools::make_periodicity_constraints(dof_handler,0,1,0, constraints, 
component_mask);
DoFTools::make_periodicity_constraints(dof_handler,2,3,1, constraints, 
component_mask);

constraints.close (); 

std::vector dofs_per_block (4); 
DoFTools::count_dofs_per_block (dof_handler, dofs_per_block, 
block_component);

const unsigned int n_phi = dofs_per_block[0],
   n_e = dofs_per_block[1],
   n_U = dofs_per_block[2],
   n_q = dofs_per_block[3];
system_matrix_1.clear ();
   
BlockDynamicSparsityPattern dsp (4,4);
dsp.block(0,0).reinit (n_phi, n_phi);
dsp.block(1,0).reinit (n_e, n_phi);  
dsp.block(2,0).reinit (n_U, n_phi);
dsp.block(3,0).reinit (n_q, n_phi); 
 
dsp.block(0,1).reinit (n_phi, n_e);
dsp.block(1,1).reinit (n_e, n_e);
dsp.block(2,1).reinit (n_U, n_e);
dsp.block(3,1).reinit (n_q, n_e); 

dsp.block(0,2).reinit (n_phi, n_U);
dsp.block(1,2).reinit (n_e, n_U);  
dsp.block(2,2).reinit (n_U, n_U);
dsp.block(3,2).reinit (n_q, n_U); 
 
dsp.block(0,3).reinit (n_phi, n_q);
dsp.block(1,3).reinit (n_e, n_q);
dsp.block(2,3).reinit (n_U, n_q);
dsp.block(3,3).reinit (n_q, n_q); 

dsp.collect_sizes();

DoFTools::make_sparsity_pattern (dof_handler, dsp, constraints, false);
sparsity_pattern.copy_from (dsp);

system_matrix_1.reinit (sparsity_pattern);
[...]
the output and error is
start0
phi_00
q_00


An error occurred in line <1764> of file 
 in 
function
void 
dealii::SparseMatrix::add(dealii::SparseMatrix::size_type, 
dealii::SparseMatrix::size_type, 

[deal.II] Re: implemention of periodic boundary condition

[Daniel Arndt]

Chucui,

1. How to use function "DoFTools::make_periodicity_constraints() "  only? 
> if my code need not to compute parallel case.  If I choose [...] how to 
> choose face1 and face2 we need there correctly? If I use [...] maybe I 
> still need to use "GridTools::collect_periodic_faces" to input information 
> of faces into PeriodicFacePair. If I do this,  I am not use 
> "DoFTools::make_periodicity_constraints() "  only
>
In your case, it should be sufficient to use the overload 

 
that just takes boundary ids. Alternatively, you can use 
GridTools::collect_periodic_faces and pass the return value to the 
respective overload 

 
of GridTools::make_periodicity_constraints.

 

> 2. In step-45, the complete implemention is parallel case. For every step, 
> it use functions used in parallel case. If I want to implement a case not 
> in parallel, shall I rewrite all of them and remove the parallel parts 
> (still not succeed), or use it directly, but in shell run my program via
> mpirun -np 1 ./myCase
>
>  
As explained in the introduction of step-45 there are only very few extra 
steps you need to do when you are dealing with a 
parallel::distributed::Triangulation object.
In the end, it is sufficient to call 
GridTools::make_periodicity_constraints (in case you are using continuous 
ansatz spaces). 
Note that you have to take care yourself that there is at most a one level 
difference between periodic faces.

Best,
Daniel

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

[deal.II] Re: implemention of periodic boundary condition

[chucui1016]

Dear Jean-Paul,

Thank you very much! I had read step-45, but still have some questions:
1. How to use function "DoFTools::make_periodicity_constraints() "  only? 
if my code need not to compute parallel case.  If I choose
void DoFTools::make_periodicity_constraints ( const FaceIterator & face_1,
const typename identity 
< 
FaceIterator >::type & face_2,
AffineConstraints 
< 
double > & constraints,
const ComponentMask 
 & 
component_mask 
= ComponentMask 
(),
const bool face_orientation = true,
const bool face_flip = false,
const bool face_rotation = false,
const FullMatrix 
< double 
> & matrix = FullMatrix 

(),
const std::vector< unsigned int > & first_vector_components = std::vector<
unsigned int>() 
)
how to choose face1 and face2 we need there correctly? If I use 
template
void DoFTools::make_periodicity_constraints ( const std::vector< GridTools::
PeriodicFacePair 

< typename DoFHandlerType::cell_iterator >> & periodic_faces,
AffineConstraints 
< 
double > & constraints,
const ComponentMask 
 & 
component_mask 
= ComponentMask 
(),
const std::vector< unsigned int > & first_vector_components = std::vector<
unsigned int>() 
)
how to make a 
const std::vector< GridTools::PeriodicFacePair 

< typename DoFHandlerType::cell_iterator >> & periodic_faces
maybe I still need to use "GridTools::collect_periodic_faces" to input 
information of faces into PeriodicFacePair. If I do this,  I am not use 
"DoFTools::make_periodicity_constraints() "  only


2. In step-45, the complete implemention is parallel case. For every step, 
it use functions used in parallel case. If I want to implement a case not 
in parallel, shall I rewrite all of them and remove the parallel parts 
(still not succeed), or use it directly, but in shell run my program via
mpirun -np 1 ./myCase


Thank you very much!

Best,
Chucui

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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

[Jean-Paul Pelteret]

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() 

 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() 

 function so you could create a lookup between a point in problem 1 and a cell 
in problem 2 again using GridTools::Cache 
 
(although I’m guessing that this is what it does internally).

I hope that this gives you some ideas to play with!

Best,
J-P

> On 07 Aug 2018, at 17:47, Alberto Salvadori  
> wrote:
> 
> 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 
>   {
> 
> 
> // values: mechanical
> 
> Tensor<1,dim> 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 
> .

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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.