[deal.II] new deal.II mac os package - works also on Big Sur

2020-11-14 Thread luca.heltai
Dear all, 

a few days ago, I uploaded a new deal.II package to 

https://github.com/dealii/dealii/releases/tag/v9.2.0

named 

dealii-9.2.0-v3.dmg

I have received confirmation today that the new package works also on Big Sur 
(Mac OS 11).

Best,
Luca.

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


Re: [deal.II] Support for GMSH version 4

2020-11-02 Thread luca.heltai
Dear Chen,

version 4 (and above) are already supported. Only the first tag is supported, 
though, and it is interpreted as material id or boundary id, according to the 
dimension of the object it is attached to.

Best,
Luca.

> On 2 Nov 2020, at 11:02, Chen R  wrote:
> 
> Hi all
> 
> New to deal.II and didn't seem to find an answer to this  anywhere.
> 
> As I understand it the support for GMSH files is for versions 1 and 2.
> 
> Are there any plans for supporting version 4 at all?
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/84bb8586-8f45-4189-be5e-5187ca298a37n%40googlegroups.com.

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


Re: [deal.II] Trouble in turning -DDEAL_II_WITH_PETSC on

2020-10-06 Thread luca.heltai
I think the problem is in your MPI installation. deal.II does not find your MPI 
(i.e., it does not find MPI, even if you specifiy -DEAL_II_WITH_MPI=ON).

You could set your cxx compiler to the mpi compiler that was used to build 
PETSc. This should be sufficient to make sure deal.II picks up mpi, and PETSc.

Best,
Luca.

> On 6 Oct 2020, at 10:36, einseg...@gmail.com  wrote:
> 
> Dear developers of Deal ii,
>   I tried to run example-70(FSI example), but I found I have no PETSc 
> linked to DEAL ii. I failed since example-17. I have installed PETSc 3.13.2.0 
> following the instruction of https://ibamr.github.io/linux (IBAMR is an 
> immersed boundary method which also need PETSc, I also read the instruction 
> page of https://www.dealii.org/developer/external-libs/petsc.html which has 
> similar instructions(except the MPI ch part). And I successfully make test of 
> PETSc. But when I typed:
> (base) afan-XPS-8700:~/myProject/dealii/dealii-9.2.0$ cmake 
> -DDEAL_II_WITH_PETSC=ON -DEAL_II_WITH_MPI=ON .
> It always returns the error as follows:
> 
> ```
> PETSC_VERSION: 3.13.2.0
> --   PETSC_LIBRARIES: 
> /home/afan/sfw/petsc/3.13.2/linux-opt/lib/libpetsc.so;/home/afan/sfw/petsc/3.13.2/linux-opt/lib/libHYPRE.so;/usr/lib/x86_64-linux-gnu/liblapack.so;/usr/lib/x86_64-linux-gnu/libblas.so;m;dl;/home/afan/sfw/linux/openmpi/4.0.2/lib/libmpi_usempif08.so;/home/afan/sfw/linux/openmpi/4.0.2/lib/libmpi_usempi_ignore_tkr.so;/home/afan/sfw/linux/openmpi/4.0.2/lib/libmpi_mpifh.so;/home/afan/sfw/linux/openmpi/4.0.2/lib/libmpi.so;gfortran;m;gfortran;m;quadmath;pthread;quadmath;dl
> --   PETSC_INCLUDE_DIRS: 
> /home/afan/sfw/petsc/3.13.2/include;/home/afan/sfw/petsc/3.13.2/linux-opt/include;/home/afan/sfw/petsc/3.13.2/include;/home/afan/sfw/petsc/3.13.2/linux-opt/include
> --   PETSC_USER_INCLUDE_DIRS: 
> /home/afan/sfw/petsc/3.13.2/include;/home/afan/sfw/petsc/3.13.2/linux-opt/include;/home/afan/sfw/petsc/3.13.2/include;/home/afan/sfw/petsc/3.13.2/linux-opt/include
> -- Found PETSC
> -- Could not find a sufficient PETSc installation: PETSc has to be configured 
> with the same MPI configuration as deal.II.
> -- DEAL_II_WITH_PETSC has unmet external dependencies.
> CMake Error at cmake/configure/configure_3_petsc.cmake:141 (MESSAGE):
>   
> 
>   Could not find the petsc library!
> 
>   Could not find a sufficient PETSc installation:
> 
>   PETSc has to be configured with the same MPI configuration as deal.II, but
>   found:
> 
> DEAL_II_WITH_MPI = OFF
> PETSC_WITH_MPI   = (NOT FALSE)
> 
>   
> 
>   Please ensure that the petsc library version 3.3.0 or newer is installed on
>   your computer and is configured with the same mpi options as deal.II
> 
>   If the library is not at a default location, either provide some hints
> 
>   for the autodetection:
> 
>   PETSc installed with --prefix=<...> to a destination:
> 
>   $ PETSC_DIR="..." cmake <...>
>   $ cmake -DPETSC_DIR="..." <...>
> 
>   PETSc compiled in source tree:
> 
>   $ PETSC_DIR="..."  PETSC_ARCH="..." cmake <...>
>   $ cmake -DPETSC_DIR="..." -DPETSC_ARCH="..." <...>
> 
>   or set the relevant variables by hand in ccmake.
> 
>   
> 
> Call Stack (most recent call first):
>   CMakeFiles/CMakeTmp/evaluate_expression.tmp:1 (FEATURE_PETSC_ERROR_MESSAGE)
>   cmake/macros/macro_evaluate_expression.cmake:30 (INCLUDE)
>   cmake/macros/macro_configure_feature.cmake:267 (EVALUATE_EXPRESSION)
>   cmake/configure/configure_3_petsc.cmake:160 (CONFIGURE_FEATURE)
>   cmake/macros/macro_verbose_include.cmake:19 (INCLUDE)
>   CMakeLists.txt:124 (VERBOSE_INCLUDE)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "/home/afan/myProject/dealii/dealii-9.2.0/CMakeFiles/CMakeOutput.log".
> See also "/home/afan/myProject/dealii/dealii-9.2.0/CMakeFiles/CMakeError.log".
> ```
> 
> I would like to ask: do I need to install a new version of PETSc or how can I 
> link PETSc with DEAL_II?
> Best wishes!
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/9e3f2feb-bc47-4b8f-8e94-c3b75c8ef366n%40googlegroups.com.

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


Re: [deal.II] install problems with clang@12.0.0 and Xcode12.0 from spack

2020-09-28 Thread luca.heltai
My suggestion is to install also environment-modules, and then use

spack load dealii

This will popolate DYLD_LIBRARY_PATH with the correct values and allows your 
cmake to find all libraries.

Unfortunately, recent updates to spack have made its functionality a bit clumsy 
in Mac OS...

L.

> On 28 Sep 2020, at 13:40, 'Alexander Greiner' via deal.II User Group 
>  wrote:
> 
> Hi, thanks for your suggestions.
> 
> Yes, Trilinos is installed by spack and 
> ls `spack location -i trilinos`/lib/libmuelu*
> shows me the correct paths to the libmuelu libraries. 
> I also enabled Full Disk Access for Terminal.app and restarted the App as 
> described. 
> Still, the libraries are not linked properly.
> 
> Best 
> Alex
> 
> Praveen C schrieb am Montag, 28. September 2020 um 13:08:14 UTC+2:
> No, you dont have to recompile deal.II for what I am suggesting.
> 
> I suppose that lib is installed by spack, have you checked
> 
> ls `spack location -i trilinos`/lib/libmuelu*
> 
> Not sure if this will help, but 
> 
> Have you enabled Full Disk Access for Terminal.app
> 
> If not, can you enable it and try. See this
> 
> https://macperformanceguide.com/blog/2020/20200208_2004macOS-Catalina-add-fullDiskAccess-Terminal.html
> 
> best
> praveen
> 
> 
>> On 28-Sep-2020, at 3:53 PM, 'Alexander Greiner' via deal.II User Group 
>>  wrote:
>> 
>> Hi Praveen, 
>> 
>> "Stupid" question beforehand: Do I have to reinstall deal.II? If yes, you 
>> can skip the remainder. If no, I did the following:
>> 
>> I added that line to my ./bash_profile opened a new terminal window and 
>> executed
>> source ./bash_profile
>> spack load dealii
>> cd spack/opt/.../deal.II/examples/step-1
>> cmake .   (I removed all previously generated "make"-files to obtain the 
>> initial directory content of step-1)
>> make run
>> Unfortunately, libmuelu is still not found. I attached a printout of my 
>> environment variables, if this might help...
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/97294b8d-4815-4f96-a346-8d8d6037ff35n%40googlegroups.com.

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


Re: [deal.II] step-1 Error

2020-09-24 Thread luca.heltai
In the documentation of the 9.0.0 package, this is what is installed via spack:

==> 60 installed packages.
-- darwin-highsierra-x86_64 / clang@6.0.0 ---
adol-c@develop  gmp@6.1.2matio@1.5.9 
ninja@1.8.2 readline@7.0
arpack-ng@3.6.3 gmsh@4.0.0   metis@5.1.0 
numdiff@5.9.0   slepc@3.9.2
assimp@4.0.1gsl@2.3  mpc@1.1.0   oce@0.18.3 
 sqlite@3.23.1
autoconf@2.69   hdf5@1.10.3  mpfr@4.0.1  
openblas@0.3.3  suite-sparse@5.3.0
automake@1.16.1 hwloc@1.11.9 mumps@5.1.1 
openmpi@3.1.2   sundials@3.2.0
boost@1.68.0hypre@2.14.0 muparser@2.2.5  
openssl@1.0.2o  superlu-dist@5.2.2
bzip2@1.0.6 intel-tbb@2019   nanoflann@1.2.3 p4est@2.0  
 superlu-mt@3.1
cmake@3.12.2isl@0.19 ncurses@6.1 
parmetis@4.0.3  tcl@8.6.8
environment-modules@3.2.10  libsigsegv@2.11  netcdf@4.6.1
perl@5.26.2 tetgen@1.5.0
gcc@8.2.0   libtool@2.4.6netcdf-cxx@4.2  
petsc@3.9.2 trilinos@12.12.1
gdbm@1.14.1 libxml2@2.9.8netgen@5.3.1
pkgconf@1.4.2   xz@5.2.4
glm@0.9.7.1 m4@1.4.18netlib-scalapack@2.0.2  
python@2.7.15   zlib@1.2.11

and includes environment-modules@3.2.10 (i.e., the module command).

Also, the library is installed in 

#  deal.II configuration:
#CMAKE_BUILD_TYPE:   DebugRelease
#BUILD_SHARED_LIBS:  ON
#CMAKE_INSTALL_PREFIX:   
/Applications/deal.II-9.0.0.app/Contents/Resources
#CMAKE_SOURCE_DIR:   
/Applications/deal.II-9.0.0.app/Contents/Resources/spack/src/dealii-v9.0.0
#(version 9.0.0)
#CMAKE_BINARY_DIR:   /Users/heltai/dealii/build-pack-deal.II-9.0.0
#CMAKE_CXX_COMPILER: Clang 6.0.0 on platform Darwin x86_64
#
/Applications/deal.II-9.0.0.app/Contents/Resources/spack/view/bin/mpicxx

Can you try to configure step-1 indicating the paths that you see here directly?

export DEAL_II_DIR=/Applications/deal.II-9.0.0.app/Contents/Resources

Notice that you should have accesso to all libraries and binaries also in 

/Applications/deal.II-9.0.0.app/Contents/Resources/spack/view/lib

and

/Applications/deal.II-9.0.0.app/Contents/Resources/spack/view/bin

That is, you can force cmake to look there by adding as option 
CMAKE_PREFIX_PATH=/Applications/deal.II-9.0.0.app/Contents/Resources/spack/view/

What happens if you try to configure and run step-1 after setting DEAL_II_DIR 
manually?

L.


> On 22 Sep 2020, at 15:15, Scott Ziegler  wrote:
> 
> I'm using version 9.0.0 of deal.ii. I have an older MacBook and it won't 
> update past iOS 10.13.6. I downloaded the .dmg file and opened it/moved it 
> into my applications but I haven't done anything else besides try to run the 
> first example.
> 
> On Tuesday, September 22, 2020 at 6:05:23 AM UTC-6 luca@gmail.com wrote:
> If he’s running from the deal.II terminal, he should have the module command 
> (it is part of the spack installation). 
> 
> The deal.II terminal exports the paths so that the module command is there. 
> What version of the deal.II package is he using? On my system, this is the 
> output I get: 
> 
> 
> 
> bash-3.2$ module avail 
> --- 
> /Applications/deal.II.app/Contents/Resources/spack/share/spack/modules/darwin-catalina-x86_64
>   
> adol-c/2.7.2 hwloc/1.11.11 numdiff/5.9.0 xz/5.2.5 
> arpack-ng/3.7.0-openblas hypre/2.18.2-openblas oce/0.18.3 zlib/1.2.11 
> assimp/4.0.1 intel-tbb/2020.2 openblas/0.3.10 
> autoconf-archive/2019.01.06 libc/1.0 openmpi/3.1.6 
> autoconf/2.69 libffi/3.3 openssl/1.1.1g 
> automake/1.16.2 libsigsegv/2.12 p4est/2.2 
> boost/1.73.0 libtool/2.4.6 parmetis/4.0.3 
> bzip2/1.0.8 libxml2/2.9.10 perl/5.18.4 
> cmake/3.17.1 m4/1.4.18 petsc/3.13.1-openblas-py2-py3 
> dealii/9.2.0-openblas-py2-py3 matio/1.5.13 pkgconf/1.7.3 
> diffutils/3.7 metis/5.1.0 python/3.7.7 
> environment-modules/4.5.1 mpc/1.1.0 readline/8.0 
> expat/2.2.9 mpfr/4.0.2 slepc/3.13.3-openblas-py2-py3 
> gdbm/1.18.1 mumps/5.2.0-openblas sqlite/3.31.1 
> gettext/0.20.2 muparser/2.2.6.1 suite-sparse/5.3.0-openblas 
> ginkgo/1.1.0 nanoflann/1.2.3 sundials/3.2.1 
> glm/0.9.7.1 ncurses/6.2 superlu-dist/6.3.0-openblas 
> gmp/6.1.2 netcdf-c/4.7.3 symengine/0.6.0 
> gmsh/4.5.4-openblas netcdf-cxx/4.2 tar/1.32 
> googletest/1.10.0 netgen/5.3.1 tcl/8.6.8 
> gsl/2.5 netlib-scalapack/2.0.2-openblas tetgen/1.5.0 
> hdf5/1.10.6 ninja/1.10.0-py2-py3 trilinos/12.18.1-openblas 
> bash-3.2$ 
> 
> 
> 
> > On 21 Sep 2020, at 22:51, Wolfgang Bangerth  wrote: 
> > 
> > 
> > Hi Luca, 
> > 
> >> Are you running the terminal, or the deal.II application? 
> >> When you run the deal.II application, you are dropped into a terminal 
> >> (with instructions) to run deal.II examples. Including how to set up 

Re: [deal.II] step-1 Error

2020-09-22 Thread luca.heltai
If he’s running from the deal.II terminal, he should have the module command 
(it is part of the spack installation). 

The deal.II terminal exports the paths so that the module command is there. 
What version of the deal.II package is he using? On my system, this is the 
output I get:



bash-3.2$ module avail
--- 
/Applications/deal.II.app/Contents/Resources/spack/share/spack/modules/darwin-catalina-x86_64
 
adol-c/2.7.2   hwloc/1.11.11numdiff/5.9.0   
   xz/5.2.5 
arpack-ng/3.7.0-openblas   hypre/2.18.2-openblasoce/0.18.3  
   zlib/1.2.11  
assimp/4.0.1   intel-tbb/2020.2 openblas/0.3.10 
   
autoconf-archive/2019.01.06libc/1.0 openmpi/3.1.6   
   
autoconf/2.69  libffi/3.3   openssl/1.1.1g  
   
automake/1.16.2libsigsegv/2.12  p4est/2.2   
   
boost/1.73.0   libtool/2.4.6parmetis/4.0.3  
   
bzip2/1.0.8libxml2/2.9.10   perl/5.18.4 
   
cmake/3.17.1   m4/1.4.18
petsc/3.13.1-openblas-py2-py3  
dealii/9.2.0-openblas-py2-py3  matio/1.5.13 pkgconf/1.7.3   
   
diffutils/3.7  metis/5.1.0  python/3.7.7
   
environment-modules/4.5.1  mpc/1.1.0readline/8.0
   
expat/2.2.9mpfr/4.0.2   
slepc/3.13.3-openblas-py2-py3  
gdbm/1.18.1mumps/5.2.0-openblas sqlite/3.31.1   
   
gettext/0.20.2 muparser/2.2.6.1 
suite-sparse/5.3.0-openblas
ginkgo/1.1.0   nanoflann/1.2.3  sundials/3.2.1  
   
glm/0.9.7.1ncurses/6.2  
superlu-dist/6.3.0-openblas
gmp/6.1.2  netcdf-c/4.7.3   symengine/0.6.0 
   
gmsh/4.5.4-openblasnetcdf-cxx/4.2   tar/1.32
   
googletest/1.10.0  netgen/5.3.1 tcl/8.6.8   
   
gsl/2.5netlib-scalapack/2.0.2-openblas  tetgen/1.5.0
   
hdf5/1.10.6ninja/1.10.0-py2-py3 
trilinos/12.18.1-openblas  
bash-3.2$ 

 

> On 21 Sep 2020, at 22:51, Wolfgang Bangerth  wrote:
> 
> 
> Hi Luca,
> 
>> Are you running the terminal, or the deal.II application?
>> When you run the deal.II application, you are dropped into a terminal (with 
>> instructions) to run deal.II examples. Including how to set up your bashrc 
>> (or zshrc) to point to the deal.II
>> Installation/the module command.
> 
> He's running in the terminal that shows all of the instructions. The problem 
> is not that 'module load dealii' doesn't know how to load deal.II, but that 
> the 'module' command doesn't seem to exist on his system. That's what the 
> error message says:
>  bash: module: command not found
> 
> I can't seem to find any information (but also don't know where to look) on 
> how one can install the 'module' command or, more generally, which general 
> package 'module' would actually come from.
> 
> Any ideas?
> 
> 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/98392d90-dbd8-8213-26f8-6a0c3c844623%40colostate.edu.

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


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

2020-09-22 Thread luca.heltai
Dear Malhar, 

just as you did for the Triangulation and the DoFHandler, also DataOut should 
be instantiated with <2,3>, i.e., 

not 

DataOut<2> …


but 


DataOut<2,3> …

Best,
Luca.


> On 22 Sep 2020, at 7:37, Malhar T.  wrote:
> 
> Hello All,
> I hope you are doing well !
> 
> I am working on a surface patch in 3D (dim=2 & spacedim=3 and developed using 
> ChartManifold<2,3> by following code similar to step-53) and I would like to 
> output the results into a vtk file. I am mostly following tutorials, as I am 
> not really great with C++. So, initially I used the class DataOut and tried 
> to specify the geometry using attach_dof_handler. 
> 
> This is how its defined,
> Triangulation<2, 3
> > triangulation;
> DoFHandler<
> 2, 3
> >dof_handler;
> 
> And output_results function was written as
> {
> DataOut data_out;
> data_out.attach_dof_handler(dof_handler);
> }
> 
> But I got the error
> 
> error: cannot convert ‘
> const dealii::DoFHandler<2, 3>’ to ‘const dealii::DoFHandler<2, 2
> >&’
> note:   initializing argument 
> 1 of ‘void dealii::DataOut_DoFData patch_space_dim>::attach_dof_handler(const DoFHandlerType&) [with 
> DoFHandlerType = dealii::DoFHandler<2, 2>; int patch_dim = 2; int 
> patch_space_dim = 2
> ]’
> 
> I tried searching in the forum and came to know about DataOutFaces (through 
> this post), and I also looked at the step-61 tutorial on its implementation, 
> but I got the same error again. I have a feeling that I am not understanding 
> something very trivial, thus, any pointers would be really helpful. 
> 
> Thank You.
> 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/7e032f3f-2957-4235-9f32-df8858a2c575n%40googlegroups.com.

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


[deal.II] Doctoral Programme in Mathematical Analysis, Modelling and Applications at SISSA, Trieste, Italy

2020-08-05 Thread luca.heltai
Dear All,

I would like to  bring at your attention that the second (and last) deadline to 
apply for a Phd position in Mathematical Analysis, Modelling and Applications 
at SISSA, Scuola Internazionale Superiore di Studi Avanzati Trieste, Italy is 
August 20, 2020 at noon (Rome time).

Research activities on applied mathematics (numerical analysis, computational 
and continuum mechanics) are carried out within SISSA mathLab 
(mathlab.sissa.it).

Our group is looking for PhD candidates with interest in scientific computing. 
In particular, I’m looking for candidates with some experience in deal.II 
programming.

Due to COVID-19, all admission exams will be held online on September 10-11, 
2020. The first part of the course will also be open for online-only students.

SISSA mathematics area is highly ranked both at national and international 
level and there are at least 5 Phd grants available.

Info about Phd programme: 
https://www.math.sissa.it/content/mathematical-analysis-modelling-and-applications-0
and https://www.sissa.it/sites/default/files/Scheda%20AMMA.pdf

(Admission exams: second session on September 10-11, 2020 with online written 
and oral examination). 

To apply: 
https://www.sissa.it/it/bandi/concorso-lammissione-ai-corsi-di-phd-della-sissa-lanno-accademico-202021

Please spread the info,
best regards

Luca.

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


Re: [deal.II] Reading a Tensor from parameter file

2020-08-05 Thread luca.heltai
> Could you please provide an MWE to describe how the 
> Patterns::Convert::to_value() function would work in this case.

In the dealii/tests/parameter_handler/patterns_05.cc

there are many examples that show how to use these.

> Is it must to use prm.add_parameter()  to be able to do so?
> I usually use prm.declare_entry() and prm.get(). 


No. It is more convenient, but not necessary:

Tensor tensor;

using C = Patterns::Tools::Convert>;

prm.declare_entry(“My tensor”, C::to_string(tensor), *C::to_pattern(), 
“Documentation”);

...

tensor = C::to_value(prm.get(“My tensor”));


Best,
Luca.

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


Re: [deal.II] KDTree implementation error

2020-07-24 Thread luca.heltai
KDTree needs nanoflann to be available. Did you compile deal.II with nanoflann 
exnabled? Check in the summary.log if DEAL_II_WITH_NANOFLANN is ON.

RTree, on the other hand, does not require nanoflann, as it is included with 
boost (and it is faster than nanoflann).

L.

> On 24 Jul 2020, at 10:05, heena patel  wrote:
> 
> Dear Luca,
> I am using 9.2 version and the implementation 
> I try to follow  from your presentation at SISSA 2018 but it gives me error. 
> Following are the lines I added to step-1. I want to implement K nearest 
> neighbor. I will work on your suggestion.
> #include 
> Point<2>  p;
>KDTree<2> tree(10,triangulation.get_vertices());
>auto w = tree.get_closest_points(p, 3);
> 
> Regards,
> Heena
> 
> 
> On Fri, Jul 24, 2020 at 8:30 AM Luca Heltai  wrote:
> If you are using version 9.3pre of deal.II, kdtree was removed. Use RTree 
> instead, which is faster and more flexible. 
> 
> Luca
> 
>> Il giorno 24 lug 2020, alle ore 05:41, heena patel  ha 
>> scritto:
>> 
>> 
>> Dear Bruno,
>>I had already added kdree.h header file, 
>> check the question again. But it seems it does not read KDTree; something is 
>> not compatible between class and header file.
>> 
>> Regards,
>> Heena
>> 
>> On Thu, Jul 23, 2020 at 9:03 PM Bruno Turcksin  
>> wrote:
>> Heena,
>> 
>> You are missing an include. Try adding #include 
>> 
>> Best,
>> 
>> Bruno
>> 
>> On Thursday, July 23, 2020 at 2:55:53 PM UTC-4, heena patel wrote:
>> 
>> Dear all,
>>   I had tried to implement KDTree in step_1 tutoria 
>> and header file for kdtree is added to the codel. It is as follows:
>> 
>> void first_grid()
>> {
>> 
>>   Triangulation<2> triangulation;
>> 
>>   GridGenerator::hyper_cube(triangulation);
>>   triangulation.refine_global(4);
>>   Point<2>  p;
>>KDTree<2> tree(10,triangulation.get_vertices());
>>auto w = tree.get_closest_points(p, 3);
>>   std::ofstream out("grid-1.svg");
>>   GridOut   grid_out;
>>   grid_out.write_svg(triangulation, out);
>>   std::cout << "Grid written to grid-1.svg" << std::endl;
>> }
>> 
>> 
>> 
>> It gives me error as below 
>> 
>> /home/heena/Project/examples/step-1/step-1.cc:76:4: error: ‘KDTree’ was not 
>> declared in this scope
>> KDTree<2> tree(10,triangulation.get_vertices());
>> ^~
>> /home/heena/Project/examples/step-1/step-1.cc:76:4: note: suggested 
>> alternative: ‘free’
>> KDTree<2> tree(10,triangulation.get_vertices());
>> ^~
>> free
>> /home/heena/Project/examples/step-1/step-1.cc:76:14: error: ‘tree’ was not 
>> declared in this scope
>> KDTree<2> tree(10,triangulation.get_vertices());
>>   ^~~~
>> /home/heena/Project/examples/step-1/step-1.cc:76:14: note: suggested 
>> alternative: ‘free’
>> KDTree<2> tree(10,triangulation.get_vertices());
>>   ^~~~
>>   free
>> 
>> 
>> 
>> Is there something missing?
>> 
>> 
>> 
>> Regards,
>> Heena
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "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/d761c989-ef92-4603-8c8e-85ec4eeb3766o%40googlegroups.com.
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "deal.II User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dealii+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/CAG_OxbgYqw02b4TnJAvBgWo7dvjRvf7zr6V%2BcBDKE_5hafCDJA%40mail.gmail.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/82AC7F19-2444-4E74-90B0-DCAC8F3722C2%40gmail.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> 

Re: [deal.II] KDTree implementation error

2020-07-24 Thread luca.heltai
Dear Heena, 

here is a snippet to achieve what you want:


#include 
namespace bgi = boost::geometry::index;

…


Point<2>  p0;
const auto tree = pack_rtree(tria.get_vertices());

for (const auto  : tree | bgi::adaptors::queried(bgi::nearest(p0, 3)))
// do something with p
std::cout << p << std::endl;

or, if you need the indices of the points:

const auto tree_of_indices = pack_rtree_of_indices(tria.get_vertices());

for (const auto  : tree_of_indices | bgi::adaptors::queried(bgi::nearest(p0, 
3)))
// do something with i
std::cout << “Closest vertex has index "<< i << std::endl;


see 

https://github.com/dealii/dealii/blob/master/tests/boost/rtree_03.cc

for the example above.

L.

> On 24 Jul 2020, at 10:05, heena patel  wrote:
> 
> Dear Luca,
> I am using 9.2 version and the implementation 
> I try to follow  from your presentation at SISSA 2018 but it gives me error. 
> Following are the lines I added to step-1. I want to implement K nearest 
> neighbor. I will work on your suggestion.
> #include 
> Point<2>  p;
>KDTree<2> tree(10,triangulation.get_vertices());
>auto w = tree.get_closest_points(p, 3);
> 
> Regards,
> Heena
> 
> 
> On Fri, Jul 24, 2020 at 8:30 AM Luca Heltai  wrote:
> If you are using version 9.3pre of deal.II, kdtree was removed. Use RTree 
> instead, which is faster and more flexible. 
> 
> Luca
> 
>> Il giorno 24 lug 2020, alle ore 05:41, heena patel  ha 
>> scritto:
>> 
>> 
>> Dear Bruno,
>>I had already added kdree.h header file, 
>> check the question again. But it seems it does not read KDTree; something is 
>> not compatible between class and header file.
>> 
>> Regards,
>> Heena
>> 
>> On Thu, Jul 23, 2020 at 9:03 PM Bruno Turcksin  
>> wrote:
>> Heena,
>> 
>> You are missing an include. Try adding #include 
>> 
>> Best,
>> 
>> Bruno
>> 
>> On Thursday, July 23, 2020 at 2:55:53 PM UTC-4, heena patel wrote:
>> 
>> Dear all,
>>   I had tried to implement KDTree in step_1 tutoria 
>> and header file for kdtree is added to the codel. It is as follows:
>> 
>> void first_grid()
>> {
>> 
>>   Triangulation<2> triangulation;
>> 
>>   GridGenerator::hyper_cube(triangulation);
>>   triangulation.refine_global(4);
>>   Point<2>  p;
>>KDTree<2> tree(10,triangulation.get_vertices());
>>auto w = tree.get_closest_points(p, 3);
>>   std::ofstream out("grid-1.svg");
>>   GridOut   grid_out;
>>   grid_out.write_svg(triangulation, out);
>>   std::cout << "Grid written to grid-1.svg" << std::endl;
>> }
>> 
>> 
>> 
>> It gives me error as below 
>> 
>> /home/heena/Project/examples/step-1/step-1.cc:76:4: error: ‘KDTree’ was not 
>> declared in this scope
>> KDTree<2> tree(10,triangulation.get_vertices());
>> ^~
>> /home/heena/Project/examples/step-1/step-1.cc:76:4: note: suggested 
>> alternative: ‘free’
>> KDTree<2> tree(10,triangulation.get_vertices());
>> ^~
>> free
>> /home/heena/Project/examples/step-1/step-1.cc:76:14: error: ‘tree’ was not 
>> declared in this scope
>> KDTree<2> tree(10,triangulation.get_vertices());
>>   ^~~~
>> /home/heena/Project/examples/step-1/step-1.cc:76:14: note: suggested 
>> alternative: ‘free’
>> KDTree<2> tree(10,triangulation.get_vertices());
>>   ^~~~
>>   free
>> 
>> 
>> 
>> Is there something missing?
>> 
>> 
>> 
>> Regards,
>> Heena
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "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/d761c989-ef92-4603-8c8e-85ec4eeb3766o%40googlegroups.com.
>> 
>> -- 
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see 
>> https://groups.google.com/d/forum/dealii?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "deal.II User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dealii+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/CAG_OxbgYqw02b4TnJAvBgWo7dvjRvf7zr6V%2BcBDKE_5hafCDJA%40mail.gmail.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the 

Re: [deal.II] Particles and field interpolation error

2020-07-22 Thread luca.heltai
Dear Franco, 

you need read access to the locally active dofs, not just the locally owned 
dofs. 

Take a look at how things are done in step-70:

the vector that is used to interpolate the field on the particles is a 
read-only ghosted vector, that contains the locally relevant dofs


locally_relevant_solution.reinit(fluid_owned_dofs,
 fluid_relevant_dofs,
 mpi_communicator);


initialized right after it has been computed:

solver.solve(system_matrix, solution, system_rhs, P);
constraints.distribute(solution);
locally_relevant_solution = solution;

The particle interpolation needs read access to all dofs that belong to active 
cells. Those may not be owned by the current mpi process, and therefore you 
need a ghosted vector.

 Particles::Utilities::interpolate_field_on_particles(
fluid_dh,
tracer_particle_handler,
locally_relevant_solution,
tracer_particle_velocities,
fluid_fe->component_mask(FEValuesExtractors::Vector(0)));

Best,
Luca.

> On 21 Jul 2020, at 17:14, franco.m...@gmail.com  
> wrote:
> 
> Thanks for your hint, now the parallel distributed triangulation works and 
> global particles are correct. However, it crashes when interpolating the 
> field on particles.
> 
> This is how I initialize the field vector:
> 
> GridGenerator::hyper_cube(triangulation, 0, 1);
> triangulation.refine_global(5);
> dof_handler.distribute_dofs(fe);
> IndexSet fluid_owned_dofs;
> fluid_owned_dofs = dof_handler.locally_owned_dofs();
> field.reinit(fluid_owned_dofs, MPI_COMM_WORLD);
> VectorTools::interpolate(dof_handler, initial_function, field);
> 
> Something is wrong, since it seems I cannot get the output VTU correctly:
> 
> 
> 
> An error occurred in line <1215> of file 
> 
>  in function
> 
> void dealii::PETScWrappers::VectorBase::extract_subvector_to(const 
> ForwardIterator, const ForwardIterator, OutputIterator) const 
> [ForwardIterator = const unsigned int *, OutputIterator = double *]
> 
> The violated condition was: 
> 
> index >= static_cast(begin) && index < static_cast int>(end)
> 
> Additional information: 
> 
> This exception -- which is used in many places in the library -- usually 
> indicates that some condition which the author of the code thought must be 
> satisfied at a certain point in an algorithm, is not fulfilled. An example 
> would be that the first part of an algorithm sorts elements of an array in 
> ascending order, and a second part of the algorithm later encounters an 
> element that is not larger than the previous one.
> 
> There is usually not very much you can do if you encounter such an exception 
> since it indicates an error in deal.II, not in your own program. Try to come 
> up with the smallest possible program that still demonstrates the error and 
> contact the deal.II mailing lists with it to obtain help.
> 
> 
> 
> The field on particle locations is interpolated as follows:
> 
> IndexSet locally_owned_tracer_particle_coordinates;
> locally_owned_tracer_particle_coordinates = 
> particle_handler.locally_relevant_ids().tensor_product(complete_index_set(2));
> 
> field_on_particles.reinit(locally_owned_tracer_particle_coordinates, 
> MPI_COMM_WORLD);
> 
> //field_on_particles.reinit(MPI_COMM_WORLD, total_particles*2 
> ,particle_handler.n_locally_owned_particles()*2);
> 
> MPI_Barrier(MPI_COMM_WORLD);
> for(int i = 0; i < n_mpi_processes; i++)
> {
> if(this_mpi_process == i)
> std::cout   << "VECTOR FIELD ON PARTICLES"
> << "MPI_process: " << i
> << " vec.size: " << field_on_particles.size()
> << " vec.local_size: " << 
> field_on_particles.local_size()
> << std::endl;
> }
> MPI_Barrier(MPI_COMM_WORLD);
> 
> for(int i = 0; i < n_mpi_processes; i++)
> {
> if(this_mpi_process == i)
> std::cout   << "VECTOR FIELD"
> << "MPI_process: " << i
> << " vec.size: " << field.size()
> << " vec.local_size: " << field.local_size()
> << " vec.range from: " << 
> field.local_range().first << "  to: " << field.local_range().second
> << std::endl;
> }
> Particles::Utilities::interpolate_field_on_particles(dof_handler, 
> particle_handler, field, field_on_particles);
> 
> The interpolation error regards accessing an element out of the local range. 
> As before, I am probably initializing vectors incorrectly:
> 
> MPI_rank: 0   cell_center: 0.015625 0.015625
> [...]
> MPI_rank: 1   cell_center: 0.984375 0.015625
> MPI_process: 0 locally_owned_particles: 16 total_particles: 32 
> n_global_particles: 32
> 

Re: [deal.II] Particles and field interpolation error

2020-07-20 Thread luca.heltai
Dear Franco, 

what type of triangulation are you using? If you look at the code that is run 
with `update_cached_numbers` 

https://github.com/dealii/dealii/blob/9e50f3ac04d088a9d2ffa74a81f08348e7f98a65/source/particles/particle_handler.cc#L173

you will see that the numbers are updated (just as you are doing manually) for 
parallel::distributed::Triangulation objects, and otherwise the triangulation 
is treated as if it was a serial one. 

I suspect you are using a parallel::shared::Triangulation object. 

The ParticleHandler class was built with parallel::shared::Triangulation 
objects in mind, and only recently was made to work with serial triangulations.

You have spotted a bug in the library, in the sense that ParticleHandler should 
throw an exception when the Triangulation is paralell::shared, but not 
parallel::distributed. Since all triangulation are derived from the serial one, 
ParticleHandler thinks your triangulation is serial, and therefore gets 
incosistent numbers across the processors. 

I think there are only a few places that we would need to change to make the 
code run also in your case, but to be on the safe side, I’d switch to 
parallel::distributed::Triangulation (if you can), otherwise I can assist you 
in opening a pull request with the required changes. 

Luca.



> On 20 Jul 2020, at 17:48, franco.m...@gmail.com  
> wrote:
> 
> Dear Luca,
> 
> thanks for your answer, I've moved along but I am still encountering problems 
> in the interpolation. This seems to be a problem with the way I use PETSc.
> 
> So, as far as I understand, I need to initialize a PETSc vector of length 
> n_global_particles * components (in my case, 2, the space dimension), and 
> locally each process should handle n_locally_owned_particles * components. 
> 
> First, just a simple question: is n_global_particles working correctly on 
> processes without any? It seems that it returns zero when no particles are 
> locally owned, but the documentation, as I understand, says it should yield 
> the same value on all processes.
> 
> The code I am using is this:
> 
> void Step3::setup_system()
> {
> GridTools::partition_triangulation(n_mpi_processes, triangulation);
> dof_handler.distribute_dofs(fe);
> DoFRenumbering::subdomain_wise(dof_handler);
>  
> const std::vector locally_owned_dofs_per_proc = 
> DoFTools::locally_owned_dofs_per_subdomain(dof_handler);
> const IndexSet locally_owned_dofs = 
> locally_owned_dofs_per_proc[this_mpi_process];
> 
> field.reinit(locally_owned_dofs, mpi_communicator);
> 
> VectorTools::interpolate(dof_handler, initial_function, field);
> 
> // Particles
> 
> particle_handler.initialize(triangulation, StaticMappingQ1<2>::mapping);
> 
> std::vector> particles_to_insert;
> 
> for (const auto  : dof_handler.active_cell_iterators())
> {
> if (cell->subdomain_id() == this_mpi_process)
> {
> if(cell->center()(1) < 0.03)
> {
> particles_to_insert.emplace_back(cell->center());
> std::cout << "MPI_rank: "<< this_mpi_process  << "   
> cell_center: " << cell->center() << std::endl;
> }
> }
> }
> particle_handler.insert_particles(particles_to_insert);
> particle_handler.update_cached_numbers();
> 
> // n_global_particles returns zero when no particles are locally owned: 
> compute the real number
> int total_particles = 
> Utilities::MPI::sum(particle_handler.n_global_particles(), mpi_communicator);
> 
> for(int i = 0; i < n_mpi_processes; i++)
> {
> if(this_mpi_process == i)
> std::cout << "MPI_process: " << i
>   << " locally_owned_particles: " << 
> particle_handler.n_locally_owned_particles()
>   << " total_particles: " << total_particles
>   << " n_global_particles: " << 
> particle_handler.n_global_particles()
>   << std::endl;
> }
> 
> field_on_particles.reinit(mpi_communicator, total_particles*2 , 
> particle_handler.n_locally_owned_particles()*2);
> field_on_particles.compress(VectorOperation::add); // unnecessary?
> 
> for(int i = 0; i < n_mpi_processes; i++)
> {
> if(this_mpi_process == i)
> std::cout   << "VECTOR"
> << "MPI_process: " << i
> << " vec.size: " << field_on_particles.size()
> << " vec.local_size: " << 
> field_on_particles.local_size()
> << std::endl;
> }
> 
> Particles::Utilities::interpolate_field_on_particles(dof_handler, 
> particle_handler, field, field_on_particles);
> 
> }
> 
> As you can see, I am following the 
> Particles::Utilities::interpolate_field_on_particles, by initializing a PETSc 
> vector with "the size of the vector must be n_locally_owned_particles times 
> the n_components", the total size I guess 

Re: [deal.II] Particles and field interpolation error

2020-07-16 Thread luca.heltai
Ciao Franco, 

ParticleHandler was built with the intention of “losing” particles whenever 
they fall out of the domain. This is the default behaviour of the 
ParticleHandler, and unless you store a pointer to an existing particle 
somewhere, you should not be in trouble. 

If you iterate over the particles using the ParticleHandler, you should be 
safe. The Utilities::interpolate_on_field cannot know how many particles are 
actually there, so it asks the ParticleHandler for the 
next_available_particle_index(), which should not change, even if you drop some 
particles.

The way the interpolator works, is by looping *through* the ParticleHandler 
(again, on the safe side), and deciding what to store where based on the 
current particle id. Unless you renumber and reset all particle ids between the 
removal and the interpolation, this will remain consistent.

Luca.

> On 16 Jul 2020, at 13:47, franco.m...@gmail.com  
> wrote:
> 
> Thanks, Luca.
> 
> I have read the documentation, that's why I was skeptic of my own code: I 
> still think I am doing it wrong.
> 
> As far as I understand from the documentation, particles should be removed 
> from the handler after updating the cache, and thus the interpolated field 
> should not contain the old removed one. Unfortunately I don't see any mention 
> of "removal" in Particles::Utilities, but I could overlooking something here.
> 
> Another question relative to the removal part is more of a worry. If I remove 
> a particle, will any iterator be invalidated? If so, and say I need to remove 
> a lot of particles, what is the best way to do this without too much 
> overhead? As I understand, I have to remove (just one?) a particle and call a 
> cache update at the end of the removal process.
> 
> Thanks!
> Franco
> On Wednesday, July 15, 2020 at 7:47:58 PM UTC+2 luca@gmail.com wrote:
> Franco,
> 
> The interpolated field says that the field value is zero (on the line above 
> your arrow). This is how it is documented: if a particle is removed, its 
> interpolated value is left unchanged in the target vector. Zero in your case. 
> 
> Luca
> 
>> Il giorno 15 lug 2020, alle ore 18:18, Franco Milicchio 
>>  ha scritto:
>> 
>> 
>> Dear all,
>> 
>> I am playing with 9.2 and particles, but I've encountered a weird problem. 
>> If I remove a particle, the interpolated field on particle locations yields 
>> a wrong answer.
>> 
>> My code does (now) everything by hand:
>> 
>>   // Here be drangons...
>> 
>>   Point<2> p_0(0.1,0.5);
>>   auto ref_cell_0 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_0);
>>   Point<2> ref_p_0 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_0, p_0);
>> 
>>   Point<2> p_1(0.5,0.5);
>>   auto ref_cell_1 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_1);
>>   Point<2> ref_p_1 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_1, p_1);
>> 
>>   Point<2> p_2(0.9,0.5);
>>   auto ref_cell_2 = GridTools::find_active_cell_around_point(dof_handler, 
>> p_2);
>>   Point<2> ref_p_2 = 
>> StaticMappingQ1<2>::mapping.transform_real_to_unit_cell(ref_cell_2, p_2);
>> 
>>   particle_handler.insert_particle(Particles::Particle<2>(p_0, ref_p_0, 0), 
>> ref_cell_0);
>>   particle_handler.insert_particle(Particles::Particle<2>(p_1, ref_p_1, 1), 
>> ref_cell_1);
>>   particle_handler.insert_particle(Particles::Particle<2>(p_2, ref_p_2, 2), 
>> ref_cell_2);
>> 
>>   particle_handler.update_cached_numbers();
>> 
>>   std::cout << "Printing particle id, location and reference location" << 
>> std::endl;
>>   for(auto :particle_handler)
>>   {
>> std::cout << "id: " << p.get_id() << "  loc: " << p.get_location() << "  
>> ref_loc: " << p.get_reference_location() << std::endl;
>>   }
>> 
>>   field_on_particles.reinit(particle_handler.n_global_particles());
>>   Particles::Utilities::interpolate_field_on_particles(dof_handler, 
>> particle_handler, field, field_on_particles);
>> 
>>   std::cout << "Printing field value on particle location" << std::endl;
>>   for(int pp = 0; pp< particle_handler.n_global_particles(); pp++)
>>   {
>>   std::cout << "fluid id: " << pp << " value: " << 
>> field_on_particles[pp] << std::endl;
>>   }
>> 
>>   // 
>>   // NOW REMOVE A PARTICLE...
>>   // 
>> 
>>   for(auto itr=particle_handler.begin(); itr != particle_handler.end(); 
>> itr++)
>>   {
>> if(itr->get_id()==1) particle_handler.remove_particle(itr);
>>   }
>> 
>>   particle_handler.update_cached_numbers();
>> 
>> 
>>   // ***
>>   // ...AND VALUES ARE WRONG
>>   // ***
>> 
>>   std::cout << "Printing particle id, location and reference location after 
>> removing particle" << std::endl;
>> 
>>   for(auto itr_2=particle_handler.begin(); itr_2 != particle_handler.end(); 
>> itr_2++)
>>   {
>> std::cout << "id: " << itr_2->get_id() << "  loc: " << 
>> itr_2->get_location() << "  ref_loc: " << 

Re: [deal.II] New docker image for deal.II 9.2.0

2020-07-16 Thread luca.heltai
We should all thank Matthias. He’s the one responsible for the "apt-get install 
deal.ii-dev” magic which is happening here…

:)

Luca.

> On 16 Jul 2020, at 19:22, Bruno Blais  wrote:
> 
> Awesome!
> Thank you so much for taking the time to prepare these images Luca. They are 
> amazingly helpful for those using Travis_CI for their deal.II derived codes 
> :).
> 
> 
> On Wednesday, 15 July 2020 05:04:31 UTC-4, luca.heltai wrote:
> Dear all, 
> 
> I’d like to inform you that we now have also docker images with deal.II 
> 9.2.0, based on ubuntu bionic (18.04.1), and based on ubuntu focal (20.04.1). 
> 
> You can find them with 
> 
> docker pull dealii/dealii:v9.2.0-bionic 
> docker pull dealii/dealii:v9.2.0-focal  (dealii/dealii:latest) 
> 
> Best, 
> Luca. 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/77ba1dd9-9623-4392-9398-f33631a0328do%40googlegroups.com.

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


[deal.II] New docker image for deal.II 9.2.0

2020-07-15 Thread luca.heltai
Dear all, 

I’d like to inform you that we now have also docker images with deal.II 9.2.0, 
based on ubuntu bionic (18.04.1), and based on ubuntu focal (20.04.1).

You can find them with 

docker pull dealii/dealii:v9.2.0-bionic
docker pull dealii/dealii:v9.2.0-focal  (dealii/dealii:latest)

Best,
Luca.

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


Re: [deal.II] Interest in a step-12-like DG tutorial but for the advection-diffusion equation?

2020-07-10 Thread luca.heltai
If you want to take some more inspiration using mesh_loop, ScratchData, and 
FEInterfaceData, you could take a look at this:

https://github.com/dealii/dealii/blob/master/tests/meshworker/scratch_data_08.cc

where the FEInterfaceValues which is now included in ScratchData is used to 
solve SIPG on locally refined grids, with just this:



for (unsigned int q = 0; q < p.size(); ++q)
  for (unsigned int i = 0; i < n_dofs; ++i)
for (unsigned int j = 0; j < n_dofs; ++j)
  {
face_matrix(i, j) +=
  (-fev.jump_gradient(i, q) * n[q] * fev.average(j, q) -
   fev.average(i, q) * fev.jump_gradient(j, q) * n[q] +
   gh * fev.jump(i, q) * fev.jump(j, q)) *
  JxW[q];
  }
  };

:)

Ps: I am planning to extend FEInterfaceValues to be able to extract function 
values and gradients, so that it can also be used easily with the automatic 
differentiation tools that 
we have, or to easily write a posteriori error estimators… If anybody is 
looking for a starter project, this may be a very nice one.

L.

> On 10 Jul 2020, at 17:09, Bruno Blais  wrote:
> 
> Dear Timo,
> A step-12-like version of Step-39 for the Laplace equation would be very 
> interesting. I would be glad to help on making one of those. The same could 
> be said about the Stokes equations.
> 
> Ideally, once that is done, i would like to try and make one for stabilized 
> Navier-Stokes for both CG and DG, but I feel I need a bit more of experience 
> with writing steps before I move on to that.
> 
> So if you feel you need any help with the two aforementioned steps, I would 
> be glad to help. I really like what you have done with the FEInterfaceValues, 
> so if we can make it more popular, why not ? :)!
> I am also integrating teaching DG within one of my graduate classes and I 
> feel using deal.II for that will be really helpful.
> 
> Best
> Bruno
> 
> 
> 
> 
> On Friday, 10 July 2020 07:39:08 UTC-4, Timo Heister wrote:
> Hi Bruno, 
> 
> I introduced FEInterfaceValues because I was frustrated by the lack of 
> DG examples and as a consequence DG users in the community and I 
> realized that a more intuitive way to teach it was necessary. Of 
> course we need more than 1 or 2 examples to do that. 
> I have a lot of unfinished stuff on my machine including working 
> Laplace and Stokes examples (see my todo list here 
> https://github.com/dealii/dealii/issues/8884 ) that I haven't gotten 
> back to yet. 
> 
> Let me know if you want to work together on something or if you have 
> any ideas or suggestions. 
> 
> Best, 
> Timo 
> 
> 
> On Thu, Jul 9, 2020 at 8:50 PM Bruno Blais  wrote: 
> > 
> > Dear all, 
> > I hope you are well. 
> > I have been playing with the DG methods within deal.II lately (which has 
> > been lots of fun). 
> > I really enjoy the way step-12 is written, especially because of the use of 
> > the FEInterfaceValue class. In my opinion it makes low level stuff very 
> > easily accessible, yet it is relatively easy to understand. 
> > However, I am under the impression that there are no similar test for 
> > elliptic equations in which you need to use Nitsche method + Symmetric 
> > Interior Penalty for the boundary + inner faces respectively. I know of 
> > step-39, but it does not use the same "low-levelish" features. 
> > I have written such a code for my own pleasure for the laplace equation and 
> > I am currently working on its advection-diffusion version (mostly following 
> > Larson Chapter 14). 
> > 
> > Would it be interesting to turn such a case into a deal.II step (that would 
> > follow in step-12 footstep) or does the community feel that the existing 
> > steps for DG sufficiently cover the ground? 
> > 
> > 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 dea...@googlegroups.com. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/dealii/b931b23c-b284-4047-a887-d500ac9e8486o%40googlegroups.com.
> >  
> 
> 
> 
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/9340f75c-a631-46e0-ac2e-400c6d14ff57o%40googlegroups.com.

-- 
The deal.II project is located at http://www.dealii.org/

Re: [deal.II] New deal.II 9.2.0 package for MAC

2020-06-29 Thread luca.heltai
 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/examples/step-18
> 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-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
> 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-18
> bash-3.2$ ./step-18 
> dyld: Library not loaded: libmetis.dylib
>   Referenced from: 
> /Users/albertosalvadori/Codes/dealii-9.2/examples/step-18/./step-18
>   Reason: image not found
> Abort trap: 6
> bash-3.2$ 
> 
> 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 Wed, Jun 24, 2020 at 6:31 PM luca.heltai  wrote:
> Dear All, 
> 
> there has been an issue with the deal.II Package which I hope I was able to 
> resolve. 
> 
> The new mac package is in the same place of the old one
> 
> https://github.com/dealii/dealii/releases/download/v9.2.0/dealii-9.2.0.dmg
> 
> Would anyone with a mac try it out and tell me if they can run it?
> 
> Luca. 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/97155645-AFE0-461D-B1D1-1667F4718CFE%40gmail.com.
> 
> 
> 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/CABcATpdtf52w62ZQiJgkoMx5aFRf5HtyQSoTPnAZKteRwHMA_g%40mail.gmail.com.

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


[deal.II] New deal.II 9.2.0 package for MAC

2020-06-24 Thread luca.heltai
Dear All, 

there has been an issue with the deal.II Package which I hope I was able to 
resolve. 

The new mac package is in the same place of the old one

https://github.com/dealii/dealii/releases/download/v9.2.0/dealii-9.2.0.dmg

Would anyone with a mac try it out and tell me if they can run it?

Luca. 

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


Re: [deal.II] GMesh 1D mesh input error

2020-06-24 Thread luca.heltai
This may be a problem with your physical ids. Can you remove all physical ids 
from the geo file, and try to export a “bare” mesh, without material 
id/boundary id information? 

I currently use vtk for all my needs.

L.

> On 24 Jun 2020, at 14:53, Victoria W.  wrote:
> 
> Hi David, 
> 
> Thank you for getting back to me.  I've tried with a .inp mesh produced by 
> both gmsh and freeCAD, but I get the same error with my .inp gmsh export and 
> when I use the FreeCAD export I have to use the read_abaqus() read in method 
> which has been giving me a bad_alloc error message.  I even tried writing the 
> 1D mesh from scratch by looking at the tutorial mesh, but that also produced 
> a GridIn error.  Do you have any other program suggestions for exporting the 
> mesh?  I'm currently installing Salome and looking to try that next, but 
> please let me know if there's something else I should be using. 
> 
> Thank you and all the best, 
> Victoria 
> 
> On Tuesday, June 23, 2020 at 12:36:01 PM UTC-4, David Wells wrote:
> Hi Victoria,
> 
> This is definitely a bug with our gmsh reader - the problem is it assigns the 
> boundary ids of 0 to all nodes (since they are associated with a material id 
> of 0), which doesn't make sense since none of the given elements are actually 
> boundary elements. My best guess is that we never tested this code with 1D 
> meshes with nonzero codimension.
> 
> The fix to the GMSH code is not immediately obvious. As a temporary 
> workaround, would it be possible for you to convert your mesh to a .inp? That 
> reader seems to work correctly for the dim = 1 spacedim = 2 combination.
> 
> Best,
> David
> 
> On Thu, Jun 18, 2020 at 10:17 AM Victoria W.  wrote:
> Hi David, 
> 
> I've been using read_msh() with a version 1 gmsh 1D mesh for the boundary 
> definition.  Attaching the code snipped of my read_domain() function and the 
> mesh here.  Thank you for your help.
> 
> Best, Victoria 
> 
> 
> On Thursday, June 18, 2020 at 9:35:59 AM UTC-4, David Wells wrote:
> Hi Victoria,
> 
> It's difficult to tell what is going on without seeing some code but this 
> looks like a bug in deal.II: that's the correct GridIn function and 
> everything should be at the boundary but the assertion still fails for 
> reasons that appear to be wrong.
> 
> Can you reproduce the same error if you use that mesh with step-34, where you 
> only modify the call to gi.read_ucd() to gi.read_msh()? If so, would you 
> please post the mesh to this thread?
> 
> Best,
> David
> 
> On Wed, Jun 17, 2020 at 1:28 PM Victoria W.  wrote:
> Hello, 
> 
> I've been getting the following error message when I try and input a 1D mesh 
> in 2D space for a boundary element method simulation.  I'm working with 
> step-34 tutorial program to model an electric field on an electrode, but I 
> can't get past this mesh input step.  I have tried all of the mesh types that 
> gmsh can output and that dealii will except.  Has anyone seen this before, 
> and does anyone have advice for me?  Thank you to anyone who can help or give 
> advice! 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dea...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/63e62794-13a9-4562-9d60-4568681c077eo%40googlegroups.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dea...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/0c04e288-82dd-4f2b-b873-ebafbe49987co%40googlegroups.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/688f383d-d44c-47de-819c-fced52432518o%40googlegroups.com.

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

Re: [deal.II] triangulation save not working for 1D domain

2020-06-07 Thread luca.heltai
You could use a boost archive, and save the triangulation to a binary file 
using operator << (and >> to load it), i.e.:


#include 
#include 

...

std::ofstream file(filename, std::ios::binary | std::ios::trunc);
boost::archive::binary_oarchive oa(file);

oa << tria;


and then restore it with 


std::ifstream file(filename, std::ios::binary);
boost::archive::binary_iarchive ia(file);

ia >> tria;

Alternatively, use the method GridOut::write_vtu and GridIn::read_vtu.

Best,
Luca.

> On 7 Jun 2020, at 17:12, Amaresh B  wrote:
> 
> Thank you Luca for your reply. I can avoid 
> parallel::distributed::Triangulation and use serial code. Can you suggest a 
> method to save the solutions along with the triangulation which can be used 
> for restarting code? Also please let me know if any example code is available.
> 
> Thanks
> 
> Sincerely
> Amaresh
> 
> On Sun, Jun 7, 2020 at 8:39 PM luca.heltai  wrote:
> Amaresh,
> 
> as the documentation states, parallel::distributed::Triangulation is not 
> implemented in 1d. Consequently, parallel::distributed::SolutionTransfer will 
> not work in 1d. 
> 
> Are you running your code in debug mode? In debug mode several assertions are 
> throw when you try to instantiate a 1d parallel::distributed::Triangulation.
> 
> L.
> 
> > On 7 Jun 2020, at 16:59, Amaresh B  wrote:
> > 
> > I have even tried with subdivided_hyper_rectangle . The triangulation is 
> > not saved.
> > 
> > 
> > 
> > On Saturday, June 6, 2020 at 11:25:03 PM UTC+5:30, Amaresh B wrote:
> > Thank you peterrum for your reply.
> > 
> > I have tried the following commands. In both the cases, the triangulation 
> > was not saved. Please let me know if you have any suggestions.
> > 
> > 1.GridGenerator::hyper_cube (triangulation, 0., 40.0);
> > 
> > 
> > 2.   GridGenerator::hyper_rectangle(triangulation,
> >Point(0.0),
> >Point(40.0),
> >true);
> > 
> > 
> > Thanks,
> > Amaresh
> > 
> > 
> > On Saturday, June 6, 2020 at 9:33:20 PM UTC+5:30, peterrum wrote:
> > What type of triangulation are you using?
> > 
> > Peter
> > 
> > On Saturday, 6 June 2020 17:52:53 UTC+2, Amaresh B wrote:
> >   Dear all,
> > 
> > I am trying to save my triangulation and using the lines below. 
> > 'triangulation.save' commands works and saves the mesh if my domain is 
> > either 2D or 3D (i.e. dim=2 or 3). However, it does not save the 
> > triangulation if dim=1, nor it gives any error message. I will be thankful 
> > if someone can comment on it and give suggestions.
> > 
> > 
> > 
> >std::vector sol_transfer_vectors;
> >
> > sol_transfer_vectors.push_back();
> > 
> > 
> > parallel::distributed::SolutionTransfer 
> > sol_transfer(dof_handler);
> >sol_transfer.prepare_for_serialization 
> > (sol_transfer_vectors);
> > 
> >triangulation.save("restart.mesh");
> > 
> > Thank you,
> > 
> > Regards
> > Amaresh
> >  
> > 
> > -- 
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see 
> > https://groups.google.com/d/forum/dealii?hl=en
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "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/816239ba-d993-4ae1-8772-77d920b946eeo%40googlegroups.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/618C643B-C88D-4BFF-B82D-A2B2675C467A%40gmail.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this 

Re: [deal.II] triangulation save not working for 1D domain

2020-06-07 Thread luca.heltai
Amaresh,

as the documentation states, parallel::distributed::Triangulation is not 
implemented in 1d. Consequently, parallel::distributed::SolutionTransfer will 
not work in 1d. 

Are you running your code in debug mode? In debug mode several assertions are 
throw when you try to instantiate a 1d parallel::distributed::Triangulation.

L.

> On 7 Jun 2020, at 16:59, Amaresh B  wrote:
> 
> I have even tried with subdivided_hyper_rectangle . The triangulation is not 
> saved.
> 
> 
> 
> On Saturday, June 6, 2020 at 11:25:03 PM UTC+5:30, Amaresh B wrote:
> Thank you peterrum for your reply.
> 
> I have tried the following commands. In both the cases, the triangulation was 
> not saved. Please let me know if you have any suggestions.
> 
> 1.GridGenerator::hyper_cube (triangulation, 0., 40.0);
> 
> 
> 2.   GridGenerator::hyper_rectangle(triangulation,
>Point(0.0),
>Point(40.0),
>true);
> 
> 
> Thanks,
> Amaresh
> 
> 
> On Saturday, June 6, 2020 at 9:33:20 PM UTC+5:30, peterrum wrote:
> What type of triangulation are you using?
> 
> Peter
> 
> On Saturday, 6 June 2020 17:52:53 UTC+2, Amaresh B wrote:
>   Dear all,
> 
> I am trying to save my triangulation and using the lines below. 
> 'triangulation.save' commands works and saves the mesh if my domain is either 
> 2D or 3D (i.e. dim=2 or 3). However, it does not save the triangulation if 
> dim=1, nor it gives any error message. I will be thankful if someone can 
> comment on it and give suggestions.
> 
> 
> 
>std::vector sol_transfer_vectors;
>sol_transfer_vectors.push_back();
> 
> 
> parallel::distributed::SolutionTransfer 
> sol_transfer(dof_handler);
>sol_transfer.prepare_for_serialization 
> (sol_transfer_vectors);
> 
>triangulation.save("restart.mesh");
> 
> Thank you,
> 
> Regards
> Amaresh
>  
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/816239ba-d993-4ae1-8772-77d920b946eeo%40googlegroups.com.

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


Re: [deal.II] step 70 9.2 version

2020-06-05 Thread luca.heltai
Yes. On it.

L.

> On 5 Jun 2020, at 18:21, Wolfgang Bangerth  wrote:
> 
> On 6/5/20 10:19 AM, luca.heltai wrote:
>> Wolfgang, it seems that indeed the default parameter file in 9.2 still 
>> contains `set Output directory = results`.:(
> 
> Want to move that to the 9.2.x branch in case we create a .1 release?
> 
> 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/2b049651-fe11-0be9-d096-4dc87c53190c%40colostate.edu.

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


Re: [deal.II] step 70 9.2 version

2020-06-05 Thread luca.heltai
Dear Heena, 

unfortunately, we failed in cherry picking a default value in the parameter 
file. 

The generated parameter handler tries to write output files in a `results` 
directory (as indicated in the default parameter file `set Output directory = 
results`), which however is not created by the installation. You can either 
change the parameter file and set the output directory to `.` or create the 
directory `results` in the location where you are running the program. 

Wolfgang, it seems that indeed the default parameter file in 9.2 still contains 
`set Output directory = results`. :(

L.


> On 5 Jun 2020, at 7:03, heena patel  wrote:
> 
> Dear all,
>  
> I had downloaded latest 9.2 version and had run 
> some tutorials successfully. When I try to run tutorial 70 it gives following 
> error. Kindly help me.
> 
> 
> TimerOutput objects finalize timed values printed to the
> screen by communicating over MPI in their destructors.
> Since an exception is currently uncaught, this
> synchronization (and subsequent output) will be skipped
> to avoid a possible deadlock.
> -
> 
> 
> 
> Exception on processing: 
> 
> 
> An error occurred in line <1360> of file 
>  in 
> function
> void dealii::ParameterHandler::print_parameters(const string&, 
> dealii::ParameterHandler::OutputStyle) const
> The violated condition was: 
> out
> Additional information: 
> An input/output error has occurred. There are a number of reasons why 
> this may be happening, both for reading and writing operations.
> 
> If this happens during an operation that tries to read data: First, you may 
> be trying to read from a file that doesn't exist or that is not readable 
> given its file permissions. Second, deal.II uses this error at times if it 
> tries to read information from a file but where the information in the file 
> does not correspond to the expected format. An example would be a truncated 
> file, or a mesh file that contains not only sections that describe the 
> vertices and cells, but also sections for additional data that deal.II does 
> not understand.
> 
> If this happens during an operation that tries to write data: you may be 
> trying to write to a file to which file or directory permissions do not allow 
> you to write. A typical example is where you specify an output file in a 
> directory that does not exist.
> 
> 
> 
> Regards,
> Heena
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/d102ed42-8257-4674-a900-1e6337af2849o%40googlegroups.com.

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


Re: [deal.II] Example not Compiling in deallii on Docker

2020-05-18 Thread luca.heltai
You are trying to compile the examples in the /usr/local directory. 

The default user in the dealii docker image is the “dealii” user, and it does 
not have write access to those directories. If you really want work inside the 
docker image, you should copy the directory of the example(s) you want to 
compile under /home/dealii and compile from there. 

However, the usual way people use the docker image is to mount a local 
directory into the image, e.g., calling 

docker run -v $HOME:$HOME -t -i dealii/dealii:latest bash

and then building your examples/programs/etc. in a local directory under your 
home folder path. In this way you use the image, without modifying its content, 
and the build results are left in your home directory (in the host computer, 
and not in the image, where the changes you make are discarded when you exit).

Best,
Luca.

> On 15 May 2020, at 11:44, Jack Urombo  wrote:
> 
> 
> 
> I have installed dealii on docker and when itry t run the examples i get the 
> error below. What am i doing wrong?
> 
> 
> 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6/CMakeFiles/CMakeTmp/testCCompiler.c
> 
>   try_compile() works only for enabled languages.  Currently these are:
> 
> C CXX
> 
>   See project() command to enable other languages.
> Call Stack (most recent call first):
>   CMakeLists.txt:38 (PROJECT)
> 
> 
> -- Check for working C compiler: /usr/bin/cc -- broken
> CMake Error at 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/cmake-3.14.4-7gmvmpryqyfj5m42vt5qj5tb27tw7un6/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:56
>  (file):
>   file failed to open for writing (No such file or directory):
> 
> 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6/CMakeFiles/CMakeError.log
> Call Stack (most recent call first):
>   CMakeLists.txt:38 (PROJECT)
> 
> 
> CMake Error at 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/cmake-3.14.4-7gmvmpryqyfj5m42vt5qj5tb27tw7un6/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60
>  (message):
>   The C compiler
> 
> "/usr/bin/cc"
> 
>   is not able to compile a simple test program.
> 
>   It fails with the following output:
> 
> 
> 
>   
> 
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:38 (PROJECT)
> 
> 
> -- Configuring incomplete, errors occurred!
> CMake Error: Cannot open file for write: 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6/CMakeCache.txt.tmp
> CMake Error: : System Error: Permission denied
> CMake Error: Unable to open cache file for save. 
> /usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6/CMakeCache.txt
> CMake Error: : System Error: Permission denied
> dealii@85f866bfa019:/usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6$
>  ^C
> dealii@85f866bfa019:/usr/local/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/dealii-9.1.1-kbq6c5p67nir5zwpx5lbevwutndfivxz/share/deal.II/examples/step-6$
>  
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/77501932-426c-43d0-8607-7fa259151b6e%40googlegroups.com.

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


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

2020-05-03 Thread luca.heltai
I’m updating my Mac, to see if I can reproduce.

Best,
Luca.

> On 3 May 2020, at 9:47, Alberto Salvadori  wrote:
> 
> 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 

Re: [deal.II] Difficulty setting manifold with Opencascade using gmsh mesh + salome STEP (or IGES) - Step-54

2020-04-09 Thread luca.heltai
That’s fanstastic!

:)

You sould put this image in the image gallery!

Luca.

> On 8 Apr 2020, at 16:29, Bruno Blais  wrote:
> 
> Dear all,
> Thank you very much for the help and support. I have managed to make it work 
> in 3D within Lethe.
> A quick image of the application of CAD mesh adaptation using multiple CADs 
> on a complex mixer :)!
> Thank  you for your help (especially you Luca :)!)
> 
> 
> 
> 
> On Sunday, 5 April 2020 12:05:17 UTC-4, Bruno Blais wrote:
> Dear Jean-Paul, what you wrote in the FAQ is very clear. If I find additional 
> elements as I play with the functionnality I will add it to the FAQ. Thanks 
> for adding this section.
> Best
> Bruno
> 
> 
> On Friday, 3 April 2020 16:11:05 UTC-4, Jean-Paul Pelteret wrote:
> Dear Bruno,
> 
> I guess that it would be best to mention this in the tutorial itself, but in 
> the mean time I wrote a segment about it in the FAQ:
> https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-ensure-that-my-refined-grid-is-correct-when-using-cad-geometry
> Please feel free to edit it as you see fit. Never having used this 
> functionality in the library before, I hope that I have correctly interpreted 
> and massages what Luca had detailed.
> 
> Best,
> Jean-Paul
> 
>> On 03 Apr 2020, at 15:55, Bruno Blais  wrote:
>> 
>> Dear Jean-Paul,
>> Do you think it should be added to the wiki page or as additional 
>> information to step-54? I have a bit on my hands, but i'd be glad to work to 
>> make the information readily available. Clearly I would not have found that 
>> out without Luca's help. 
>> Best
>> Bruno
>> 
>> 
>> On Friday, 3 April 2020 09:43:33 UTC-4, Jean-Paul Pelteret wrote:
>> Dear Bruno,
>> 
>> I’m glad that you managed to solve this issue with Luca’s aid. I think that 
>> the information and workflow that Luca gave was really valuable. Would you 
>> care to add this to the Wiki page?
>> 
>> Best,
>> Jean-Paul
>> 
>>> On 03 Apr 2020, at 06:03, Bruno Blais  wrote:
>>> 
>>> Ciao Luca,
>>> It works perfectly now even with regular GMSH triangulation (see movie). 
>>> Now I understand the difference and how to set it correctly.
>>> Thank you very much for the help :)!
>>> 
>>> 
>>> On Thursday, 2 April 2020 11:31:42 UTC-4, luca.heltai wrote:
>>> Bruno, it seems like you are attaching your faces to the *boundary* 
>>> manifold. Let me try to explain what is happening. 
>>> 
>>> In the code for step-54, there is a wire that is used to describe the 
>>> manifold of the *boundary* of the surface (a curve of dimension one 
>>> embedded in dimension three). This is generated by the wire that identifies 
>>> the boundary of the TopoDS shape of the face. The manifold attached to it 
>>> is an ArcLengthProjectionManifold, where mid points on the curve are added 
>>> by computing the distance in arc length, and taking the point in the middle 
>>> w.r.t. this length. 
>>> 
>>> In your code with more than one cell, you are not assigning *just the 
>>> boundary faces* to the wire, but *all* faces (including the one in the 
>>> middle of your surface, delimitating the two cells). Intermediate points on 
>>> those lines will be projected (correctly) on the boundary wire (that’s what 
>>> your movie shows). 
>>> 
>>> Of course any point that is in the middle of the surface does *not* belong 
>>> to the *boundary wire*, and you’ll get an exception when trying to 
>>> construct the midpoint of an *edge* that belongs to the interior of the 
>>> domain, with manifold id 2 (which corresponds to a manifold that describes 
>>> *the boundary* of your topology, not its surface). 
>>> 
>>> With two cells, the internal edge (the only edge that does not belong to 
>>> the boundary) should *not* have id 2. If you set its id to 2, the result is 
>>> that a point which is in the middle of the edge, is actually in the midlle 
>>> of the two points *when running along the curve that describes the 
>>> boundary*, hence you get the distortion you show in the movie. 
>>> 
>>> Try adding a check to the faces in which you set the manifold id to 2 only 
>>> if the face is at the boundary. 
>>> 
>>> The principle is: 
>>> 1. start from the lowest codimension objects, identify how to deform them. 
>>> In your case, cells of a Tria<2,3> are quads, that should deform as a 
>>> TopoDS_FACE. 
>>> 2. Attach your favorite manifold to the Top

Re: [deal.II] Difficulty setting manifold with Opencascade using gmsh mesh + salome STEP (or IGES) - Step-54

2020-04-02 Thread luca.heltai
Bruno, it seems like you are attaching your faces to the *boundary* manifold. 
Let me try to explain what is happening. 

In the code for step-54, there is a wire that is used to describe the manifold 
of the *boundary* of the surface (a curve of dimension one embedded in 
dimension three). This is generated by the wire that identifies the boundary of 
the TopoDS shape of the face. The manifold attached to it is an 
ArcLengthProjectionManifold, where mid points on the curve are added by 
computing the distance in arc length, and taking the point in the middle w.r.t. 
this length.

In your code with more than one cell, you are not assigning *just the boundary 
faces* to the wire, but *all* faces (including the one in the middle of your 
surface, delimitating the two cells). Intermediate points on those lines will 
be projected (correctly) on the boundary wire (that’s what your movie shows). 

Of course any point that is in the middle of the surface does *not* belong to 
the *boundary wire*, and you’ll get an exception when trying to construct the 
midpoint of an *edge* that belongs to the interior of the domain, with manifold 
id 2 (which corresponds to a manifold that describes *the boundary* of your 
topology, not its surface).

With two cells, the internal edge (the only edge that does not belong to the 
boundary) should *not* have id 2. If you set its id to 2, the result is that a 
point which is in the middle of the edge, is actually in the midlle of the two 
points *when running along the curve that describes the boundary*, hence you 
get the distortion you show in the movie. 

Try adding a check to the faces in which you set the manifold id to 2 only if 
the face is at the boundary.

The principle is: 
1. start from the lowest codimension objects, identify how to deform them. In 
your case, cells of a Tria<2,3> are quads, that should deform as a TopoDS_FACE. 
2. Attach your favorite manifold to the TopoDS_Face (I’d personally only use 
NormalToMeshProjectionManifold) using cell->set_all_manifold_ids(manifold_id) 
(Notice the use of set_all_manifold_ids, and **not** set_manifold_id: you want 
all children of these objects to belong to the same manifold, in particular you 
want all faces that are internal, i.e., that are shared between two obects with 
the same manifold id, to inherit the same manifold id). 
3. Go one codimension lower: in your case, curves (for 3d meshes, surfaces). 
Follow the same rule as above, setting all_manifold_ids on faces that you know 
should follow a known codimension one geometry (a known TopoDS_EDGE, or 
TopoDS_WIRE). In this case I’d only use ArcLengthProjectionManifold objects, 
attached to the wires that identify your geometry.

Doing things in this order guarantees that internal edges get the correct 
manifold id, which, in your case, is not happening.

Best,
Luca.



> On 1 Apr 2020, at 17:32, Bruno Blais  wrote:
> 
> So my investigation on this issue continues...
> It seems the core of my issues stem from using a non-trivial mesh with more 
> than one cell as a starting point.
> if I start with a 2 cell spacedim=2 dim=3 mesh such as:
> 
> 
> 
> 
> 
> 
> Which is identical to the second step of the adaptation. I get an aberrant 
> result (see attached out_wrong.mp4).
> 
> 
> 
> I also get issues when I try to apply the manifold on a starting msh made 
> with GMSH that has a similar topology such as in the following image:
> 
> 
> 
> 
> 
> In this case, I get an error about a point not being on the manifold (when it 
> clearly is)...
> 
> So I must admit I am at loss here. Right now the code I use to set the 
> manifold is :
> 
> for (const auto  : tria.active_cell_iterators())
>   {
> 
> cell->set_manifold_id(1);
> 
> for (const auto  : cell->face_iterators())
> 
>   {
> 
>   face->set_manifold_id(2);
> 
>   }
> 
>   }
> 
> If anybody has any experience with using the OpenCascade manifold using 
> initial meshes that have more than 1 cell, I would greatly appreciate advices 
> :)!.
> 
> Best
> 
> Bruno
> 
> 
> 
> 
> On Wednesday, April 1, 2020 at 9:38:27 AM UTC-4, Bruno Blais wrote:
> 
> So it seems part of my problem relate to the topology I was trying to adapt 
> OR to the staring complex mesh I was using.
> I have managed to make it work starting with a trivial mesh and using a more 
> simple IGES CAD. I will work on complexifying it from there. I will try to 
> keep the information here as it seems that feature has not been used 
> extensively :)!.
> What I have working now is this animation.
> 
> On Tuesday, March 31, 2020 at 9:19:23 AM UTC-4, Bruno Blais wrote:
> Dear all,
> I hope you are well in these uncertain times.
> 
> I have been trying to use the OpenCASCADE library to set-up my manifolds. The 
> goal of this is to be able to do CFD simulations in complex geometry, but use 
> an initial very coarse mesh made with GMSH and use the dynamics mesh 
> adaptation to adapt the mesh while having the adaptation be 

Re: [deal.II] Deal.II on Docker

2020-03-14 Thread luca.heltai
By the way, the examples in the docker image are located under 

$(spack location -i dealii)/share/deal.II/examples

i.e., you can go to 

cd $(spack location -i dealii)/share/deal.II/examples

and from there, compile and run. Notice that they are not pre-compiled (they 
would just take up download bandwidth).

Best,
Luca

> On 13 Mar 2020, at 2:47, Robert Kopp  wrote:
> 
> After some false starts, I was able to use deal.II on Ubuntu 18.04 by 
> installing it from the backport PPA. It occurred to me that I might want to 
> use it during a Windows session, and since Windows does not support it 
> natively, the use of a pre-built Docker container came to mind.
> 
> The most likely candidate was dealii/dealii:latest. I was disappointed to 
> note the the "examples" weren't there (or, at least, I can't find them) so I 
> downloaded these from Github. As in the case of my abortive attempts on bare 
> metal, I received such messages as the following:
> 
> dealii@5ee4b768bb50:~/dealii/examples/step-5$ cmake .
> CMake Error at CMakeLists.txt:30 (MESSAGE):  
> 
>   *** Could not locate a (sufficiently recent) version of deal.II.  ***  
> 
>   You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to cmake
> 
>   or set an environment variable "DEAL_II_DIR" that contains this path.
> 
> I was hoping that it would be a complete kit, but upbeat_albattani had let me 
> down. Can anyone suggest a good way (reference, etc.) to get up to speed on 
> this container? I can do everything I need to do on Linux, but there would be 
> some advantage to being able to use it on Windows as well. 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/e007aee1-2057-4541-9eed-92c9bf5b0cf6%40googlegroups.com.

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


Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-26 Thread luca.heltai
Did you try the pre-compiled deal.II package? 

Both 

dealii-9.1.1-clang-9.0.0.dmg

and 

dealii-9.1.1-catalina-haswell-ro.dmg.zip


from https://github.com/dealii/dealii/releases/tag/v9.1.1

should work.

Luca.

> On 25 Jan 2020, at 21:29, Ihar Suvorau  wrote:
> 
> 
> Software:
>   • macOS Catalina 10.15.2
>   • deal.ii 9.1.1
>   • PETSc 3.12
> Question:
> 
> Hey, does somebody know a potential reason for this message while running a 
> well-compiled step-40 program:
> 
> ihar@husky build3 % ./step-40
> 
> 
> Running with PETSc on 1 MPI rank(s)...
> 
> Cycle 0:
> 
>   Number of active cells:   1024
> 
>   Number of degrees of freedom: 4225
> 
> 
> 
> ---
> 
> 
> An error occurred in line <543> of file 
>  in function
> 
>void dealii::PETScWrappers::PreconditionBoomerAMG::initialize(const 
> dealii::PETScWrappers::MatrixBase &, const 
> dealii::PETScWrappers::PreconditionBoomerAMG::AdditionalData &)
> 
> The violated condition was:
> 
>false
> 
> Additional information:
> 
>Your PETSc installation does not include a copy of the hypre package 
> necessary for this preconditioner.
> 
> 
> 
> Stacktrace:
> 
> ---
> 
> #0  2   libdeal_II.g.9.1.1.dylib0x00011188b86f 
> _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE
>  + 95: 2   libdeal_II.g.9.1.1.dylib0x00011188b86f 
> _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE
> 
> #1  3   step-40 0x00010643881a 
> _ZN6Step4014LaplaceProblemILi2EE5solveEv + 266: 3   step-40   
>   0x00010643881a _ZN6Step4014LaplaceProblemILi2EE5solveEv
> 
> #2  4   step-40 0x00010642e633 
> _ZN6Step4014LaplaceProblemILi2EE3runEv + 451: 4   step-40 
> 0x00010642e633 _ZN6Step4014LaplaceProblemILi2EE3runEv
> 
> #3  5   step-40 0x00010642e23a main + 106: 5  
>  step-40 0x00010642e23a main
> 
> #4  6   libdyld.dylib   0x7fff6350f7fd start + 1: 6   
> libdyld.dylib   0x7fff6350f7fd start
> 
> 
> 
> 
> 
> [husky:92536] *** Process received signal ***
> 
> [husky:92536] Signal: Abort trap: 6 (6)
> 
> [husky:92536] Signal code:  (0)
> 
> [husky:92536] [ 0] 0   libsystem_platform.dylib0x7fff6370842d 
> _sigtramp + 29
> 
> [husky:92536] [ 1] 0   ??? 0x7ffee97d8838 
> 0x0 + 140732815738936
> 
> [husky:92536] [ 2] 0   libsystem_c.dylib   0x7fff635dda1c 
> abort + 120
> 
> [husky:92536] [ 3] 0   libdeal_II.g.9.1.1.dylib0x0001119ec74d 
> _ZN6dealii18deal_II_exceptions9internals5abortERKNS_13ExceptionBaseE + 205
> 
> [husky:92536] [ 4] 0   libdeal_II.g.9.1.1.dylib0x00010de0f63f 
> _ZN6dealii18deal_II_exceptions9internals20issue_error_noreturnINS_18StandardExceptions10ExcMessageEEEvNS1_17ExceptionHandlingEPKciS7_S7_S7_T_
>  + 223
> 
> [husky:92536] [ 5] 0   libdeal_II.g.9.1.1.dylib0x00011188b86f 
> _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE
>  + 95
> 
> [husky:92536] [ 6] 0   step-40 0x00010643881a 
> _ZN6Step4014LaplaceProblemILi2EE5solveEv + 266
> 
> [husky:92536] [ 7] 0   step-40 0x00010642e633 
> _ZN6Step4014LaplaceProblemILi2EE3runEv + 451
> 
> [husky:92536] [ 8] 0   step-40 0x00010642e23a 
> main + 106
> 
> [husky:92536] [ 9] 0   libdyld.dylib   0x7fff6350f7fd 
> start + 1
> 
> [husky:92536] *** End of error message ***
> 
> 
> 
> The thing is that I've compiled PETSC with the "--download-hypre=1" option 
> and there is a compiled library with the name "libHYPRE-2.18.2.dylib" 
> alongside "libpetsc.3.12.3.dylib" and others in the folder for my 
> architecture "arch-darwin-c-debug". Environment variables "PETSC_DIR" and 
> "PETSC_ARCH" all point to the correct folder like in the instruction at 
> https://www.dealii.org/developer/external-libs/petsc.html. 
> 
> Did I miss something?
> 
> I'm trying to install all the packages with "dealii/candi", but PETSc 
> compilation fails there also, but for a different reason though 
> (https://github.com/dealii/candi/issues/133).
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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 

Re: [deal.II] number of cells sharing a line

2020-01-24 Thread luca.heltai
Nicola, 

I would simply do this by 

std::mapline(0)), unsigned int> line_count;

for(const auto : tria.active_cell_iterators()) {
for(unsigned int i=0; i< GeometryInfo::lines_per_cell; ++i) {
const it = line_count.find(cell->line(i));
if(it != line_count.end())
*it.second++;
else
line_count[cell->line(i)] = 1;
}

We don’t have access to that information within the iterator.

L.


> On 24 Jan 2020, at 8:39, Nicola Giuliani  wrote:
> 
> Dear all,
> 
> In my code I need to reconstruct the number of cells sharing an edge. 
> 
> Is there a way to reconstruct this number locally? In principle I would need 
> something like to cell->line(1)->n_sharing_cells()?
> 
> Bests,
> Nicola
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/8f2dca8c-b6e3-4a33-b203-cea32e5fb8a4%40googlegroups.com.

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


Re: [deal.II] problem with a projection using SphericalManifold

2020-01-22 Thread luca.heltai
Nicola, 

I think you are hitting a periodicity issue here. 

The points with angle 7/4 pi and 5/4 pi are at a distance (from pi/4) of 6/4 pi 
= -pi/2 (this is the shorter distance, and this is what is used in the code), 
and pi = -pi (this could be either -pi or pi, and it is in fact not well 
defined to use points at exactly T/2 distance where T is the periodicity, since 
either T/2 or -T/2 are the same point) from 1/4 pi. 

With your weights, you may get -pi/4 -pi/4 + pi/4 = - pi/4 or -pi/4 + pi/4 + 
pi/4 = pi/4 (which is what you observe). The only solution to this is to make 
sure that the initial grid does not contain a single cell, with a periodic 
boundary associated to the it. This produces a manifold which is not well 
defined, and does not behave as one would expect.

L.

> On 21 Jan 2020, at 16:09, Nicola Giuliani  wrote:
> 
> Dear all,
> 
> I have the following snippet of code.
> 
> 
>   const unsigned int dim = 2;
>   double factor = 1./std::sqrt(dim);
> 
>   Point p1test{factor, -factor};
>   Point p2test{factor, factor};
>   Point p3test{-factor, -factor};
> 
>   std::vector > surrounding_points;
>   surrounding_points.push_back(p1test);
>   surrounding_points.push_back(p2test);
>   surrounding_points.push_back(p3test);
> 
>   std::vector surrounding_weights(3);
>   surrounding_weights[0] = 0.5;
>   surrounding_weights[1] = 0.25;
>   surrounding_weights[2] = 0.25;  
> 
>   auto new_vertex = spherical_manifold.get_new_point(
> ArrayView>(_points[0],
>surrounding_points.size()),
> ArrayView(_weights[0],
>   surrounding_weights.size()));
> 
> I would expect the new point to coincide with the original one, but instead 
> it collapses on the second. Looking into the code of spherical manifold the 
> associated angles are: 7/4 pi, 1/4 pi and 5/4 pi. From this representation I 
> would expect the projected point to be at 5/4 pi. 
> 
> I really don't understand this behavior of SphericalManifold, do you have an 
> explanation?
> 
> Bests,
> Nicola
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/ca22bb00-481d-49ae-aa38-1572415d8340%40googlegroups.com.

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


Re: [deal.II] Parallelizing step-33 with MPI

2019-12-22 Thread luca.heltai
Dear Ellen, 

you may want to compare with this:

https://github.com/luca-heltai/dealii/pull/91/files#diff-acfb3c7b43e4935be016fda6ebdc5881

It is a parallel version of step-38, that never got into the library, written 
by one of our students, during a deal.II workshop in Trieste (held by Timo and 
myself).

Best,
Luca.

> On 21 Dec 2019, at 20:52, Ellen M. Price  wrote:
> 
> Thanks for the feedback. This problem was me writing to the wrong matrix 
> elements, and I'm so close to having a working prototype of this code. I 
> think the (hopefully last) bug is in this section of code:
> 
> dof_handler.clear();
> dof_handler.distribute_dofs(fe);
> locally_owned_dofs = dof_handler.locally_owned_dofs();
> DoFTools::extract_locally_relevant_dofs(dof_handler, locally_relevant_dofs);
> 
> DynamicSparsityPattern dsp(locally_relevant_dofs);
> DoFTools::make_sparsity_pattern(dof_handler, dsp);
> SparsityTools::distribute_sparsity_pattern(
> dsp, dof_handler.n_locally_owned_dofs_per_processor(),
> MPI_COMM_WORLD, locally_relevant_dofs);
> 
> system_matrix.reinit(locally_owned_dofs, locally_owned_dofs, 
> dsp, MPI_COMM_WORLD);
> 
> current_solution.reinit(locally_owned_dofs, 
> locally_relevant_dofs, MPI_COMM_WORLD);
> right_hand_side.reinit(locally_owned_dofs, MPI_COMM_WORLD);
> 
> I get a runtime exception from the TrilinosWrappers module when I call 
> SparseMatrix::add() on more than one processor, and I suspect that I've set 
> up the sparsity pattern incorrectly (maybe the system_matrix doesn't know how 
> to distribute entries, or it gets the wrong indices?). Is there anything 
> obviously wrong with what I've done here? There are a lot of notes in the 
> doxygen about setting up the Trilinos sparsity pattern, but nothing I've 
> tried (like calling compress() after setting up the matrix) works.
> 
> Ellen
> 
> 
> On Friday, December 20, 2019 at 10:24:23 PM UTC-6, Wolfgang Bangerth wrote:
> On 12/20/19 6:42 PM, Ellen M. Price wrote: 
> > I did eventually solve this problem, but I ran into another one. I think 
> > I'm 
> > close, I just need a little guidance. The problems occur in assembling the 
> > system. I've checked the right-hand side vector and it has some odd 
> > features. 
> > I'm running the "slide" problem, just like step-33 does. I suppose my 
> > question 
> > is, how should the system assembly routine be changed to accommodate 
> > parallelization? All I did was add an if statement to check whether a cell 
> > is 
> > locally owned before computing on it. Conceptually, what else needs to 
> > change? 
> 
> Ellen, 
> not actually very much: You need a non-ghosted (writable) vector, which 
> apparently you have, for your right hand side. Then you loop over the locally 
> owned cells (which you do), and the only other thing you have to do is to 
> call 
> compress() at the end of the assembly. 
> 
> There are many other things one can do to test whether things work correctly, 
> but "has some odd features" is not enough of a hint to allow for more 
> concrete 
> suggestions :-) 
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/9b404d3e-cd78-4290-b4d0-11b36edcc692%40googlegroups.com.

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


Re: [deal.II] get_dof_indices() only works on active cells - blocks vector

2019-12-09 Thread luca.heltai
Dear Juan,

The logic you should use is: when your neighbour is finer, you should not 
assemble the full face term from the coarse neighbour. Instead, you have to 
assemble your DG terms using a FESubfaceValues initialized with the correct 
arguments on the coarse face, to match *each* of the fine FEFaceValues. This 
logic is tricky to get right.

May I suggest that you use the MeshWorker::mesh_loop function?

That function takes care of these issues for you, by calling a user provided 
assembly function for cells, faces and boundary faces, and passing to that 
function the right arguments with which you can initialise your FEFaceValues 
and FESubFaceValues.

You can see it in action in step-12 (development version of deal.II), or in the 
tests/meshworker/mesh_loop_*.cc files and tests/meshworker/scratch_data_*.cc

Best,
Luca.

> On 9 Dec 2019, at 4:55, Juan Felipe Giraldo  wrote:
> 
> Dear David,
>  
> Thank you for your quick reply. 
> Yes, I need the neighbour information of each cell to compute the boundary 
> integration in the DG formulation. Therefore, I get the neighbouring cell in 
> the loop of the active cell by using "const auto neighbor = 
> cell->neighbor(face_n)";  (similar to step 30). 
> I am quite sure that the problem is what you are describing, thus it occurs 
> only when I use the adaptative refinement. 
> 
> The problem appears here:
> #0  ./FEM-DGdeal: dealii::DoFCellAccessor, 
> false>::get_dof_indices(std::vector int> >&) const
> #1  ./FEM-DGdeal: FEMwDG<2>::assemble_system(unsigned int)
> #2  ./FEM-DGdeal: FEMwDG<2>::run(unsigned int, unsigned int, unsigned int, 
> unsigned int)
> #3  ./FEM-DGdeal: main
> 
> And the part of the code where I call the get_dof_indices is this:
> 
> void FEMwDG::assemble_system(const unsigned int typecase)
> {
>   const unsigned int dofs_per_cell = dof_handler.get_fe().dofs_per_cell;
>   std::vector local_dof_indices(dofs_per_cell);
>   std::vector 
> neighbor_dof_indices(dofs_per_cell);
>   const UpdateFlags update_flags = update_values | update_gradients |
>update_quadrature_points |
>update_JxW_values;
>   const UpdateFlags face_update_flags =  update_values | 
> update_quadrature_points | update_JxW_values |
>  update_normal_vectors;
>   const UpdateFlags neighbor_face_update_flags = update_values;
> 
>   FEValues fe_values(mapping, fe, quadrature, update_flags);
>   FEFaceValues fe_face_values(mapping, fe, face_quadrature, 
> face_update_flags);
>   FESubfaceValues fe_subface_values(mapping,  fe, face_quadrature, 
> face_update_flags);
>   FEFaceValues  fe_face_neighbor(mapping,  fe, 
> face_quadrature,neighbor_face_update_flags);
> 
>   FullMatrix ui_vi_matrix(dofs_per_cell, dofs_per_cell); //matrix 
> dominio
>   FullMatrix ue_vi_matrix(dofs_per_cell, dofs_per_cell);
>   FullMatrix ui_ve_matrix(dofs_per_cell, dofs_per_cell);
>   FullMatrix ue_ve_matrix(dofs_per_cell, dofs_per_cell);
> 
>   Vector cell_vector(dofs_per_cell);
>   const FEValuesExtractors::Scalar verror(0);
>   const FEValuesExtractors::Scalar variable(1);
> 
>   for (const auto  : dof_handler.active_cell_iterators())
> {
>   fe_values.reinit(cell);   ui_vi_matrix = 0;  cell_vector= 0;
>   //--DOMAIN 
> INTEGRATOR--
>  adv.assemble_cell_term(fe_values, ui_vi_matrix, cell_vector, 
> verror, variable,cell, typecase);
>  cell->get_dof_indices(local_dof_indices);
> 
> for (unsigned int face_n = 0;  face_n < 
> GeometryInfo::faces_per_cell;  ++face_n)
>   {
> //-FACE AT THE 
> EXTERNAL 
> BOUNDARY-
> const auto face = cell->face(face_n);
>  if (face->at_boundary())
>{
>  fe_face_values.reinit(cell, face_n);
>  adv.assemble_boundary_term(fe_face_values, 
> ui_vi_matrix, cell_vector, verror, variable);
>}
> //-FACE AT THE 
> INTERNAL 
> BOUNDARY-
>else
>{
>   const auto neighbor = cell->neighbor(face_n);
>  if ((dim > 1) && (cell->index() < neighbor->index()))
>   {
>  const unsigned int neighbor2 
> =cell->neighbor_face_no(face_n);
>  ue_vi_matrix = 0; ui_ve_matrix = 0;  ue_ve_matrix = 
> 0;
> 
>  fe_face_values.reinit(cell, 

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

2019-12-06 Thread luca.heltai
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 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 co

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

2019-12-06 Thread luca.heltai
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$ 
> > 
> > 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/s

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

2019-12-06 Thread luca.heltai
Alberto, 

do you have 10.15.1, or 10.15? Did you also update XCode? 

I’m currently building everything from scratch for 10.15.1, with XCode 11.2.1. 
This may be the issue.

I hope I’ll have a new package by tonight.

Best,
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$ 
> > 
> > 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.ap

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

2019-12-03 Thread luca.heltai
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
> 
> There is a package for Mac OS Catalina. In Catalina, permissions are much 
> more restrictive, and you’ll have to explicitly enable the application to run 
> (the first time), by right clicking on it, and selecting “open” (which pops 
> up a dialog asking if you are sure about opening the app, and giving you some 
> instruction on how to allow deal.II to run on your system.
> 
> L.
> 
> 
> 
> > On 21 Oct 2019, at 13:39, Ester Comellas  wrote:
> > 
> > Hi,
> > 
> > I'm pretty new to macOS and updated the system when prompted to do so, and 
> > several software stopped working! Among them, deal.ii. I tried reinstalling 
> > CMake, Xcode and deal.ii, but can't get it to work. Xcode and CMake seem to 
> > be working fine. Deal.ii appears to be installed correctly but, when I try 
> > to open it, a system window pops up saying deal.II.app couldn't be opened. 
> > Any ideas on what may be wrong and how I can fix this? I'm on macOS 
> > Catalina Version 10.15.
> > 
> > Thanks,
> > Ester
> > 
> > -- 
> > The deal.II project is located at http://www.dealii.org/
> > For mailing list/forum options, see 
> > https://groups.google.com/d/forum/dealii?hl=en
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "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/e1edaedd-f3b4-44ef-9543-f5a52b8d2972%40googlegroups.com.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/CB27B768-395C-4148-A540-C2886D241A06%40gmail.com.
> 
> 
> 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/CABcATpd7eSGU6Fg%2Bx6RSGMUjdDNW32d-FCKRC%3DChxLqmqqzCuA%40mail.gmail.com.

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


Re: [deal.II] Associating a MappingManifold with a Manifold

2019-11-16 Thread luca.heltai
  
> CylindricalManifold<2> cylman(0);
> triangulation.set_manifold(numbers::flat_manifold_id, cylman);

The flat_manifold_id is usually reserved for the flat manifold, and yours is 
not a flat manifold. Setting the flat manifold to the cylindrical manifold 
implies 

You should set the manifold ids of the cells that you want to deform. 

What triangulation are you using? if the Triangulation you are using contains 
the axis, then the CylindricalManifold is not well posed in the cells that 
touch or contain the axis, since the cylindrical transformation is not well 
posed there.

> QGauss<2> quadrature_formula(fe.degree + 1);
> MappingManifold<2> mapping;
> FEValues<2> fe_values(mapping, fe, quadrature_formula,  update_values | 
> update_gradients | update_JxW_values);
> 
> The fe_values object seems to have nonsense inside.

Have you called fe_values.reinit(cell)?

> All the shape_gradients are nans and the JxW values are zeros. I also tried 
> to check whether the internaldata of the MappingManifold are correct, but 
> they seem to not be initialized.

The internal data is initialized by calls to fe_values.reinit(cell), and it is 
*not* owned by the mapping, but by the fevalues object. These are not thought 
to be used directly by the user.

> I guess I am not initializing something correctly, but I can't find what. 

Take a look at the way this is used in the tests directory: 

tests/mappings/mapping_manifold_*.cc

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


Re: [deal.II] Associating a MappingManifold with a Manifold

2019-11-12 Thread luca.heltai
You don’t need to do anything special. Just create a MappingManifold, and pass 
it where required. The manifold that is used is the one associated to the 
triangulation. You don’t need to associate it to the Mapping, since the mapping 
is used on *all* objects of the triangulation, and it will know how to 
construct the data from the underlying manifold objects.

Best,
Luca.

> On 12 Nov 2019, at 15:37, Andreas Kyritsakis  wrote:
> 
> 
> Hi,
> 
> I want to use a real-to-reference-cell mapping which corresponds to 
> cylindrical symmetry in 2D. In other words, the integration jacobian and the 
> shape function gradients should contain the scale factor of the cylindrical 
> coordinates. I tried to do it with the following code:
> 
>   QGauss<2> quadrature_formula(fe.degree + 1);
>   CylindricalManifold<2> cyl_man(0);
>   MappingManifold<2> mapping;
>   auto  = dynamic_cast< MappingManifold<2>::InternalData 
> &>(*mapping.get_data(update_values | update_gradients | update_JxW_values, 
> quadrature_formula));
>   data.manifold = _man;
> 
> but it does not seem to work. I am afraid that this is not the correct way to 
> associate the Manifold object  with the Mapping object, but I can't figure 
> out how it should be done.
> 
> Can anyone help?
> 
> Best regards,
> Andreas
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/9d0b3e81-6559-4dc9-bc89-0f4a74ec4921%40googlegroups.com.

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


Re: [deal.II] Docker MPI

2019-10-25 Thread luca.heltai
You can do 

export PATH=$(spack location -i mpich)/bin:$PATH

to prepend the path of mpich to your PATH. This is not done automatically. 
Alternatively, you could also run, as root: 

cd /usr/local
spack view add . mpich

which aliases all mpi commands to /usr/local/bin

I usually do this in a custom docker image, derived from the official deal.II 
image, which I then upload to my personal docker hub, and use for my CI needs.

Best,
Luca.

---
FROM dealii/dealii:v9.1.1-gcc-mpi-fulldepsspack-debugrelease

MAINTAINER luca.hel...@gmail.com

USER   root
RUNspack install googletest ninja \
   && spack clean -a \
   && cd /usr/local && spack view add . googletest ninja mpich

RUNchmod 777 /home/$USER

USER   $USER



> On 25 Oct 2019, at 4:02, Reza Rastak  wrote:
> 
> Hi,
> 
> I have a related issue regarding the docker image. I can see `mpich` when I 
> type `spack find`. However, I don't have access to executable programs 
> `mpirun` or `mpiexec`.
> 
> >> mpirun
> bash: mpirun: command not found
> 
> when I try to load the module I see the following error messages.
> 
> >> spack load mpich
> ==> This command requires spack's shell integration.
>   
>   To initialize spack's shell commands:
>   
>   # for bash and zsh
>   . /usr/local/share/spack/setup-env.sh
>   
>   # for csh and tcsh
>   setenv SPACK_ROOT /usr/local
>   source /usr/local/share/spack/setup-env.csh
>   
>   This exposes a 'spack' shell function, which you can use like
>   $ spack load package-foo
>   
>   Running the Spack executable directly (for example, invoking
>   ./bin/spack) will bypass the shell function and print this
>   placeholder message, even if you have sourced one of the above
>   shell integration scripts.
> 
> >> . /usr/local/share/spack/setup-env.sh
> >> spack load mpich
> bash: module: command not found
> 
> Does anyone know how I can access `mpirun`?
> 
> Thank you,
> 
> Reza
> 
> 
> 
> On Tuesday, October 22, 2019 at 5:18:22 AM UTC-7, Bruno Turcksin wrote:
> Doug,
> 
> You are using an image build using spack so everything is installed using 
> spack instead of the package manager. If you type `spack find` inside a 
> container, you will see that mpich is installed.
> 
> Best,
> 
> Bruno
> 
> On Monday, October 21, 2019 at 9:53:36 PM UTC-4, Doug Shi-Dong wrote:
> Hello everyone,
> 
> I would like to use Travis CI to test pull requests, and I am currently 
> following the steps described in 
> https://github.com/dealii/dealii/wiki/Docker-Images
> 
> Except I am using the following Docker image: 
> dealii/dealii:v9.1.1-gcc-mpi-fulldepsspack-debugrelease
> 
> It seems that this Docker imagine does not contain an MPI package in its 
> installation. Here is a log of my Travis CI build
> 
> https://travis-ci.org/dougshidong/PHiLiP/builds/600536273
> 
> The command apt search mpi shows that no packages such as openmpi or mpich is 
> available. However, oddly enough, DEAL_II_WITH_MPI is ON, when my CMake 
> checks for it.
> 
> If no MPI is available, how do I compile the code within this Docker 
> container?
> 
> Best regards,
> 
> Doug
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/aa77f722-f3cb-4ae8-a46c-7c6e815e0338%40googlegroups.com.

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


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

2019-10-25 Thread luca.heltai
Dear Ester,

please take a look at the release page:

https://github.com/dealii/dealii/releases/tag/v9.1.1

There is a package for Mac OS Catalina. In Catalina, permissions are much more 
restrictive, and you’ll have to explicitly enable the application to run (the 
first time), by right clicking on it, and selecting “open” (which pops up a 
dialog asking if you are sure about opening the app, and giving you some 
instruction on how to allow deal.II to run on your system.

L.



> On 21 Oct 2019, at 13:39, Ester Comellas  wrote:
> 
> Hi,
> 
> I'm pretty new to macOS and updated the system when prompted to do so, and 
> several software stopped working! Among them, deal.ii. I tried reinstalling 
> CMake, Xcode and deal.ii, but can't get it to work. Xcode and CMake seem to 
> be working fine. Deal.ii appears to be installed correctly but, when I try to 
> open it, a system window pops up saying deal.II.app couldn't be opened. Any 
> ideas on what may be wrong and how I can fix this? I'm on macOS Catalina 
> Version 10.15.
> 
> Thanks,
> Ester
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/e1edaedd-f3b4-44ef-9543-f5a52b8d2972%40googlegroups.com.

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


Re: [deal.II] Convergence rate

2019-10-10 Thread luca.heltai
Dear Felix, 

by any chance, did you take a look at step 10?

https://www.dealii.org/current/doxygen/deal.II/step_10.html

This step explains a little bit what to do when you want to solve on curved 
domains with high order finite elements. In particular, you need to ensure that 
the mapping you are using (from the reference element to the current element) 
is at least of the same order of your finite element method, if you want to 
achieve the correct convergence rates. In your case, you are using a MappingQ1 
(the default mapping, if you don’t specify anything). With that, you won’t go 
beyond 2nd order in L2. If you use MappingQ2, you should see again the optimal 
convergence rates.

Best,
Luca.

> On 10 Oct 2019, at 14:11, Félix Bunel  wrote:
> 
> Thanks for your answer !
> 
> I'm working in 2D on a disk !
> 
> This is my mesh on the 4 cycle of refinement (which I never use in practice 
> because it's not refined enough for what I want to do).
> 
> 
> 
> I don't think I have a mapping object...
> What i do to initalize my system on phi is :
> //On génère le dofhandler
> phi_dof_handler.distribute_dofs (phi_fe);
> 
> //On génère les conditions aux bords
> phi_constraints.clear();
> DoFTools::make_hanging_node_constraints(phi_dof_handler, phi_constraints);
> VectorTools::interpolate_boundary_values(phi_dof_handler,
>  0,
>  ZeroFunction<2>(1),
>  phi_constraints
> );
> 
> //On créer le sparsity pattern
> DynamicSparsityPattern dsp(phi_dof_handler.n_dofs());
> DoFTools::make_sparsity_pattern (phi_dof_handler, dsp);
> phi_sparsity_pattern.copy_from(dsp);
> 
> //On resize les objets à la bonne taille
> phi_system_matrix.reinit (phi_sparsity_pattern);
> phi_solution.reinit (phi_dof_handler.n_dofs());
> phi_old_solution.reinit (phi_dof_handler.n_dofs());
> phi_system_rhs.reinit (phi_dof_handler.n_dofs());
> 
> //On affiche les infos intéressantes
> std::cout << YELLOW << " Nombre de degrés de liberté pour les angles 
> : " 
>   << RESET  << WHITE  << phi_dof_handler.n_dofs() << RESET
>   << std::endl;
> 
> 
> 
> Le jeudi 10 octobre 2019 14:00:23 UTC+2, Bruno Blais a écrit :
> A quick question, since you are working on a sphere, are you specifying a 
> mapping of the same order as your phi?
> 
> On Wednesday, 9 October 2019 08:57:45 UTC-4, Félix Bunel wrote:
> Hello everyone.
> 
> I'm having some trouble to understand the convergence rate i'm observing in 
> my code.
> 
> Here is what i'm solving :
> 
> - I'm in 2D on a round mesh.
> - I'm solving a simple Poisson equation on this mesh for a variable named Phi 
> the solution is known for this and is 1-x^2-y^2
> - With this solution phi I'm then solving a Stokes equation that has special 
> terms that depends on phi.
> 
> For the stokes problem i'm using the usual mixed fe element as such :
> stokes_fe(FE_Q<2>(2), 2,
>   FE_Q<2>(1), 1),
> So second order for the speeds and first order for the pressure (just like in 
> the boussinesq problem from the tutorials.
> 
> For the poisson/phi problem, i'm using FE_Q<2>  also
> initialized as such :
> phi_fe (2),
> So second order.
> 
> For a special case, I have a known solution which is u=v=0 and p of the form 
> 1-x^2-y^2 (just like phi)
> And i have solved this on multiple refinement cycle which gives me different 
> number of dofs and cellsize.
> 
> 
> The thing is, when I plot the error as a function of the maximum cell 
> diameter, I get a quadratic convergence rate for the speed, and a linear rate 
> for P and phi.
> What surprises me is that I don't have a quadratic convergence rate for my 
> poisson/\phi problem even though I used 
> phi_fe (2),
> 
> My norm is the L2 norm which is simply sqrt(sum(error**2))). I'm computing it 
> with python after exporting the solution as a gpl file.
> Here are the graphs :
> 
> 
> 
> I have also tried 
> phi_fe (1),
> 
> But in this case I don't even have convergence for the speed.
> 
> 
> 
> In my integration part, I have always used 
> QGauss<2>  quadrature_formula(4);
> which is equal to degree+2.
> 
> So here are my questions :
> 
> 1- Is this convergence rate the one i'm expecting for a poisson equation (phi 
> problem) ?
> 
> 2- If no, any idea why I don't have the correct convergence rate ?
> 
> 3- In the tutorial step 31, a degree of 2 is used for the temperature (which 
> is very similar to my phi), is there some reason for that choice (just like 
> using degree+1 for the speed and degree for the pressure in a stokes 
> problem...)
> 
> Thanks in advance.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 

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

2019-09-11 Thread luca.heltai
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.


[deal.II] 4 PhD Positions @ SISSA, Trieste

2019-08-09 Thread luca.heltai
Dear All,

I would like to  bring at your attention that the deadline to apply for a Phd 
position in Mathematical Analysis, Modelling and Applications at SISSA, Scuola 
Internazionale Superiore di Studi Avanzati Trieste, Italy is August 22nd, 2019 
at noon (Rome time).
Applied mathematics activities (numerical analysis, computational mechanics) 
are carried out within SISSA mathLab: mathlab.sissa.it 

There are 4 Phd grants available.

Info about Phd programme: 
https://www.math.sissa.it/content/mathematical-analysis-modelling-and-applications-0
(Admission exams on September 10-11, 2019)

To apply: 
https://www.sissa.it/it/bandi/concorso-lammissione-ai-corsi-di-phd-della-sissa-lanno-accademico-201920-announcements

Best,
Luca.

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


[deal.II] Postdoc Position (deal.II related), International School for Advanced Studies, Trieste, Italy

2019-08-05 Thread luca.heltai
Dear all, 

I’d like to advertise an opening for a Postdoctoral position (18 months) in my 
group, to work with and on deal.II. The deadline is pretty tight… please send 
me a private message if you are interested. 

Luca.

---

Title of the position: Adaptive methods for solving multi-physics
problems in nanoelectronic devices.

The International School for Advanced Studies, Trieste, has an opening
in the applied mathematics laboratory group (mathLab) for a
Postdoctoral Scholar.

The candidate will work on
- Modeling and numerical simulation of nanometric electronic devices
- Modeling of electrical properties of materials, including structural
  defects and interfaces, providing a link between ab-initio
  simulation software and traditional technological CAD software used
  in the semiconductor industry.
- Adaptive methods for the numerical simulation of the potential /
  temperature of the device and of the charge continuity and
  drift-diffusion equations.

The project is developed in close contact with a software company
working in the field of semiconductor device modeling.

Additional information:

https://www.sissa.it/bandi/selezione-pubblica-titoli-conferimento-di-n-1-assegno-di-
ricerca-area-matematica-ref-prof-2

Deadline for the application: 30 August 2019
First available date for position start: 16 September 2019
Online application: https://pica.cineca.it/sissa/ar-fe-mate-38-2019

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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/2B2F73A2-167A-4E52-9D55-35CC8D865472%40gmail.com.


[deal.II] Re: What is the path to the dealii installation directory in a containerized version?

2019-07-31 Thread luca.heltai
Jhon, 

the path is there, and it is correct. The message is telling you that you are 
in a directory containing developement version of the examples.

If you inspect the CMakeLists.txt of the example you are trying to compile, it 
tells you:


FIND_PACKAGE(deal.II 9.2.0 QUIET
  HINTS ${deal.II_DIR} ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
  )
IF(NOT ${deal.II_FOUND})
  MESSAGE(FATAL_ERROR "\n"
"*** Could not locate a (sufficiently recent) version of deal.II. ***\n\n"
"You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to 
cmake\n"
"or set an environment variable \"DEAL_II_DIR\" that contains this path."
)
ENDIF()

i.e., I guess your program is looking for deal.II 9.2.0, but finds only 9.1.1, 
and bails out.

Try replacing 9.2.0 with 9.1.0 in the CMakeLists.txt, and you should be able to 
compile and run within docker.

Best,
Luca.

> On 30 Jul 2019, at 23:39, Luca Heltai  wrote:
> 
> You don't need to do that, because the container already export DEAL_II_DIR 
> to the correct path. 
> 
> Luca
> 
> Il giorno 30 lug 2019, alle ore 22:50, Jhon Uribe  ha 
> scritto:
> 
>> 
>> 
>> El martes, 30 de julio de 2019, 15:48:47 (UTC-5), Jhon Uribe escribió:
>> Hello
>> 
>> I am using a container from the image 
>> v9.1.1-gcc-mpi-fulldepsspack-debugrelease, but when I try to use the command 
>> "cmake -DDEAL_II_DIR=/path/to/installed/deal.II .", I don't know what to 
>> replace the string "/path/to/installed/deal.II" for.
>> 
>> Thank you for your attention
>> 

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


Re: [deal.II] obtaining an ellipsoid grid and manifold from GridGenerator::hyper_sphere() and a subclass of ChartManifold

2019-06-13 Thread luca.heltai
Dear Sebastian, 

have you tried using a simple SphericalManifold for your problem?

The way spherical manifold works is by interpolating *both* the radius and the 
angles, so that points intermediate between two points with different radii get 
an average radius between the two. 

This may not be the exact solution you were looking for, but if you have a 
sphere which is uniformly deformed along one axis, then SphericalManifold 
should do the correct job for you.

L.

> On 13 Jun 2019, at 12:31, SebG  wrote:
> 
> Hi Wolfgang,
> 
> that is exactly the way how I tried to implement this. For a section of a 
> sphere the approach of step-53 works perfectly well for my case too. But I 
> need a full sphere. For the full sphere the problem is that SphericalManifold 
> (like Manifold) does not have the a function called push_forward anymore. So 
> I tried to overload the functions get_intermediate_point, get_new_point and 
> get_new_points. I am not sure which member functions I need to overload if I 
> derive my from class SphericalManifold. I am also not sure if I should derive 
> my class from SphericalManifold or Manifold. It would be great if you could 
> give some advice.
> 
> Best wishes,
> Sebastian
> 
> 
> Am Dienstag, 11. Juni 2019 17:39:44 UTC+2 schrieb Wolfgang Bangerth:
> On 6/11/19 1:06 AM, SebG wrote: 
> > 
> > actually I was not aware of this class. But this class is unfortunately 
> > only 
> > implemented in 2D. I am not exactly looking for an ellipsoid but for a 
> > sphere 
> > with a peturbed radius, where r = R * (1 +  e * Y^m_n(\theta, \phi) ). Here 
> > R 
> > is the reference radius, e > 0 is a scalar and  Y^m_n is a real-valued 
> > spherical harmonic. 
> > 
> > To implement this, I thought that I could map a point from the perturbed 
> > sphere to the reference sphere. Then the updated point is computed on the 
> > reference sphere and mapped back to the perturbed one. 
> > 
> > As a first step, I tried this approach based on the step-53 tutorial. But I 
> > realized that closing the sphere at the poles and in azimuthal direction 
> > does 
> > not work. Then I thought that it might easier to program the example of an 
> > ellipsoid from this discussion. 
> > 
> > It would interessting to know why my approach of mapping back to a 
> > reference 
> > sphere is not working with the updated version of SphericalManifold. But 
> > maybe 
> > this is worth a new discussion. 
> 
> I don't know what the issue is, but the way I would write this is a 
> concatenation of two operations. The first would be the transformation from 
> reference coordinates to the sphere (done by the push_forward() function of 
> the SphericalManifold) and the second the scaling in radial direction (done 
> by 
> your own code). step-53 does this same kind of 2-step procedure, but instead 
> of using the WGS84 transformation used there, you'd just defer to 
> SphericalManifold::push_forward. 
> 
> Best 
>   W. 
> 
> 
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
> www: http://www.math.colostate.edu/~bangerth/ 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/5d4bb9c2-d11c-4c4f-aaf9-035352f1c839%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: [deal.II] obtaining an ellipsoid grid and manifold from GridGenerator::hyper_sphere() and a subclass of ChartManifold

2019-06-05 Thread luca.heltai
Did you look at this class?

https://www.dealii.org/developer/doxygen/deal.II/classEllipticalManifold.html

It is in deal.II 9.1.0…

L.

> On 3 Jun 2019, at 12:54, SebG  wrote:
> 
> Hi Thomas, hi Luca,
> 
> I would like to re-generate the ellipsoidal with deal.ii 9.0.1 but the 
> interfaces of the SphericalManifold class have changed in some release. So I 
> tried to re-implement the following methods
> 
> virtual std::unique_ptr> clone() const override;
> 
> virtual Point get_intermediate_point(
> const Point ,
> const Point ,
> const double weight) const override;
> 
> virtual void get_new_points(
> const ArrayView>  _points,
> const Table<2,double>   ,
> ArrayView>   new_points) const 
> override;
> 
> virtual Point get_new_point(
> const ArrayView>  ,
> const ArrayView   ) const override;
> 
> and two additional methods for the mapping from ellipsoid to sphere:
> 
> /*
>  * map a (cartesian) point on a sphere to a point on an ellipsoid
>  */
> Point push_forward(const Point_point) 
> const;
> 
> /*
>  * map a (cartesian) point on an ellipsoid to a point on a sphere
>  */
> Point pull_back(const Point  _point) const;
> 
> Somehow, my implementation does not work well and the mesh is distorted 
> especially for points on the y- and z-axis. I am actually using the ellipsoid 
> as test case and would like generate a mesh consisting of a sphere with 
> (spherical harmonic) boundary topography.
> 
> Does anyone know what is going wrong here and the code by Thomas may used in 
> a newer version of deal.ii?
> 
> Best wishes,
> Sebastian
> 
> 
> Am Dienstag, 9. August 2016 19:04:07 UTC+2 schrieb thomas stephens:
> Luca, Thank you for the help.  
> 
> I now have a working Ellipsoid class:
> 
> template 
> class Ellipsoid: public SphericalManifold
> {
> public:
> 
>   Ellipsoid(double,double,double);
> 
>   Point pull_back(const Point _point) const;
> 
>   Point push_forward(const Point _point) const;
> 
>   Point get_new_point(const Quadrature ) const;
> 
>   Point grid_transform(const Point );
> 
> private:
>   double  a,b,c;
>   double max_axis;
>   const Point center;
> 
>   Point ellipsoid_pull_back(const Point _point) const;
> 
>   Point ellipsoid_push_forward(const Point _point) const;
> 
> };
> 
> 
> with member functions: 
> 
> template 
> Ellipsoid::Ellipsoid(double a, double b, double c) : 
> SphericalManifold(center), a(a), b(b),c(c), center(0,0,0)
> {
>   max_axis = std::max(std::max(a,b),c);
> }
> 
> 
> template 
> Point Ellipsoid::pull_back(const Point 
> _point) const
> {
>   Point chart_point = ellipsoid_pull_back(space_point);
>   Point p;
>   p[0] = -1; // dummy radius to match return of SphericalManifold::pull_back()
>   p[1] = chart_point[0];
>   p[2] = chart_point[1];
> 
>   return p;
> }
> 
> 
> template 
> Point Ellipsoid::push_forward(const Point 
> _point) const
> {
> 
>   Point p;  // 
>   p[0] = chart_point[1];
>   p[1] = chart_point[2];
> 
>   Point space_point = ellipsoid_push_forward(p);
>   return space_point;
> 
> }
> 
> 
> template 
> Point Ellipsoid::get_new_point(const 
> Quadrature ) const
> {
>   double u,v,w;
>   std::vector< Point > space_points;
>   for (unsigned int i=0; i   {
> u = quad.point(i)[0]/a;
> v = quad.point(i)[1]/b;
> w = quad.point(i)[2]/c;
> space_points.push_back(Point(u,v,w));
>   }
> 
>   Quadrature spherical_quad = Quadrature(space_points, 
> quad.get_weights());
> 
>   Point p = 
> SphericalManifold::get_new_point(spherical_quad);
>   double x,y,z;
>   x = a*p[0];
>   y = b*p[1];
>   z = c*p[2];
> 
>   Point new_point = Point(x,y,z);
>   return new_point;
> }
> 
> template 
> Point Ellipsoid::ellipsoid_pull_back(const Point 
> _point) const
> {
>   double x,y,z, u,v,w;
> 
>   // get point on ellipsoid
>   x = space_point[0];
>   y = space_point[1];
>   z = space_point[2];
> 
>   std::cout << "using a,b,c: " << std::endl;
>   std::cout << a << " " << b << " "  << c << std::endl;
>   std::cout << "from pull_back: " << std::endl;
>   std::cout << "space_point: " << std::endl;
>   std::cout << x << " " << y << " "  << z << std::endl;
> 
>   // map ellipsoid point onto sphere
>   u = x/a;
>   v = y/b;
>   w = z/c;
> 
>   std::cout << "pulls back to : " << std::endl;
>   std::cout << u << " " << v << " "  << w << std::endl;
>   std::cout << "on sphere." << std::endl;
> 
>   Point p(u,v,w);
> 
>   // use reference_sphere's pull_back function
>   Point q = pull_back(p);
>   Point chart_point;
> 
> 
>   std::cout << "sphere pull_back: " << std::endl;
>   std::cout << q[0] << " " << q[1] << " "  << q[2] << std::endl;
>   std::cout << "r theta phi" << std::endl;
>   std::cout << "..." << std::endl;
> 
>   chart_point[0] = q[1];
>   chart_point[1] = q[2];
> 
>   // return (theta,phi) in the chart domain 
>   return chart_point;
> 
> }
> 
> template 
> 

Re: [deal.II] Interpolate correct solution onto mesh using interpolate() with FE_Bernstein elements

2019-05-16 Thread luca.heltai


> On 16 May 2019, at 9:16, 'Maxi Miller' via deal.II User Group 
>  wrote:
> 
> I would like to use the interpolate()-function to interpolate the correct 
> function onto my mesh for comparison during some simple tests. This works 
> fine when using FE_Q-elements, but fails when using FE_Bernstein elements.

FE_Bernstein, like BSplines, are not interpolatory, there is not a single 
definition of “interpolation”, since there are no support points.

If you want your function to be interpolated at some points, then you’d have to 
construct the interpolation matrix yourself, by solving in some sense the 
following system

sum_i  B_i(x_j) u_i = f(x_j)

provided that you specify exactly the same number of interpolation points as 
there are degrees of freedom.

One easy way to do this, is to interpolate to a dofhandler with FE_Q(d), with 
the same degree of the FEBernstein, and then call 


void VectorTools::interpolate   (   const DoFHandler< dim, spacedim > & 
dof_1,
const DoFHandler< dim, spacedim > & dof_2,
const FullMatrix< double > &transfer,
const InVector &data_1,
OutVector & data_2 
)

where the FullMatrix< double > & transfer represents the local interpolation 
between FE_Bernstein and FE_Q. 

https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a5e3af70a47cedfaf361cf5c621e94e3d

This is used, for example, here:

https://github.com/dealii/dealii/blob/master/include/deal.II/numerics/vector_tools.templates.h#L9120

You can do the exact same thing. Construct a local interpolation matrix, and 
then call the interpolate function above passing this matrix (and the vector 
you interpolated on the standard FE_Q space).

https://github.com/dealii/dealii/blob/master/include/deal.II/numerics/vector_tools.templates.h#L9208

Best,
Luca.



> The error message I get is 
> An error occurred in line <3098> of file 
> <~/Downloads/git-files/dealii/source/fe/fe_values.cc> in function
> dealii::FEValuesBase::FEValuesBase(unsigned int, unsigned 
> int, dealii::UpdateFlags, const dealii::Mapping&, const 
> dealii::FiniteElement&) [with int dim = 2; int spacedim = 2]
> The violated condition was: 
> n_q_points > 0
> Additional information: 
> There is nothing useful you can do with an FEValues object when using a 
> quadrature formula with zero quadrature points!
> 
> 
> Is there an alternative way to interpolate a function onto the mesh when 
> using FE_Bernstein elements?
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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/2f5b238a-b78a-4097-b492-2e0ebd82ec93%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: [deal.II] Mass matrix for a distributed vector problem

2019-04-12 Thread luca.heltai
Wolfgang, is that true also for mass matrices? I’d agree with you for stiffness 
matrices, but I’d surprised this worked ok for mass matrices as well.

If so, I’ve always been over integrating in my life… 

:) 

L.

> On 12 Apr 2019, at 21:15, Wolfgang Bangerth  wrote:
> 
> On 4/12/19 8:41 AM, Robert Spartus wrote:
>> 
>> That is some fascinating information! It seems like step-44, for 
>> instance, does not follow this recommendation, as there the polynomial 
>> degree is 2, while the quadrature degree is 3
> 
> Actually, Gauss quadrature with degree+1 points in each direction is 
> sufficient to retain the convergence order of the finite element in 
> question, on any kind of mesh. Using higher order quadrature formulas 
> might increase the *absolute accuracy*, but is not necessary for the 
> convergence *order*.
> 
> 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.

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

2019-04-12 Thread luca.heltai
If you plan to use any domain that is not a square (or an affine 
transformation), you have to make sure you integrate exactly the product of two 
polynomials of order degree and of the determinant of the Jacobian. This last 
term is constant only for simple meshes, but it is the square root of a 
polynomial of order (degree-1) in more complicated cases.

2*fe_degree is ok for most cases, but I would not use this for serious 
calculations. I prefer to be on the safe side…

:)

L.

> On 11 Apr 2019, at 19:34, Robert Spartus  wrote:
> 
> Dear Luca,
> 
> Thanks for your suggestion. Unfortunately, it did not solve the problem. I am 
> sending the modified version, as well as the output of the program.
> 
> Out of curiosity, what is the reason to use (2*fe_degree + 1)? Checking 
> step-8, I notice that there a quadrature degree one larger than the 
> polynomial degree is also used.
> 
> Bests,
> Bob
> 

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

2019-04-11 Thread luca.heltai
You are integrating using two quadrature points per direction. Can you raise 
that to (2*fe.degree+1)?

L.

> On 11 Apr 2019, at 10:58, bobspar...@gmail.com wrote:
> 
> Dear all,
> 
> First of all, thanks for the awesome library. I am starting to learn deal.II, 
> and it is great! The documentation has been extremely helpful so far.
> 
> I am trying to solve the time dependent elastic equation, and there we 
> naturally have a mass matrix-like for the velocities. To build this mass 
> matrix, I adapted the function Diffusion::assemble_system from step-52. 
> However, in my problem the mass matrix has zero determinant, therefore, it is 
> not invertible. Is there some mistake in the construction of the mass matrix, 
> or something I am missing? 
> 
> I have sent attached a minimal source code that reproduces this error, the 
> output of a single run, and a file containing the mass matrix.
> 
> I am running deal.II 9.0.0 installed via candi in Ubuntu 18.04.
> 
> Kind regards,
> Bob
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] issues with manifold id (at least in codim-1) revealed by PR 7775

2019-03-19 Thread luca.heltai
Nicola, 

what would you think of a function in GridTools like 

GridTools::propagate_internal_manifold_ids(tria, disambiguation_function)

that would loop over all cells, loop over all faces, check if the neighbor 
manifold id is the same of this cell, and 
i) the two ids are the same: assign the same id to the face (calling 
cell->face(f)->set_all_manifold_ids())
ii) the two ids are different: set the id of the face to the return value of 
the disambiguation_function(id1, id2)

disambiguation_function could be of type

std::function

and its default implementation could be 

std::function = [](const manifold_id , const manifold_id ){return 
std::min(id1, id2);}

Would this address your needs?

L.


> On 15 Mar 2019, at 15:16, Nicola Giuliani  wrote:
> 
> I agree that the choice is ambiguous on the faces. 
> 
> However a practical problem remains, let's assume that a user wants to import 
> a very big geometry with a lot of internal faces. Right now he would need to 
> specify all the possible faces in the input file (with an increasing 
> possibility of confusing the manifold ids). 
> I agree he should (otherwise is a criminal) specify what happens when two 
> different manifolds meet but if we have a face neighbouring two cells with 
> the same manifold_id couldn't (or shouldn't) we assume the manifold of the 
> face to be the same? 
> Alternatively we could write a utility to transfer the manifold information 
> to the faces, it should be "morally" the same of calling set_all_manifold_ids.

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

2019-03-19 Thread luca.heltai
> Is there a reason then that there are several examples using 
> integration_loop(), but (afaik) only one using mesh_loop?

Yes. mesh_loop is more recent w.r.t. integration_loop.

mesh_loop was introduced to address some of the oddities that are in 
integration_loop, that make its use somewhat less intuitive w.r.t. 
WorkStream::run, and was originally thought as the “kernel” of integration_loop.

The original idea was to replace the internals of integration_loop with 
mesh_loop, but this stage of the project is not yet completed (for lack of time 
of the original developers of mesh_loop… cough cough… :) …).

The examples in 

https://github.com/dealii/dealii/pull/7806

show you a few more ways to use mesh_loop, for DG methods, or using Automatic 
Differentiation.

Hopefully there will be more examples soon on using mesh_loop.

L.


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

2019-03-18 Thread luca.heltai
Take a look at this PR for a few examples of usage of mesh_loop:

https://github.com/dealii/dealii/pull/7806

The function WorkStream::run 

takes (a minimum of) 5 arguments:

WorkStream::run(cell, endc, cell_worker, copier, scratch, copy);

initial and final iterator, a worker function, a copier function, a scratch 
object, and a copy object.

Logically, WorkStream::run does the following:

for(it = cell; it != endc; ++it) {
cell_worker(cell, scratch, copy);
copier(copy);
}

and is agnostic about what type of iterator you pass to it. 

MeshWorker::mesh_loop is a specific implementation of the above in which the 
iterator is a cell iterator, and the loop is thought to run also on each face 
of each cell as well, in order to assemble DG type contributions, i.e., it 
allows you to specify two additional functions, a boundary_worker and a 
face_worker:

WorkStream::mesh_loop(cell, endc, cell_worker, copier, scratch, copy, flags, 
boundary_worker, face_worker);

This is logically identical to

for(it = cell; it != endc; ++it) {
cell_worker(cell, scratch, copy);
for(unsigned int f=0; fface(f)->at_boundary() {
boundary_worker(cell, f, scratch, copy);
   } else {
// Get subface, neighbor face index, and neighbor subface index
const auto [sf, nf, nsf] = get_neighbor_info(cell, f);
// Run the face worker
face_worker(cell, f, sf, cell->neighbor(f), nf, nsf);
   }
}
copier(copy);
}

What mesh_loop does is controlled in a finer way by the assembly flags. For 
example it is possible to visit each face only once, or to assemble first faces 
and then cells, etc. 

MeshWorker::integration_loop 

is a specific implementation of MeshWorker::mesh_loop where you use the DoFInfo 
and DoFInfoBox objects, that contain scratch and copy data with a different 
structure. The two behave in a substantially identical way, but with different 
data structures. 

In particular, you could implement MeshWorker::integration_loop using 
MeshWorker::mesh_loop, and some wrapping around DoFInfo and DoFInfoBox objects.

I hope this clarifies a little the scope of run (agnostic about iterators) and 
mesh_loop (actually expecting cell iterators, and taking care of 
subface/face/neighbor matching when looping over faces).

Best,
Luca.


> On 18 Mar 2019, at 17:46, 'Maxi Miller' via deal.II User Group 
>  wrote:
> 
> Similar question: How are the different loop-functions differentiated, i.e. 
> MeshWorker::integration_loop and MeshWorker::mesh_loop? Both are able to loop 
> over faces, boundaries and cells, but what are the differences here?
> Thanks!
> 
> Am Dienstag, 22. Januar 2019 16:56:28 UTC+1 schrieb Bruno Turcksin:
> Le mar. 22 janv. 2019 à 10:48, 'Maxi Miller' via deal.II User Group 
>  a écrit : 
> > I. e. if I would like to calculate f. ex. the L2-norm of a vector (while 
> > neglecting that there already is a function for that), I can use WorkStream 
> > for parallelization of that, but not MeshWorker, is that correct? 
> That's right. You can use WorkStream using the iterators for the 
> vector but MeshWorker won't work because it expects cell iterators. 
> 
> 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.

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

2019-03-18 Thread luca.heltai
You may also find useful this link:

https://journals.ub.uni-heidelberg.de/index.php/ans/issue/view/2930

where the authors implement XFEM in deal.II to model interface problems.

L.

> On 18 Mar 2019, at 9:39, Daniel Arndt  
> wrote:
> 
> James,
>  
> I am a graduate student who will be defending in the not-too-distant future, 
> and afterwards I want to remain in the research community even though I will 
> be leaving academia for the foreseeable future. My research group has an 
> established cohesive-zone model (CZM) code that is used in Abaqus, and I have 
> been using this for all of my graduate work. The main drawback to not 
> switching over to deal.ii years ago was that it lacks the ability to model 
> crack-propagation (which is the main focus of my research), and the 
> resistance to changing from a code the group knows already works.
>  
> There are at least some papers that use deal.II for crack propagations, e.g. 
> "A primal-dual active set method and predictor-corrector mesh adaptivity for 
> computing fracture propagation using a phase-field approach".
> 
> 
> With this in mind, would a user/developer be willing to guide me along the 
> path of writing a new FiniteElement? I have already written initial 
> traction-separation laws (in C++) that could be used in a "volume" 
> cohesive-zone element. I have collected papers of others who have already 
> written cohesive-zone finite-elements for the commercial software package 
> Abaqus, and my intention would be to replicate this work (with perhaps some 
> small modifications/improvements) for deal.ii so that I can continue work in 
> fracture mechanics.
>  
> It is probably best if you describe what you need and how your new finite 
> element would look like. In general, you need to define a suitable 
> (polynomial) ansatz space and how the degrees of freedom are evaluated. In 
> case, the element uses tensor-product polynomials there are alreay at lot of 
> prerequsites available. You might one want to look into the implementation of 
> FE_Q (https://github.com/dealii/dealii/blob/master/source/fe/fe_q.cc)
> 
>  
> Additionally, does deal.ii have the capabilities of the so-called A-FEM 
> (augmented finite element method)? A-FEM allows one element to change an 
> element from one finite-element into another finite-element during the 
> calculation. An example from fracture mechanics: starting with an initially 
> isotropic elastic calculation of generic shape, when a certain stress 
> threshold is met by an element, the elastic element is replaced with a CZM 
> element to allow for arbitrary crack-initiation and propagation to occur. 
> Note: other FEM-based methods appear to use this same idea of replacing one 
> element type with another during a calculation, but I am do not have 
> extensive knowledge of the nuanced differences between them.
>  
> deal.II support hp-adaptivity that requires the possibility to use different 
> finite elements across the discretization. Have a look at 
> https://www.dealii.org/current/doxygen/deal.II/step_27.html.
> 
> 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.

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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] issues with manifold id (at least in codim-1) revealed by PR 7775

2019-03-13 Thread luca.heltai
I believe the first point is a bug of the read_ucd function. 

I opened an issue for this (https://github.com/dealii/dealii/issues/7802)

The second point, however, is a feature. What should you do when two material 
ids meet? I think it is the responsability of the user to make sure that the 
correct manifold id is associated to the correct face.

Currently our read/write vtk functions (in the GridIn class) are the only ones 
allowing full treatment  material ids, boundary ids, and manifold ids.

I’m not sure UCD format allows you to specify both material and manifold ids 
for cells, and boundary and manifold is for faces. Maybe Andrea knows better?

L.

> On 8 Mar 2019, at 15:15, Nicola Giuliani  wrote:
> 
> PR 7775 has revealed some critical issues in the handling of manifold_id in 
> codim-1 domain.
> 
> -) I believe that GridIn.read_ucd appears to ignore manifold ids associated 
> to the cells, it seems to me that the flag 
> apply_all_indicators_to_manifold_ids does not affect the manifold id for the 
> cell. This issue has never been seen because internally the material_id was 
> used.
> 
> -) As far as I understand the default behaviour is to consider only user 
> specified manifold ids for the lines of a cell otherwise flat_manifold_id. 
> Would it make sense to use the cell->manifold_id instead of flat_manifold_id?
> 

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

2018-11-18 Thread luca.heltai
Did you use the option “colorize=on”?

L.

> On 18 Nov 2018, at 10:45, Praveen C  wrote:
> 
> 
> 
>> On 18-Nov-2018, at 2:59 PM, luca.heltai  wrote:
>> 
>> Dear Praveen, 
>> 
>> this is actually a feature, and not a bug. The reason is that, by default, 
>> deal.II generates triangulations with boundary id = 0. If you don’t specify 
>> a boundary id in the gmsh file, then all boundary faces get boundary id = 0.
>> 
>> This allows us to save space in the output grid, since there is no need to 
>> save faces with id = 0, because they will be recreated correctly when you 
>> read the mesh back in.
>> 
>> Best,
>> Luca.
>  
> 
> ok. This is fine for deal.II but if I try to use this mesh with other tools, 
> then it may not be ideal. Maybe an option to save id=0 faces also might be 
> useful.
> 
> The other issue is that both inner sphere and part of the outer sphere are 
> getting id=0. This makes it difficult to use the boundary id to set different 
> boundary conditions on the inner and outer sphere.
> 
> The description says faces on outer sphere should get id=1 but that is not 
> happening.
> 
> Best
> praveen
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> 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] Saving boundary faces in half_hyper_shell to msh file

2018-11-18 Thread luca.heltai
Dear Praveen, 

this is actually a feature, and not a bug. The reason is that, by default, 
deal.II generates triangulations with boundary id = 0. If you don’t specify a 
boundary id in the gmsh file, then all boundary faces get boundary id = 0.

This allows us to save space in the output grid, since there is no need to save 
faces with id = 0, because they will be recreated correctly when you read the 
mesh back in.

Best,
Luca.

Ps: there is a new pull request https://github.com/dealii/dealii/pull/7427 that 
allows you to save both boundary ids and manifold ids using the vtk format 
instead of the msh format (that does not allow saving manifold id information 
on the file).

> On 18 Nov 2018, at 4:17, Praveen C  wrote:
> 
> Dear ll
> 
> I am using GridGenerator::half_hyper_shell and save the mesh in msh format. I 
> also want boundary faces to be saved. However not all boundary faces are 
> being saved. See attached figure.
> 
> There are two problems.
> 
> Some boundary faces have id = 0 which do not get saved to msh file.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> Both inner sphere and part of the outer sphere are getting same id of 0
> 
> You can first run attached code and see default behaviour. 
> 
> Then uncomment call to set_boundary_id function and run again which now saves 
> all boundary faces.
> 
> I changed boundary id 0 to 3 and also modified check to determine boundary 
> face. I am not sure this works for all cases though.
> 
> If this something that needs to be fixed in the library ?
> 
> 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.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Help on manifold ids

2018-11-12 Thread luca.heltai
Dear Earl, 

setting the Manifold should be done *before* you do refinment. 

The line you added at the end, tria.execute_coarsening_and_refinement(), is not 
doing any refinement, so you don’t see the effect of your set_manifold_id() 
call. 

What happens if you refine globally once more after the loop where you set the 
manifold on the faces?

L.

> On 13 Nov 2018, at 7:39, Earl Fairall  wrote:
> 
> Hi everyone,
> I am having some trouble handling manifold ids. I  built a script where I 
> want every face center with radius <= 50 to have a spherical manifold, and 
> every face center radius > 50 to have a flat manifold. I can make them all 
> flat by default and I have also used “tria.set_all_manifold_ids(8)” to make 
> the entire mesh spherical, but I can’t figure out how to have both. The code 
> does not fail during compilation; however, the mesh simply doesn’t get 
> impacted by this line of code “cell→face(f)→set_manifold_id(8);” in my nested 
> loop. I know the nested loop is being executed, so I must be missing some key 
> information about how to assign the manifold. 
> 
> Any help you can provide is greatly appreciated.
> 
> const SphericalManifold<2> boundary_description(center);
> tria.set_manifold(8, boundary_description);
> tria.refine_global(3);
> 
> typename Triangulation<2>::active_cell_iterator
> cell = tria.begin_active(),
> endc = tria.end();
> for (; cell != endc; ++cell)
> {
> for (unsigned int f = 0;
> f < GeometryInfo<2>::faces_per_cell;
> ++f)
> {
> const Point<2> face_center = cell->face(f)->center();
> if (sqrt(pow(face_center[0], 2) + pow(face_center[1], 2)) <= 50)
> {
> cell→face(f)→set_manifold_id(8); \\this line does not appear to be executing
> std::cout << "setmanifold" << std::endl; \\ this is printing, so I know the 
> code goes here.
> }
> }
> }
> tria.execute_coarsening_and_refinement();
> 
> 
> 
> Sincerely,
> 
> Earl 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Compilation problems with MS Visual Studio, 2017

2018-10-12 Thread luca.heltai
Dear Rochan, 

you can find prebuilt static binaries of deal.II 8.5.0 for windows, with no 
external libraries, here:

https://github.com/luca-heltai/dealii/releases/tag/9.5.pre-windows

I also know of people that successfully compiled and used deal.II 9.0.0 on 
windows.

L.

> On 12 Oct 2018, at 4:47, Rochan Upadhyay  wrote:
> 
> Reading from topics in mailing lists, it seems Windows is not the preferred 
> platform. However for reasons of convenience (e.g. working from a laptop) I 
> would like to build the code with MS Visual Studio. I followed the 
> instructions in https://github.com/dealii/dealii/wiki/Windows for "Using 
> deal.II on native Windows". As mentioned there, I am using MSVC v15.0, 2017 
> Community edition. It seems to go well except for one problem :
> Compilation fails in the code include\deal.ii\grid\grid_tools.h, in the 
> function declaration in line 1100:
> std::pair::active_cell_iterator, 
> Point >
>   find_active_cell_around_point (const Cache
>  ,
>  const Point
>  ,
>  const typename Triangulation spacedim>::active_cell_iterator _hint=typename Triangulation spacedim>::active_cell_iterator(),
>  const std::vector  
>  _vertices = std::vector());
> From Google, it seems that using "designated initializers" such as const 
> std::vector _vertices = std::vector() in the function 
> declaration in the header file is not allowed in Visual Studio. It needs 
> building with C99 support which is not there. The build process throws a few 
> more errors but it is mostly in .cc files that use the above function. I 
> think there is one more function in the same file (grid_tools.h) where 
> "designated initializers" are used and compilation fails on them as well. I 
> am very poor at MS Visual Studio. Could anyone well versed in this area 
> suggest a workaround for the above problem ? Also are there any pre-built 
> binaries / libraries for use with Windows ?
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] advice on import from STEP format

2018-10-01 Thread luca.heltai
Dear Marek, 

> On 29 Sep 2018, at 22:58, Marek Čapek  wrote:
> 
> Hi,
> I have a geometry in step file format. I would like to import it and generate
> from it a mesh digestible by dealii GridIn functions.
> I followed step-54, modifying thefunction read_domain
> 
> https://www.dealii.org/8.4.1/doxygen/deal.II/step_54.html#TriangulationOnCADread_domain
> 
> in the following way:
> 
>   void TriangulationOnCAD::read_domain()
>   {
> TopoDS_Shape sh = OpenCASCADE::read_STEP(cad_file_name, 1e-3);
> 
> std::vector   faces;
>  std::vector   edges;
>  std::vector vertices;
> 
>  OpenCASCADE::extract_geometrical_shapes(sh, faces, edges, vertices);
> 
>  OpenCASCADE::create_triangulation(faces[0], tria);
> 
>  
>const double tolerance = OpenCASCADE::get_shape_tolerance(sh) * 5;
> 
> 
>std::vector  compounds;
>std::vector compsolids;
>std::vector solids;
>std::vector shells;
>std::vector  wires;
> 
>OpenCASCADE::extract_compound_shapes(sh,
> compounds,
> compsolids,
> solids,
> shells,
> wires);

You have to make sure you know how the surfaces/wires/solids,etc are 
distributed in your CAD file. This will depend on how you generated your cad 
file, how many faces it is made of, etc.


>  std::ifstream in;
> 
>in.open(initial_mesh_filename.c_str());
> 
>GridIn<2,3> gi;
>gi.attach_triangulation(tria);
>gi.read_vtk(in);

How did you generate the initial grid? Are you sure the scaling is correct? 
IGES and STEP files often have different units of measure (typically IGES files 
units are millimiters). If your grid does not use the same units, you may get 
into trouble.

>output_results(0);
> 
>   
>Triangulation<2,3>::active_cell_iterator cell = tria.begin_active();
>cell->set_manifold_id(1);

This only sets the first cell id to 1. I don’t think your initial mesh only 
contains one face, does it? If it does, from what I can see from the file, 
there is no chance it can produce anything sensible. You will have to produce 
an initial mesh that is at least topologically equivalent to the CAD file your 
are trying to import. 

> 
>for (unsigned int f=0; f::faces_per_cell; ++f)
>  cell->face(f)->set_manifold_id(2);

Same here. You are setting the id of the faces of the first cell to 2.

>OpenCASCADE::ArclengthProjectionLineManifold<2,3>
>line_projector (wires[0], tolerance);
> 
>tria.set_manifold(2, line_projector);

There are at least 5 wires in the file you attached. You should identify where 
they are, set the corresponding manifold ids to something useful, and then 
attach the correct wire. The above lines were working on the case of the 
example, but won’t work in your case.

> Maybe my approach is wrong. Is that possible to import an IGES or STEP file 
> into dealii and
> let dealii process it automatically?

It depends by what you mean with “automatically”. If you have an input grid (in 
ucd format) where you already specified all the manifold ids, then you could use

read_ucd (in, true /* apply_all_indicators_to_manifolds */)

to get a mesh with all manifold ids set to the correct value. Then you should 
loop over all wires, and attach the correct one to the corresponding manifold 
id, and do the same with all faces. This cannot be done automatically, unless 
you manage to number your manifold ids with the same numbering of the step file 
(which I strongly suggest you do).

Unfortunately, we don’t have a file format (yet) that would do this 
automatically. You’ll have to do a lot of manual tuning.

L.

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

2018-09-21 Thread luca.heltai
Dear Riku, 

this is not (yet) supported by deal.II. You will have to attach manually a 
CylindricalManifold after extrusion. The library does not know yet how to 
compute the extrusion of a general manifold object, therefore it removes all 
manifold objects from the extruded triangulation (as they would not be valid 
objects, being of type Manifold<2>, while you’d require a Manifold<3> object).

L.

> On 20 Sep 2018, at 20:24, Riku Suzuki  wrote:
> 
> Hi all
> 
> I've been using the following chunk of code to generate mesh for 2D disk or 
> 3D sphere:
> 
>   template 
>   void sphere(Triangulation ,
>   const Point ,
>   double radius)
>   {
> SphericalManifold spherical_manifold(center);
> TransfiniteInterpolationManifold inner_manifold;
> GridGenerator::hyper_ball(tria, center, radius);
> tria.set_all_manifold_ids(1);
> tria.set_all_manifold_ids_on_boundary(0);
> tria.set_manifold(0, spherical_manifold);
> inner_manifold.initialize(tria);
> tria.set_manifold(1, inner_manifold);
>   }
> 
> The attached file p1.png shows a nice mesh in 2D generated from it (after 
> refinement).
> 
> Now I am trying to extrude the 2D mesh to get a 3D cylinder using 
> extrude_triangulation as follows:
> 
>   void cylinder(Triangulation<3> ,
> const double  radius,
> const double  length)
>   {
> Triangulation<2> tria2d;
> Point<2> center(0, 0);
> sphere(tria2d, center, radius);
> GridGenerator::extrude_triangulation(tria2d, 10, length, tria);
>   }
> 
> However the SphericalManifold is gone after extrusion, resulting in a mesh 
> shown in p2.png.
> 
> What did I do wrong?
> 
> Thank you
> Riku
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.


[deal.II] New package for mac - v9.1.0-pre-002bd21ce6

2018-05-27 Thread luca.heltai
Dear all, 

thanks for the feedback. Here you’ll find a new version of the deal.II package, 
made with spack, and compiled with clang@6.0.0, and gfortran@8.1:

https://github.com/luca-heltai/dealii/releases/tag/v9.1.0-pre-002bd21ce6

The package is independent on apple compilers, should work on most systems, and 
should be robust to Xcode updates.

Let me know if you have problems with it.

Best,
Luca.

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

2018-05-23 Thread luca.heltai
Dear All, 

the deadline for the submission of talks proposal for the “Sixth deal.II Users 
and Developers Workshop” is on the 23 of June (one month from now).

You are invited to register and submit an abstract through the online procedure:

http://indico.sissa.it/e/sixth-dealii-workshop

If you need an accommodation, we have reserved about thirty rooms at a special 
price in two residences (on a first come first served basis). Contact me so 
that I can forward your request to our administration.

Registration to the workshop is mandatory for the room to be reserved on your 
name.

Best,
Luca.

--
Luca Heltai 
http://people.sissa.it/~heltai/
Scuola Internazionale Superiore di Studi Avanzati
Phone:  +39 040 3787 449, Office: 608
--
There are no answers, only cross references

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"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: cmake . returns error on MAC OS XI Captain version 10.11.6 upon compiling dealii-8.5.0-brew.dmg

2018-05-11 Thread luca.heltai
The deal.II source directory can be found under

/Applications/deal.II-9.0.0.app/Contents/Resources/spack/src/deal.II-9.0.0

There you will find the examples directory.

In the new package (that I’m building right now), you’ll also have in the usual 
location.

Best,
Luca.



> On 12 May 2018, at 1:34, 'Wakil Sarfaraz' via deal.II User Group 
>  wrote:
> 
> In version 9.0.0 the examples directory is no longer located in 
> /Applications/deal.II-9.0.0.app/Contents/Resources/examples,
> Could you please help me allocated this?
> 
> Thanks,
> Wakil,
> 
> On Fri, May 11, 2018 at 10:47 PM, Denis Davydov  wrote:
> you can also try a pre-release package from this post: 
> 
> https://groups.google.com/forum/?fromgroups=#!topic/dealii/uvgXWCwAIlY 
> 
> 
> On Friday, May 11, 2018 at 10:53:32 PM UTC+2, Wakil Sarfaraz wrote:
> Hi Denis,
> Xcode is installed on my machine. It is just that I deleted the dmg files 
> associated to previous versions of deal.ii and cmake, which was perfectly 
> working.
> When I downloaded the new versions today, it returned these errors.
> 
> Best,
> Wakil 
> 
> On Friday, May 11, 2018 at 9:04:17 PM UTC+1, Denis Davydov wrote:
> Hi,
> 
> Make sure you have XCode installed as well as command line tools: 
> xcode-select --install
> 
> Regards,
> Denis.
> 
> On Friday, May 11, 2018 at 7:36:48 PM UTC+2, Wakil Sarfaraz wrote:
> Hi all,
> I have been away from deal.ii for almost two years.
> I have come back and wanted to install the most updated version which is 
> dealii-8.5.0-brew.dmg
> When I attempted to cmake the step-1 of the examples, it returns error 
> containing the following texts:
> 
> -- The C compiler identification is unknown
> 
> -- The CXX compiler identification is unknown
> 
> CMake Error at CMakeLists.txt:38 (PROJECT):
> 
>   The CMAKE_C_COMPILER:
> 
> 
> 
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> 
> 
> 
>   is not a full path to an existing compiler tool.
> 
> 
> 
>   Tell CMake where to find the compiler by setting either the environment
> 
>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
> 
>   the compiler, or to the compiler name if it is in the PATH.
> 
> 
> 
> 
> 
> -- Check for working CXX compiler: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx
> 
> -- Check for working CXX compiler: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx -- 
> broken
> 
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.11/Modules/CMakeTestCXXCompiler.cmake:45
>  (message):
> 
>   The C++ compiler
> 
> 
> 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx"
> 
> 
> 
>   is not able to compile a simple test program.
> 
> 
> 
>   It fails with the following output:
> 
> 
> 
> Change Dir: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp
> 
> 
> Run Build Command:"/usr/bin/make" "cmTC_a4024/fast"
> 
> /Library/Developer/CommandLineTools/usr/bin/make -f 
> CMakeFiles/cmTC_a4024.dir/build.make CMakeFiles/cmTC_a4024.dir/build
> 
> Building CXX object CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o
> 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx 
> -o CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o -c 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
> 
> make[1]: *** [CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o] Illegal 
> instruction: 4
> 
> make: *** [cmTC_a4024/fast] Error 2
> 
> 
> 
> 
>   
> 
> 
>   CMake will not be able to correctly generate this project.
> 
> Call Stack (most recent call first):
> 
>   CMakeLists.txt:38 (PROJECT)
> 
> 
> 
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeOutput.log".
> 
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeError.log".
> 
> localhost:step-1 wakilsarfaraz$ 
> 
> I will greatly appreciate your help on this.
> 
> Regards,
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/KTR-9nGYemg/unsubscribe.
> To unsubscribe from this group and all its topics, 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 

Re: [deal.II] Re: Mac testers wanted

2018-05-11 Thread luca.heltai
It did… Matthias just removed all of the intermediate release candidates.

I’m building the final package now. The 

https://github.com/luca-heltai/dealii/releases/tag/v9.0.0-rc1 

image has a missing initialisation file, so you have to define DEAL_II_DIR and 
CMAKE_PREFIX_PATH by yourself,

L.


> On 11 May 2018, at 23:50, Denis Davydov <davyd...@gmail.com> wrote:
> 
> Luca, 
> 
> the link does not seem to contain dmg. 
> You probably wanted to give a link to your fork, i.e. 
> https://github.com/luca-heltai/dealii/releases/tag/v9.0.0-rc1 
> 
> Cheers,
> Denis
> 
> On Sunday, May 6, 2018 at 11:51:19 AM UTC+2, Luca Heltai wrote:
> Sorry. The address is the following:
> 
> https://github.com/dealii/dealii/releases/v9.0.0-rc2
> 
> Luca
> 
> Il giorno 06 mag 2018, alle ore 11:30, luca.heltai <luca@gmail.com> ha 
> scritto:
> 
>> Dear all, 
>> 
>> I have just uploaded a new package for deal.II-9.0.0-rc2 here:
>> 
>> https://github.com/dealii/dealii/releases/edit/v9.0.0-rc2
>> 
>> This was compiled with Apple clang 9.1.0, and gfortran from gcc 7.3.
>> 
>> Please test, and let me know if everything is ok.
>> 
>> Best,
>> Luca.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.


[deal.II] Mac testers wanted

2018-05-06 Thread luca.heltai
Dear all, 

I have just uploaded a new package for deal.II-9.0.0-rc2 here:

https://github.com/dealii/dealii/releases/edit/v9.0.0-rc2

This was compiled with Apple clang 9.1.0, and gfortran from gcc 7.3.

Please test, and let me know if everything is ok.

Best,
Luca.

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

2018-04-30 Thread luca.heltai
The problem is that you cannot read a mesh with hanging nodes. If you have a 
mesh with hanging nodes, all faces with a hanging node are actually boundary 
faces, so in your picture, all faces that are between a refined and an 
unrefined cells, are actually boundary faces, i.e., they are topologically 
separated (it is as if you had two different lines there).

If you count the faces, you’ll have 16 refined faces (8 left, 8 right), plus 8 
coarse faces (4 left and 4 right) that counts up to 24.

Don’t read meshes with hanging nodes. Deal.II does not know how to treat those 
hanging nodes, and will simply treat those as boundary faces, with id = 0 
(which is the default boundary id).

L.

> On 30 Apr 2018, at 15:53, zeng <2012zg...@gmail.com> wrote:
> 
> hi all, I tried to create a mesh as follws:
> 1. Generate the initial mesh using gmsh. Use 1, 2, 3 as boundary_indicator to 
> denote three diffenrent boundary. Then I got the initial square.msh file. It 
> looks like this:
> 
> 
> 
> 
> 
> 
> 
> 
> 2. Read the mesh into dealii. Refine those cells with boundary indicator 3 
> and output to square_refined0.msh. When output this refined mesh, I used 
> flags to keep the boundary indicators. so the boundary faces still have 
> correct boundary_indicators after refinement.
> 
> 
> 
> My problem is:
> 
> When I use the following code to test the resulting mesh square_refined0.msh. 
> The result shows that there are 24 faces whose boundary_id is 0 in the 
> triangulation. Since from the initial mesh, I only set boundary_ids to 1,2,3. 
> Why the resulting mesh have boundary_id 0? Is this a bug?
> 
> 
> 
> 
> 
> My code is like:
> 
> void test_square(){
> 
>   Triangulation<2> triangulation;
> 
>GridIn<2> gridin;
> 
>gridin.attach_triangulation(triangulation);
> 
>std::ifstream f("square_good_refined0.msh");
> 
>gridin.read_msh(f);
> 
>int i=0;
> 
>typename Triangulation<2>::active_cell_iterator 
> 
> cell = triangulation.begin_active(),
> 
> endc = triangulation.end();
> 
>for(; cell!=endc; cell++)
> 
>   for(unsigned int face = 0; face::faces_per_cell; 
> face++){
> 
>  if(cell->face(face)->boundary_id()==0)
> 
> i ++;
> 
>   }
> 
>std::cout<<"number of boundary_id=0 faces "< 
> } 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.


[deal.II] Postdoc @ SISSA mathLab, Trieste -- numerical modeling and simulation of nanometric electronic devices

2018-03-20 Thread luca.heltai
Dear all, 

the following announcement may be of interest to you or to some of your 
students. We are actively seeking for a deal.II experienced programmer ASAP!

Best,
Luca.

--

A one year postdoctoral position is available at SISSA @ mathLab, starting from 
May 1, 2018

(see https://goo.gl/247WNT for the application procedure and the position 
details)

Fields of the research activity: 
- Numerical modeling and simulation of nanometric electronic devices
- Modeling the electrical properties of materials, including structural defects 
and interfaces, providing a link between ab-initio simulation software and the 
traditional Technology-CAD software used in the semiconductor industry. 
- 3D Finite Element simulations of the potential and temperature fields in the 
device and of the charge continuity and drift-diffusion equations using the 
deal.II (www.dealii.org) library. 

The candidate will work closely with the MDLSOFT company 
(http://www.mdlsoft.com/).

Duration of the research fellowship: 12 months, renewable, gross remuneration 
per year: € 24.336,00 

Candidates are required to have at least two confidential letters of reference 
sent to the address luca.hel...@sissa.it, before the deadline (13th of April 
2018). 

Requisites for the admission to the selection procedure: University degree: 
Master's degree in Mathematical Engineering, Physics Engineering, Electronic 
Engineering, Industrial Engineering (Aerospace, Mechanics, Nuclear, Energetics, 
or equivalent), Civil Engineering, Mathematics, Physics. 

Proven experience in: Mathematical modeling, numerical analysis, and simulation 
for complex systems governed by PDEs - advanced C++ programming skills - 
knowledge / use of development platforms in Windows and Linux for scientific 
computing. 

Preferential Title: PhD in Mathematical Engineering, Electronic Engineering, 
Mathematics, Applied Mathematics, Industrial Engineering, Numerical Analysis, 
Computational Science and Engineering. 

Excellent knowledge of high-level programming languages, such as C / C ++ / 
Python; Use of advanced software libraries for Scientific Computing; Finite 
element discretization techniques.

Luca Heltai

--
Luca Heltai 
http://people.sissa.it/~heltai/
Scuola Internazionale Superiore di Studi Avanzati
Phone:  +39 040 3787 449, Office: 608
--
There are no answers, only cross references.

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

2018-03-13 Thread luca.heltai
Kurt, 

in principle deal.II does not require OCE. It can work also with OCCT (it will 
use whatever it finds available, unless someone changed this behaviour).

When OCCT will be packaged into debian, I’m sure we can make dealii use that 
instead of OCE.

Best,
Luca.

> On 11 Mar 2018, at 4:29, Kurt Kremitzki  wrote:
> 
> Hello,
> 
> I work with the FreeCAD project and have been working on getting OCCT 7.2.0 
> back into Debian (for those not aware, it was removed from license reasons 
> and replaced with OCE.) However development on OCE has slowed while the pace 
> has picked up for OCCT, resulting in several improvements we'll need for our 
> upcoming 0.17 release.
> 
> Since deal.II depends on OCE, I wanted to reach out to all of you to let you 
> know that at some point Debian will likely want to replace liboce in the 
> repositories altogether with libocct. FreeCAD, netgen, and deal.II are the 
> only dependencies there that I know of; since FreeCAD uses netgen, I've 
> already successfully built the first 2 from libocct.
> 
> However, I am not familiar with deal.II so my introductory attempt to build 
> using libocct didn't work. While I will eventually have some time to look at 
> it further, I was hoping that by announcing this in advance someone in the 
> deal.II community could take a look before there's any pressure for the 
> removal of liboce in Debian.
> 
> By the way, the packages are not in Debian Sid yet, but I hope/assume they 
> will be soon. For the time being they need to be built from the git 
> repository at https://salsa.debian.org/kkremitzki-guest/opencascade.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Automatic refinement with minimal level of refinement

2018-02-19 Thread luca.heltai
After you have created your coarse mesh, you could 
GridTools::flatten_triangulation it. This will create a brand new coarse 
triangulation, containing only all your active cells.

L. 

> On 19 Feb 2018, at 13:35, Lucas Campos  wrote:
> 
> Dear all,
> 
> I am creating a mesh using GridGenerator::hyper_shell. In this mesh, I want 
> to divide the mesh into 
> two distinct subdomains, radially. In order to do that, I need to refine the 
> mesh at least once. Each 
> of these cells carries an internal state that depends on its kind.
> 
> The issue I have is that, while improbable, in theory it is possible for 
> GridRefinement::refine_and_coarsen_fixed_number to merge these cells back, 
> which 
> would be a mistake. Is there a way either configure the triangulation to 
> consider the once refined 
> state the coarsest possible?
> 
> The other solution I see is to "manually" input the once-refined mesh and 
> then use 
> create_triangulation, but that sounds cumbersome and error-prone.
> 
> Bests,
> Lucas Campos
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Neighbors search within a particular radius of an element

2018-01-25 Thread luca.heltai
You could use KDTree, based on nanoflann. 

If you installed the development version of dealii with NANOFLANN support, then 
you’d have access to algorithms that work in order log(N) complexity for each 
search, and N log(N) to build the tree. 

You’d have to massage it a little, as at the moment it does not use cells but 
points. I’d construct a vector of active cell centers, and use kdtree on this 
vector to obtain the “k nearest neighbours”  (get_closest_points), as well as 
"neighbours within distance” (get_points_within_ball).

http://dealii.org/developer/doxygen/deal.II/classKDTree.html

L.

> On 24 Jan 2018, at 21:37, Sukhminder Singh  wrote:
> 
> Is there any way to find element neighbors with in a particular radius from 
> its center? One approach is to compare distance with every other element in 
> the whole mesh but then the algorithmic complexity will be O(N^2). Another 
> approach is to map all the elements to a coarse structured grid with h=radius 
> and assign each element a cell number of this structured grid. Then I know 
> what are the neighbors of an element which lie in the same cell of the grid 
> and then check the distance only with these neighbors (this will have O(N) 
> algorithmic complexity).
> Is there any simpler way to find neighbors in Dealii, in MPI parallel 
> framework? 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Re: Creation of own CMakeLists.txt

2018-01-11 Thread luca.heltai
Take a look at this:

https://github.com/luca-heltai/bare-dealii-app

it is a bare structure, for medium to large size problems, with separate 
source/include/tests directories, that support travis CI integration.

L. 

> On 11 Jan 2018, at 15:52, 'Maxi Miller' via deal.II User Group 
>  wrote:
> 
> An initial investigation shows that DEAL_II_INVOKE_AUTOPILOT calls 
> add_executable, thus I placed the additional libraries after the macro. Is 
> that the correct way to solve it?
> 
> Am Donnerstag, 11. Januar 2018 14:00:28 UTC+1 schrieb Maxi Miller:
> Hei,
> I tried to create my own CMakeLists-file, in order to include a second 
> project (which provides a shared library, which should be coupled to the main 
> executable). Thus my CMakeLists-file looks now like
> # Set the name of the project and target:
> set(CMAKE_C_COMPILER /usr/lib64/mpi/gcc/openmpi3/bin/mpicc)
> set(CMAKE_CXX_COMPILER /usr/lib64/mpi/gcc/openmpi3/bin/mpic++)
> set(TARGET "main")
> PROJECT(${TARGET})
> set(CMAKE_BUILD_TYPE Debug)
> cmake_policy(SET CMP0015 NEW)
> cmake_policy(SET CMP0003 NEW)
> include_directories("include" 
> "../pulse_propagation/include"
> "/opt/dealii/include"
> "/opt/trilinos/include"
> "/opt/intel/tbb/include"
> "/opt/petsc/include"
> "/opt/slepc/include"
> "/opt/p4est/include")
> file(GLOB_RECURSE TARGET_SRC  "source/*.cpp")
> file(GLOB_RECURSE TARGET_INC  "include/*.h" )
> 
> SET(TARGET_SRC ${TARGET_SRC}  ${TARGET_INC})
> add_executable(${TARGET} ${TARGET_SRC})
> find_library(PULSE_LIBRARY pulse_propagation HINT ../pulse_propagation/)
> find_library(FILESYSTEM boost_filesystem)
> target_link_libraries(${TARGET} ${FILESYSTEM} ${PULSE_LIBRARY})
> # Usually, you will not need to modify anything beyond this point...
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)
> 
> FIND_PACKAGE(deal.II 9.0.0 QUIET
>   HINTS ${deal.II_DIR} ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
>   )
> IF(NOT ${deal.II_FOUND})
>   MESSAGE(FATAL_ERROR "\n"
> "*** Could not locate a (sufficiently recent) version of deal.II. ***\n\n"
> "You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to 
> cmake\n"
> "or set an environment variable \"DEAL_II_DIR\" that contains this path."
> )
> ENDIF()
> 
> 
> DEAL_II_INITIALIZE_CACHED_VARIABLES()
> SET(CLEAN_UP_FILES *.log *.*tu* *.gmv *.gnuplot *.gpl *.eps *.pov *.vtk *.ucd 
> *.d2 *.vtu *.pvtu)
> #PROJECT(${TARGET})
> DEAL_II_INVOKE_AUTOPILOT()
> But now the command "DEAL_II_INVOKE_AUTOPILOT()" results in the error 
>   ADD_EXECUTABLE cannot create target "main" because another target with the
>   same name already exists.  The existing target is an executable created in
>   source directory
>   "~/Documents/heat_equation_with_pulse_propagation/heat_equation".
>   See documentation for policy CMP0002 for more details.
> Call Stack (most recent call first):
>   CMakeLists.txt:44 (DEAL_II_INVOKE_AUTOPILOT)
> 
> Removing the command "add_executable" results in 
> CMake Error at CMakeLists.txt:24 (target_link_libraries):
>   Cannot specify link libraries for target "main" which is not built by this
>   project.
> 
> What do I have to fix in order to remove the collision with 
> DEAL_II_INVOKE_AUTOPILOT?
> Thanks!
> 
> 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> 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] New deal.II 8.5.1 is 20% slower than deal.II 8.0.0

2017-12-31 Thread luca.heltai
This depends on the finite element. For FEQ, yes, for other finite elements, 
definitely not (RaviarThomas, Nedelec, etc.).

Also, the code was wrong with the numbering, of course. On the left you should 
put the global dof number associated to i, not i. 

Even if the local matrix is identical, storing it with the correct numbering 
into a big sparse matrix is only marginally expensive, while saving a lot in 
extracting local dofs.

One vmult, followed by memory contiguous access at every cell, is much cheaper 
than searching in the global vector for local dofs, then performing one local 
multiplication (maybe with one identical Vandermonde matrix).

L. 

> On 31 Dec 2017, at 6:09, Praveen C <cprav...@gmail.com> wrote:
> 
> 
> 
>> On 30-Dec-2017, at 11:40 PM, luca.heltai <luca.hel...@gmail.com> wrote:
>> 
>> I’m thinking of a matrix of size (n_quadrature_points x n_active_cells) x 
>> n_dofs, and then  you slice the results cellwise instead of repeatedly 
>> calling get_function_values.
>> 
>> once:
>> 
>> M[q+active_cell_index*n_dofs_per_cell, i] = fe_values.shape_value(i,q);
> 
> This looks like a Vandermonde matrix which would be identical on every cell. 
> In that case, it is not necessary to store it for every cell.
> 
> 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.
> 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] New deal.II 8.5.1 is 20% slower than deal.II 8.0.0

2017-12-30 Thread luca.heltai
If all you are solving is a two dimensional problem, you could encode your 
“get_function_values” into a matrix vector multiplication to drastically 
improve the situation. 

I’m thinking of a matrix of size (n_quadrature_points x n_active_cells) x 
n_dofs, and then  you slice the results cellwise instead of repeatedly calling 
get_function_values.

once:

M[q+active_cell_index*n_dofs_per_cell, i] = fe_values.shape_value(i,q);

at every solution step, before you actually need the values:
M.vmult(values, solution);

in every cell:
local_values = ArrayView(values[active_cell_index*n_dofs_per_cell], 
n_dofs_per_cell)

L.


> On 27 Dec 2017, at 14:16, drgulev...@gmail.com wrote:
> 
> Thank you! 
> 
> Some guidance how I could optimize the code would be appreciated. I am using 
> deal.II for solving a time-dependent nonlinear 2D problem (sort of 
> sine-Gordon, but a more advanced model which includes a history dependence, 
> https://github.com/drgulevich/mitmojco). Most of the time the deal.II code 
> spends in:
> 
> 1. fe_values.get_function_values -- most of the wall time (70%)
> 2. fe_values.reinit -- less often
> 3. CG solver -- even less often
> 
> Kind regards,
> Dmitry
> 
> On Wednesday, December 27, 2017 at 11:49:42 AM UTC+3, Martin Kronbichler 
> wrote:
> In general, we strive to make deal.II faster with new releases, and for many 
> cases that is also true as I can confirm from my applications. I have ran 
> step-23 on release 8.0 as well as the current development sources and I can 
> confirm that the new version is slower on my machine. If I disable output of 
> step-23, I get a run time of 4.7 seconds for version 8.0 and 5.3 seconds for 
> the current version. After some investigations I found out that while some 
> solver-related operations got faster indeed (the problem with   16k dofs 
> is small enough to run from L3 cache in my case), we are slower in the 
> FEValues::reinit() calls. This call appears in 
> VectorTools::create_right_hand_side() and the 
> VectorTools::interpolate_boundary_values in the time loop. The reason for 
> this is that we nowadays call 
> "MappingQGeneric::compute_mapping_support_points" also for the   bilinear 
> mapping MappingQ1, which allocates and de-allocates a vector. While this is 
> uncritical on higher order mappings, in 2D with linear shape functions the 
> time spent there is indeed not negligible. This is indeed unfortunate for 
> your use case, but I want to stress that the changes were made in the hope to 
> make that part of the code more reliable. Furthermore, those parts of the 
> code are not performance critical and not accurately tracked. It is a rather 
> isolated issue that got worse here, so from this   single example one 
> definitely not say that we are going the wrong direction as a project.
> While there are plenty of things I could imagine to make this particular case 
> more efficient in the application code, way beyond the performance of what 
> the version 8.0 provided - note that I would not write the code like that if 
> it were performance critical - the only obvious thing is that we could try to 
> work around the memory allocations by not returning a vector in 
> MappingQGeneric::compute_mapping_support_points but rather fill an existing 
> array in MappingQGeneric::InternalData::mapping_support_points. Nobody of us 
> developers has this high on the priority list right now, but we would 
> definitely appreciate if some of our users, like you, wants to look into 
> that. I could guide you to the right spots.
> 
> Best regards,
> Martin
> 
> On 26.12.2017 21:22, drgul...@gmail.com wrote:
>> Yes, the two are attached. The key lines from their diff result:
>> 
>> $ diff detailed.log-v8.1.0 detailed.log-v8.5.1
>> ...
>> < #  Compiler flags used for this build:
>> < #CMAKE_CXX_FLAGS:  -pedantic -fpic -Wall 
>> -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch 
>> -Wno-unused-local-typedefs -Wno-long-long -Wno-deprecated 
>> -Wno-deprecated-declarations -std=c++11 -Wno-parentheses -Wno-long-long
>> < #DEAL_II_CXX_FLAGS_RELEASE:-O2 -funroll-loops 
>> -funroll-all-loops -fstrict-aliasing -Wno-unused
>> ---
>> > #  Base configuration (prior to feature configuration):
>> > #DEAL_II_CXX_FLAGS:-pedantic -fPIC -Wall -Wextra 
>> > -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch 
>> > -Woverloaded-virtual -Wno-long-long -Wno-deprecated-declarations 
>> > -Wno-literal-suffix -std=c++11
>> > #DEAL_II_CXX_FLAGS_RELEASE:-O2 -funroll-loops 
>> > -funroll-all-loops -fstrict-aliasing -Wno-unused-local-typedefs
>> 18c19
>> < #DEAL_II_LINKER_FLAGS: -Wl,--as-needed -rdynamic -pthread
>> ---
>> > #DEAL_II_LINKER_FLAGS: -Wl,--as-needed -rdynamic 
>> > -fuse-ld=gold
>> ...
>> > #BOOST_CXX_FLAGS = -Wno-unused-local-typedefs
>> ...
>> > #  ( DEAL_II_WITH_BZIP2 = OFF )
>> > #DEAL_II_WITH_CXX11 = ON
>> 

Re: [deal.II] Re: Why does the L2-norm increase when the number of nodes becomes too large?

2017-12-20 Thread luca.heltai
M… 

I’m actually not sure it’s a bug… The point where the error starts growing is 
at 10e-12. This is basically machine precision, considering the fact that you 
are computing the L2 error. 

After you have reached machine precision, any addition you make to that, is 
just roundoff error adding up. This may or may not be a problem, according to 
what finite elements you use, but I’m not surprised that increasing the number 
of dofs, you get higher error.

What’s the tolerance of your solver? Is it a direct or an iterative solver? If 
it is an iterative solver, is the tolerance right around 1e-12?

L.

> On 20 Dec 2017, at 9:47, 'Uwe Köcher' via deal.II User Group 
>  wrote:
> 
> Dear Jie,
> 
> I'm with Bruno, you definately have a bug in your code.
> 
> Maybe the application of the Dirichlet boundary is incorrect. When you use 
> the 1d grid generation
> the left and right boundary nodes are coloured by different numbers. This is 
> a different behaviour
> compared to 2d or 3d grid generation.
> 
> https://www.dealii.org/8.5.0/doxygen/deal.II/namespaceGridGenerator.html#acea0cbcd68e52ce8113d1134b87de403
> 
> Some time ago I had a similar issue (incorrect Dirichlet application). Maybe 
> you should check that
> firstly.
> 
> Kind regards
>   Uwe
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.


[deal.II] Sixth deal.II Users and Developers Workshop - 23 --27 July 2018, Trieste, Italy

2017-12-11 Thread luca.heltai
Dear all, 

registration is now open for the Sixth deal.II Users and Developers Workshop, 
to be held in Trieste@SISSA, from July 23 to July 28.

http://indico.sissa.it/e/sixth-dealii-workshop

The program includes invited talks and discussions by users and developers of 
the deal.II library in areas including:

- use cases and applications of the library,
- what users think would be useful directions for the library to go into,
- things that are missing,
- newer parts of the library.

The workshop will have time for both talks and "hackathon"- or "code jam"-style 
time to work jointly on everyone's projects with plenty of people to ask and 
get help from.

You can submit a talk proposal in one of the following tracks:


Developers' track
Talks dedicated to new features of the library, by long time contributors, or 
deal.II main developers (40 min talks)


Users' track
Talks dedicated to users of the library, showing how they use deal.II in their 
work, and sharing their experience with the library (from 5 to 20 min talks, 
depending on the number of submissions)


Looking forward to seeing you in Trieste!

The deal.II developers.

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

2017-11-22 Thread luca.heltai
Dear Yaakov, 

did you even try google?

:)

google search: dealii isogeometric analysis

https://www.google.it/search?q=dealii+isogeometric+analyis_rd=cr=0=vTkVWvurIcOUaPbVr6AO

gives you as a first result this repository:

https://github.com/mathLab/IGA-dealii

So far it supports single patch IGA, and it contains a version of step-41 that 
uses IGA, as well as a few other tools.

Best,
Luca.


> On 21 Nov 2017, at 22:15, feap...@gmail.com wrote:
> 
> Hi Bruno,
> 
> As Isogometric Analysis is very popular in solid & fluid mechanics now. I 
> would know, does Deal.II 8.5.0 contain Isogometric Analysis library?
> 
> Regards,
> Yaakov
> 
> 
> On Tuesday, November 21, 2017 at 8:35:38 PM UTC+1, Bruno Turcksin wrote:
> Yaakov,
> 
> This is not my area of expertise but I guess you will want to take a look at 
> http://dealii.org/8.5.0/doxygen/deal.II/step_54.html 
> 
> Best,
> 
> Bruno
> 
> On Tuesday, November 21, 2017 at 12:17:25 PM UTC-5, fea...@gmail.com wrote:
> Dear Deal.II Team & User,
> 
> I would like to ask a question:
> 
> Can I solve Isgometric Analysis problems (single or multipatchs)?
> 
> Warm regards,
> Yaakov
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] A cube rather than a ball with GridGenerator::hyper_ball

2017-11-17 Thread luca.heltai
Dear Alberto,


>   GridGenerator::hyper_ball ( triangulation, center, cell_radius );
> 
>   static SphericalManifold volume_boundary;
> 
>   
>   triangulation.refine_global ( 3 );
> 
>   triangulation.set_all_manifold_ids_on_boundary(0);
> 
>   triangulation.set_manifold (0, volume_boundary);


You should put the `refine_global` **after** set_manifold.

Now you are refining a coarse hyperball (a cube) and then you are attaching a 
manifold. You should first attach the manifold, then refine.

Best,
Luca.

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

2017-11-09 Thread luca.heltai
It does not compile, anyway…

:D 

Maybe Denis can help: I get the following when trying to compile pkg-config 
using gcc installed with spack:

In file included from 
/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32:0,
 from 
/System/Library/Frameworks/Security.framework/Headers/Security.h:43,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:27,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:22,
 from 
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
 from gunicollate.c:30:
/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: 
error: variably modified ‘bytes’ at file scope
  char bytes[kAuthorizationExternalFormLength];
   ^
make[6]: *** [libglib_2_0_la-gunicollate.lo] Error 1
make[5]: *** [all-recursive] Error 1
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

L.

> On 9 Nov 2017, at 23:09, Timo Heister  wrote:
> 
>> I'm using clang+gfortran. I have not tried using gcc for everything, but I 
>> could give it a shot if you think it would be worth it.
> 
> No, I was just curious. I don't have a strong preference for either.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Re: New Mac OSX brew package

2017-11-09 Thread luca.heltai
Oh, and naturally ’s/brew/spack/g’ in my previous email.


clang --version
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

and 

gfortran --version
GNU Fortran (GCC) 7.2.0
Copyright (C) 2017 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.
/Applications/deal.II-9.0-spack.app/Contents/Resources/spack/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-zjkdy42fjmlapty3f7khykdwz4366mwt/bin/gfortran


> On 9 Nov 2017, at 19:21, Denis Davydov  wrote:
> 
> nice!
> 
> @Timo: If I am not mistaken, it's Apple's Clang 9.0.0 + gfortran 7.2.0.  
> 
> On Thursday, November 9, 2017 at 9:41:52 AM UTC+1, Luca Heltai wrote:
> Dear All, 
> 
> I just finished uploading a new brew based package for deal.II with a 
> 9.0pre.1 version: 
> 
> https://github.com/luca-heltai/dealii/releases/tag/v9.0.pre.1 
> 
> It was compiled on a Mac OS X High Sierra: 10.13 (17A405), with Xcode 9.0.1 
> (9A1004). 
> 
> The application contains a full `spack` installation at 
> 
> `/Applications/deal.II-9.0-spack/Contents/Resources/spack` 
> 
> You’ll have access to all spack facilities (including modules) by adding 
> 
> . 
> /Applications/deal.II-9.0-spack.app/Contents/Resources/share/deal.II/dealii.conf
>  
> 
> to your ~/.profile file. 
> 
> Summary.log: 
> 
> ### 
> # 
> #  deal.II configuration: 
> #CMAKE_BUILD_TYPE:   DebugRelease 
> #BUILD_SHARED_LIBS:  ON 
> #CMAKE_INSTALL_PREFIX:   
> /Applications/deal.II-9.0-spack.app/Contents/Resources 
> #CMAKE_SOURCE_DIR:   /Users/heltai/dealii/dealii 
> #(version 9.0.0-pre, shortrev 88babf1a4d) 
> #CMAKE_BINARY_DIR:   /Users/heltai/dealii/dealii/build-9.0-spack 
> #CMAKE_CXX_COMPILER: AppleClang 9.0.0.938 on platform Darwin 
> x86_64 
> #
> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/bin/mpic++ 
> # 
> #  Configured Features (DEAL_II_ALLOW_BUNDLED = ON, 
> DEAL_II_ALLOW_AUTODETECTION = ON): 
> #  ( DEAL_II_WITH_64BIT_INDICES = OFF ) 
> #DEAL_II_WITH_ADOLC set up with external dependencies 
> #DEAL_II_WITH_ARPACK set up with external dependencies 
> #DEAL_II_WITH_ASSIMP set up with external dependencies 
> #DEAL_II_WITH_BOOST set up with external dependencies 
> #  ( DEAL_II_WITH_CUDA = OFF ) 
> #DEAL_II_WITH_CXX14 = ON 
> #DEAL_II_WITH_CXX17 = ON 
> #DEAL_II_WITH_GSL set up with external dependencies 
> #DEAL_II_WITH_HDF5 set up with external dependencies 
> #DEAL_II_WITH_LAPACK set up with external dependencies 
> #DEAL_II_WITH_METIS set up with external dependencies 
> #DEAL_II_WITH_MPI set up with external dependencies 
> #DEAL_II_WITH_MUPARSER set up with external dependencies 
> #DEAL_II_WITH_NANOFLANN set up with external dependencies 
> #DEAL_II_WITH_NETCDF set up with external dependencies 
> #DEAL_II_WITH_OPENCASCADE set up with external dependencies 
> #DEAL_II_WITH_P4EST set up with external dependencies 
> #DEAL_II_WITH_PETSC set up with external dependencies 
> #DEAL_II_WITH_SLEPC set up with external dependencies 
> #DEAL_II_WITH_SUNDIALS set up with external dependencies 
> #DEAL_II_WITH_THREADS set up with external dependencies 
> #DEAL_II_WITH_TRILINOS set up with external dependencies 
> #DEAL_II_WITH_UMFPACK set up with external dependencies 
> #DEAL_II_WITH_ZLIB set up with external dependencies 
> # 
> #  Component configuration: 
> #  ( DEAL_II_COMPONENT_DOCUMENTATION = OFF ) 
> #  ( DEAL_II_COMPONENT_EXAMPLES = OFF ) 
> #DEAL_II_COMPONENT_PACKAGE 
> #  ( DEAL_II_COMPONENT_PYTHON_BINDINGS = OFF ) 
> # 
> #  Detailed information (compiler flags, feature configuration) can be found 
> in detailed.log 
> # 
> #  Run  $ ninja info  to print a help message with a list of top level 
> targets 
> # 
> ### 
> 
> And this is the output of spack find: 
> 
> ==> 74 installed packages. 
> -- darwin-highsierra-x86_64 / clang@9.0.0-apple - 
> adol-c@develop  freetype@2.7.1lcms@2.8 
> nasm@2.11.06pkg-config@0.29.2 
> arpack-ng@3.5.0 gcc@7.2.0 libjpeg-turbo@1.5.0  
> ncurses@6.0 python@2.7.14 
> assimp@4.0.1gdbm@1.13 libpng@1.6.29
> net...@4.4.1.1  readline@7.0 
> astyle@2.04 get...@0.19.8.1  libsigsegv@2.11  
> netcdf-cxx@4.2  slepc@3.8.0 
> autoconf@2.69   ghostscript@9.21  libtiff@4.0.8
> netlib-scalapack@2.0.2  sqlite@3.20.0 
> 

Re: [deal.II] A few questions

2017-11-08 Thread luca.heltai

>> — Are there any applications with immersed FEM (cut-cell, etc.) with deal.II?

Yes. There are at least two open source codes, published on “Archive of 
Numerical Software”:

http://journals.ub.uni-heidelberg.de/index.php/ans/issue/view/2930

"Carraro, Wetterauer: On the implementation of the eXtended Finite Element 
Method (XFEM) for interface problems”

and 

http://journals.ub.uni-heidelberg.de/index.php/ans/issue/view/1724

"Heltai, Roy, Costanzo: A Fully Coupled Immersed Finite Element Method for 
Fluid Structure Interaction via the deal.II Library”

Best,
Luca.

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

2017-10-11 Thread luca.heltai
Yes. It is trying to use the accelerate framework, but since it was installed 
using 10.12, it links to that one. 

If you install the 10.12 SDK you should have what you need.

L.

> On 11 Oct 2017, at 8:58, Alberto Salvadori  wrote:
> 
> 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.

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

2017-09-19 Thread luca.heltai
Dear Lucas, 

you could use GridTools::remove_anisotropy

Best,
Luca. 

> On 18 Sep 2017, at 16:29, Lucas Campos  wrote:
> 
> Dear Bruno,
> 
> You will find attached the resulting grids. While I originally expected to 
> find new divisions only along the x-direction, your previous answer tells me 
> it actually cuts in some local coordinate (whatever that might be). In this 
> case, what is the best way to refine the cylinder in a single direction? I 
> tried adding an if(cell->boundary_id() == 0) before setting the flag, but it 
> did not really help. The mesh is still being refined in all directions.
> 
> I ask this because I plan to do some transformations on this cylinder, to 
> turn it into a coil. In this case, the final result is much better if there 
> are enough cuts in the x-axis.
> 
> Bests
> 
> On Monday, 18 September 2017 14:44:40 UTC+2, Bruno Turcksin wrote:
> Lucas,
> 
> On Monday, September 18, 2017 at 3:50:20 AM UTC-4, Lucas Campos wrote:
> I am trying to refine a cylinder in the x direction only, but it seems that 
> when I use 
> 
> > cell->set_refine_flag(RefinementCase<3>::cut_x);
> 
> the whole cylinder is refined. Indeed, if I run the above line for every 
> active cell *once* I would expect the number of cells to double. However, 
> they quintuple!
> It looks good but how does the mesh look like? Here, you can see that cut_x 
> is in the local coordinate system not the global one. So I would not be 
> surprise if the mesh doesn't look like you think it should. Also if you do 
> more than one refinement you should also use 
> prepare_coarsening_and_refinement() before you refine your mesh.
> 
> 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.
> 

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

2017-06-14 Thread luca.heltai
Felix,

also, if the point you want is not a quadrature point, you can exploit the 
following trick:

Point my_point_in_reference_cell;

std::vector quad(1, my_point_in_reference_cell);

and then you can initialize an 

FEValues fev(fe, quad, update_inverse_jacobians);

This will give you access to what you need by


fev.reinit(cell);
auto _invs = fev.get_inverse_jacobians();

Best,
Luca.

> On 14 Jun 2017, at 2:20, Weixiong Zheng  wrote:
> 
> Felix,
> 
> Would you take a look at if [1] is what you want to have?
> 
> [1]: 
> https://www.dealii.org/8.4.0/doxygen/deal.II/classFEValuesBase.html#a665ab681011424cb1b0ba11c4155a121
> 
> Best,
> Weixiong
> 
> 在 2017年6月13日星期二 UTC-7上午9:35:09,Felix Lorenz写道:
> 
> Hi everyone,
> 
> I want to compute the transformation of a gradient at a point (no quadrature 
> point) on the reference cell to the real space. Mathematically formulated I 
> want to compute:
> 
> 
> 
> 
> 
> 
> 
> How do I get the inverse Jacobian at this point?
> 
> 
> 
> Best regards,
> 
> Felix
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Problem with compiling in macOS sierra, version 10.12.5

2017-06-05 Thread luca.heltai
If you don’t have XCode, then you don’t have XCode tools. You can download 
XCode from the App store.

This error:
>  The CMAKE_C_COMPILER:
> 
> 
> 
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> 
> 
> 
>   is not a full path to an existing compiler tool.

is saying that the application Xcode.app (which is where the command line tools 
are installed), is not there. Install that first.

Best,

Luca. 

> On 5 Jun 2017, at 13:11, Sudarshan Kumar  wrote:
> 
> 
> 
> On Monday, June 5, 2017 at 1:49:01 PM UTC+5:30, Luca Heltai wrote:
> No need to restore to the old version. I have 10.12.5 myself. 
> 
> Can you try running xcode, and see if it asks you wether you want to upgrade 
> the command line tools? 
> 
> 
> I have run the command  "xcode-select --install"  but I do not see Xcode.app 
> in the /Applications  directory, something messed up.
> 
> Still I ge the following  error message in step-1
> 
> -- The C compiler identification is unknown
> 
> CMake Error at CMakeLists.txt:38 (PROJECT):
> 
>   The CMAKE_C_COMPILER:
> 
> 
> 
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> 
> 
> 
>   is not a full path to an existing compiler tool.
> 
> 
> 
>   Tell CMake where to find the compiler by setting either the environment
> 
>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
> 
>   the compiler, or to the compiler name if it is in the PATH.
> 
> 
> 
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeOutput.log".
> 
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeError.log".
> 
>  
> 
> L. 
> 
> > On 5 Jun 2017, at 8:22, Sudarshan Kumar  wrote: 
> > 
> > 
> > 
> > On Monday, June 5, 2017 at 11:39:28 AM UTC+5:30, Luca Heltai wrote: 
> > Did you install xcode and xcode-tools? 
> > 
> > It looks like deal.II cannot find a lot of things… 
> > 
> > The application opens a terminal and tries to figure out if you did. Does 
> > the terminal open up with no issues? 
> > 
> > 
> > Terminal opens with no issue. In fact  I have  upgraded my mac book pro 
> > retina  from yosemite to  sierra.  Do you think  I need to restore back to 
> > my old version? 
> > Thanks in advance.. 
> > L. 
> > 
> > 
> > 
> > > On 5 Jun 2017, at 8:00, Sudarshan Kumar  wrote: 
> > > 
> > > I have  installed deal.II-8.5-brew in my mac  ( macOS sierra, version 
> > > 10.12.5). Failed to compile  step-1 of examples. I have attached the 
> > > error log files. Any help is very much appreciated. 
> > > Thanks a lot in advance. 
> > > 
> > > -- 
> > > The deal.II project is located at http://www.dealii.org/ 
> > > For mailing list/forum options, see 
> > > https://groups.google.com/d/forum/dealii?hl=en 
> > > --- 
> > > You received this message because you are subscribed to the Google Groups 
> > > "deal.II User Group" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to dealii+un...@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+un...@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.

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

2017-06-05 Thread luca.heltai
No need to restore to the old version. I have 10.12.5 myself.

Can you try running xcode, and see if it asks you wether you want to upgrade 
the command line tools?

L.

> On 5 Jun 2017, at 8:22, Sudarshan Kumar  wrote:
> 
> 
> 
> On Monday, June 5, 2017 at 11:39:28 AM UTC+5:30, Luca Heltai wrote:
> Did you install xcode and xcode-tools? 
> 
> It looks like deal.II cannot find a lot of things… 
> 
> The application opens a terminal and tries to figure out if you did. Does the 
> terminal open up with no issues? 
> 
> 
> Terminal opens with no issue. In fact  I have  upgraded my mac book pro 
> retina  from yosemite to  sierra.  Do you think  I need to restore back to my 
> old version? 
> Thanks in advance..
> L. 
> 
> 
> 
> > On 5 Jun 2017, at 8:00, Sudarshan Kumar  wrote: 
> > 
> > I have  installed deal.II-8.5-brew in my mac  ( macOS sierra, version 
> > 10.12.5). Failed to compile  step-1 of examples. I have attached the error 
> > log files. Any help is very much appreciated. 
> > Thanks a lot in advance. 
> > 
> > -- 
> > The deal.II project is located at http://www.dealii.org/ 
> > For mailing list/forum options, see 
> > https://groups.google.com/d/forum/dealii?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "deal.II User Group" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to dealii+un...@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.

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

2017-06-05 Thread luca.heltai
Did you install xcode and xcode-tools? 

It looks like deal.II cannot find a lot of things…

The application opens a terminal and tries to figure out if you did. Does the 
terminal open up with no issues?

L.



> On 5 Jun 2017, at 8:00, Sudarshan Kumar  wrote:
> 
> I have  installed deal.II-8.5-brew in my mac  ( macOS sierra, version 
> 10.12.5). Failed to compile  step-1 of examples. I have attached the error 
> log files. Any help is very much appreciated. 
> Thanks a lot in advance. 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dealii+unsubscr...@googlegroups.com.
> 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] Refining a hyper_ball with a spherical_manifold produces nan values

2017-04-26 Thread luca.heltai
This is actually not a bug. A spherical manifold is undefined on the center of 
the sphere/ball. You cannot attach set_all_manifold_ids of the spherical 
manifold and attach a spherical manifold to it, since the central cell (the one 
where the cell->center() coincides with the ball center) would not know what to 
do.

This is documented in the SphericalManfold documentation. See the phrase "In 
order for this manifold to work correctly, it cannot be attached to cells 
containing the center of the coordinate system. This point is a singular point 
of the coordinate transformation, and there taking averages does not make any 
sense.”

Best,

L.


> On 25 Apr 2017, at 13:42, Alexander Gary Zimmerman 
>  wrote:
> 
> When I refine a Triangulation that has been initialized with 
> GridGenerator::hyper_ball, and has a SphericalManifold attached (and having 
> set_all_manifold_ids on the Triangulation), some nan (not a number) values 
> are produced.
> 
> On the other hand, I get the expected behavior when instead using a 
> GridGenerator::hyper_shell.
> 
> I've documented the issue on my repo here: 
> https://github.com/alexanderzimmerman/nsb-pcm/issues/21
> 
> I'm using deal.II-v.8.5.0. I haven't tried reproducing this on any other 
> versions.
> 
> These are in the repo, but here's the test that passes:
> 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> using namespace dealii;
> 
> const unsigned int dim = 2;
> 
> 
> void validate_vertices(Triangulation )
> {   
> Triangulation::cell_iterator cell;
> 
> unsigned int nv = GeometryInfo::vertices_per_cell;
>   
> for (cell = tria.begin(); cell != tria.end(); ++cell)
> {
> for (unsigned int v = 0; v < nv; ++v)
> {
> for (unsigned int i = 0; i < dim; ++i)
> {
> assert(!numbers::is_nan(cell->vertex(v)[i]));
> }
> 
> }
> 
> }
> 
> }
> 
> 
> int main(int /*argc*/, char** /*argv*/)
> {
> Triangulation triangulation;
> 
> GridGenerator::hyper_shell(triangulation, Point(), 0.1, 0.5);
> 
> const unsigned int manifold_id = 0;
> 
> triangulation.set_all_manifold_ids(manifold_id);
>
> SphericalManifold spherical_manifold;
> 
> triangulation.set_manifold(manifold_id, spherical_manifold);  
>
> GridOut grid_writer;
> 
> 
> for (unsigned int r = 0; r < 2; ++r)
> {
> std::string file_name = "grid_"+std::to_string(r)+".vtk";
> 
> std::ofstream file(file_name);
> 
> grid_writer.write_vtk(triangulation, file);   
> 
> validate_vertices(triangulation);
> 
> triangulation.refine_global(1);
> }
> 
> triangulation.set_manifold(0);
> 
> return 0;
> }
> 
> 
> and here's the test that fails:
> 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> 
> using namespace dealii;
> 
> const unsigned int dim = 2;
> 
> 
> void validate_vertices(Triangulation )
> {   
> Triangulation::cell_iterator cell;
> 
> unsigned int nv = GeometryInfo::vertices_per_cell;
>   
> for (cell = tria.begin(); cell != tria.end(); ++cell)
> {
> for (unsigned int v = 0; v < nv; ++v)
> {
> for (unsigned int i = 0; i < dim; ++i)
> {
> assert(!numbers::is_nan(cell->vertex(v)[i]));
> }
> 
> }
> 
> }
> 
> }
> 
> 
> int main(int /*argc*/, char** /*argv*/)
> {
> Triangulation triangulation;
> 
> GridGenerator::hyper_ball(triangulation);
> 
> const unsigned int manifold_id = 0;
> 
> triangulation.set_all_manifold_ids(manifold_id);
>
> SphericalManifold spherical_manifold;
> 
> triangulation.set_manifold(manifold_id, spherical_manifold);  
>
> GridOut grid_writer;
> 
> 
> for (unsigned int r = 0; r < 2; ++r)
> {
> std::string file_name = "grid_"+std::to_string(r)+".vtk";
> 
> std::ofstream file(file_name);
> 
> grid_writer.write_vtk(triangulation, file);   
> 
> validate_vertices(triangulation);
> 
> triangulation.refine_global(1);
> }
> 
> triangulation.set_manifold(0);
> 
> return 0;
> }
> 
> 
> Any ideas?
> 
> Thanks,
> 
> Alex
> 
> P.S. for future reference, if I have an issue formulated like this, should I 
> raise it on the deal.II repo or here in the mailing list?
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II 

Re: [deal.II] Re: Unable to download dealii-8.4.1 for Mac

2017-04-09 Thread luca.heltai
Same here. I can download the package both from home and from my office.

L. 

> On 8 Apr 2017, at 18:35, Daniel Arndt  
> wrote:
> 
> Ana,
> 
> I can't confirm your problem. Downloading works without issues. What browser 
> are you using? Do you get any warnings?
> 
> Best,
> Daniel
> 
> Am Samstag, 8. April 2017 16:39:34 UTC+2 schrieb Ana Marija:
> Hi,
> 
> For a few days I am unable to download installation for MAC, it always fails 
> around 90MB
> https://dealii.org/download.html
> Can you please check what is going on with that?
> 
> Thanks
> Ana
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Re: Finite Element Method for Two Phase Flow

2017-04-09 Thread luca.heltai
Or, you could use as a stable pair of finite elements the FE_Q(k)-FE_DGP(k-1) 
pair:

D. Boffi and L. Gastaldi. On the quadrilateral Q2-P1 element for the Stokes 
problem. Int. J. Numer. Meth. Fluids, 39 (2002), 1001-1011.

This pair of finite elements is known to produce consistently better results 
for discontinuous pressures (after all, p is only supposed to be in L2).

L.

> On 7 Apr 2017, at 23:51, Sumedh Yadav  wrote:
> 
> 
> I would like to add an idea I intend to apply but right now am clueless of 
> how to apply.
> In the earlier post I mentioned issue of 'spurious currents'. In the past 
> researchers have tried quite a few approaches to handle this. One of them 
> involves reconstruction of computed pressure field. In essence if you look 
> carefully at the images I shared in the last post you can see the failure of 
> taylor-hood elements to handle the discontinuity in pressure which in turn 
> makes the velocity field oscillatory/spurious. Reconstruction of pressure is 
> done only in the interface region by interpolating the local normal direction 
> values of pressure inside and outside this interface region. I am able to 
> construct the normal field necessary for this local reconstruction. But I 
> need to traverse to neighboring cells in both directions of this normal 
> vector in the interface cells. I am clueless to how this can be done in 
> deal.ii. The normal field image - 
> 
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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 can I resize a std::vector<Functions::ParsedFunction>?

2017-03-23 Thread luca.heltai
Resizing is fine. It is the equality that won’t work:

function_pointers[f] = 
 std::shared_ptr(new 
dealii::Functions::ParsedFunction()));

is the correct way to do it. 

L.


> On 23 Mar 2017, at 15:09, Alex Zimmerman  wrote:
> 
> Also for the record, here's a copy of issue_10_push_back.cc from that 
> repository, which is the example of how to solve my issue:
> 
> #include 
> 
> #include 
> #include  
> 
> int main(int /*argc*/, char** /*argv*/)
> {
> const unsigned int dim = 2;
> const unsigned int function_count = 4;
> 
> std::vector>
> function_pointers;
> 
> dealii::ParameterHandler prm;
> dealii::Point point;
> double value;
> 
> for (unsigned int f = 0; f < function_count; ++f)
> {
> function_pointers.push_back(
> std::shared_ptr(new 
> dealii::Functions::ParsedFunction()));
> 
> prm.enter_subsection("parsed_function_"+std::to_string(f));
> {
> function_pointers[f]->declare_parameters(prm);
> function_pointers[f]->parse_parameters(prm);
> }
> prm.leave_subsection();
> 
> function_pointers[f]->value(point, value);
> 
> std::cout << "f(" << point << ") = " << value << std::endl;
> }
> 
> return 0;
> }
> 
> 
> On Thursday, March 23, 2017 at 3:05:53 PM UTC+1, Alex Zimmerman wrote:
> Timo, thanks for the extra clarification. As I mentioned in my reply to Luca, 
> I don't understand why declare_parameters appeared to succeed in my test, 
> which failed at parse_parameters.
> 
> My issue is solved using the vector.push_back(new 
> ParsedFunction) approach. My attempt at the resize approach isn't working; 
> but push_back is fine. 
> 
> Related test code is here: 
> https://github.com/alexanderzimmerman/nsb-pcm/tree/bugs/tests
> ctest passes all tests except for issue_10_resize.cc. I'm guessing that I 
> have the syntax wrong somewhere.
> 
> Thanks for the help!
> 
> 
> On Wednesday, March 22, 2017 at 10:01:21 PM UTC+1, Timo Heister wrote:
> Your call to resize() will create 4 shared_ptrs, but they are pointing 
> to nothing (NULL) because you are never allocating any objects and 
> assigning them. 
> 
> Think of this example: 
> std::vector v; 
> v.resize(4); 
> now v[0] is a pointer to an int, but it is NULL unless you do something like 
> v[0] = new int; 
> 
> 
> 
> On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman 
>  wrote: 
> > Also for the record, I verified that the test passes if I use a 
> > std::vector without resizing: 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_blob_bugs_tests_bug-5F10-5Fpass.cc=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=v1-30ZnlLX9dscEMGIPAxToOfyXrgOcTjUUS54eVdJA=
> >  
> > 
> > 
> > 
> > On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman wrote: 
> >> 
> >> Luca, 
> >> 
> >> Thanks for the idea. Conceptually I don't understand how a shared_ptr 
> >> solves my problem. I can resize 
> >> std::vector>; but 
> >> all of the shared pointers are empty. I imagine that they are supposed to 
> >> point to ParsedFunction objects that I've instantiated somewhere. 
> >> 
> >> That being said, I think you are leading me in the correct direction. In 
> >> the following test code, "default.prm" is successfully generated with the 
> >> four parsed function sections. It seg faults when I call parse_parameters; 
> >> so I'm still debugging: 
> >> 
> >> #include  
> >> 
> >> #include  
> >> #include  
> >> 
> >> int main(int /*argc*/, char** /*argv*/) 
> >> { 
> >> const unsigned int dim = 2; 
> >> const unsigned int function_count = 4; 
> >> 
> >> std::vector> 
> >> function_pointers; 
> >> 
> >> function_pointers.resize(function_count); 
> >> 
> >> dealii::ParameterHandler prm; 
> >> 
> >> for (unsigned int f = 0; f < function_count; ++f) 
> >> { 
> >> prm.enter_subsection("parsed_function_"+std::to_string(f)); 
> >> { 
> >> function_pointers[f]->declare_parameters(prm); 
> >> } 
> >> prm.leave_subsection(); 
> >> } 
> >> 
> >> prm.read_input("default.prm", false, true); 
> >> 
> >> for (unsigned int f = 0; f < function_count; ++f) 
> >> { 
> >> prm.enter_subsection("parsed_function_"+std::to_string(f)); 
> >> { 
> >> function_pointers[f]->parse_parameters(prm); 
> >> } 
> >> prm.leave_subsection(); 
> >> } 
> >> 
> >> return 0; 
> >> } 
> >> 
> >> Thanks, 
> >> 
> >> Alex 
> >> 
> >> On Wednesday, March 22, 2017 at 

Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-22 Thread luca.heltai
Hi Alex, 

I’d use a vector of 

std::vector > v;

which are light objects, and can be resized and reshaped. Whenever you do a 
push_back, you’d have to use

v.push_back(std_cxx11::shared_pointervalue(…)

would work.


> On 22 Mar 2017, at 16:31, Alex Zimmerman  wrote:
> 
> Fundamentally I am trying to allow for a variable number of ParsedFunction 
> objects to be specified in a parameter input file. Maybe there is a better 
> approach which circumvents my issue below. I can continue my work for some 
> time with this being a constant; but as soon as I want to extend to 3D or 
> different geometries, this will be a roadblock.
> 
> I've documented my issue on my GitHub repostiory: 
> https://github.com/alexanderzimmerman/nsb-pcm/issues/10 . Here's a copy of 
> the text from my issue, which pretty much explains it:
> 
> Attempting to resize or push_back into a 
> std::vector throws an error within TBB and/or 
> mu::Parser, e.g.:
> 
> In file included from /usr/include/c++/4.8/vector:64:0,
> 
> from /usr/include/c++/4.8/bits/random.h:34,
> 
> from /usr/include/c++/4.8/random:50,
> 
> from /usr/include/c++/4.8/bits/stl_algo.h:65,
> 
> from /usr/include/c++/4.8/algorithm:62,
> 
> from 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/concurrent_vector.h:48,
> 
> from 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:32,
> 
> from 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/base/thread_local_storage.h:23,
> 
> from 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/base/logstream.h:23,
> 
> from 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/lac/vector.h:21,
> 
> from /mnt/c/Users/Alex/UbuntuShared/nsb-pcm/tests/peclet_data.cc:1:
> 
> /usr/include/c++/4.8/bits/stl_vector.h: In instantiation of 
> ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = mu::Parser; 
> _Alloc = std::allocatormu::Parser]’:
> 
> /usr/include/c++/4.8/bits/stl_vector.h:416:33: required from 
> ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = mu::Parser; _Alloc = 
> std::allocatormu::Parser]’
> 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:659:17:
>  required from ‘void tbb::interface6::internal::ets_element ModularSize>::unconstruct() [with U = std::vectormu::Parser; long unsigned 
> int ModularSize = 24ul]’
> 
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:729:17:
>  required from ‘void tbb::interface6::enumerable_thread_specific Allocator, ETS_key_type>::unconstruct_locals() [with T = 
> std::vectormu::Parser; Allocator = 
> tbb::cache_aligned_allocator; tbb::ets_key_usage_type 
> ETS_key_type = (tbb::ets_key_usage_type)1u]’
> 
> Because of this issue, the number of boundaries on the domain must be known 
> at compile time (i.e. they can't be set in the input parameter file), so that 
> the proper number of ParsedFunction objects can be allocated.
> 
> Maybe ParsedFunction does not mean these requirements: 
> http://stackoverflow.com/questions/12251368/type-requirements-for-stdvectortype
> 
> 
> This might be a bug, or rather missing functionality, in ParsedFunction. But 
> I'm still fairly new to deal.II and to C++; so I think it's more likely that 
> I'm doing something wrong.
> 
> The repository includes a branch with test code that reproduces the compiler 
> error. The test source code is linked in the issue (on the bugs branch).
> 
> Any ideas?
> 
> 
> Thanks,
> 
> Alex
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Neumann vector conditions

2017-02-17 Thread luca.heltai

> On 17 Feb 2017, at 14:46, Franco Milicchio  wrote:
> 
> I agree I have a translation problem here. In practice, I am integrating a 
> weak problem as this (in Fenics' UFL terms, but easy to recognize):
> 
> 
> inner( sigma(u), eps(v) ) * dx = inner(f, v) * dx + inner(f1, v) * ds(1)


I’m guessing that 

f1 = sigma(u) n 

is the Neumann data on the boundary. Then if you have f1 as a dim-dimensional 
vector field, it already contains n. 

the translation from ufl to deal.II is easy:


ds(1) =>  fe_face_values.JxW(f_q_point); 
v => fe_face_values.shape_value(i, f_q_point)
f1 =>  rhs_face_values[f_q_point]

since fe_face_values.shape_value(i, f_q_point) refers to the component_i of v, 
then

inner(f1, v) *ds(1) = sum over q of 

fe_face_values.shape_value(i, f_q_point) * 
rhs_face_values[f_q_point][component_i]) * fe_face_values.JxW(f_q_point); 


> where f is a bulk force (zero in my code), f1 is a (distributed) force 
> applied to the top boundary. The dx and ds terms refer to the integral on the 
> domain and boundary; u is the displacement, and v is the test function. Sigma 
> and eps are functions that compute, obviously, stress and strain tensors.
> 
> As I said, Fenics hid everything as you see above, but I am very eager to let 
> it go as soon as possible.
> 
>  
> and while you can certainly come up with good reasons for this to work out, 
> I’m unsure about what you want to achieve. If your boundary conditions are 
> 
> ((grad(u)).n,v) = u_i,j n_j v_i 
> 
> and you impose 
> 
> (grad(u).n)_i = f_i 
> 
> on the boundary, then you should have 
> 
> cell_rhs(i) += (fe_face_values.shape_value(i, f_q_point) * 
> rhs_face_values[f_q_point][component_i]) * 
> fe_face_values.JxW(f_q_point); 
> 
> 
> My question here is this: why am I not using the normal to the face?

You are not using it, because you are imposing

sigma(u)n = f

on the boundary (where f is a dim-dimensional vector field on the boundary). 
Even in your FENICS implementation you are not using the normal… 

inner(f1,v)*ds(1) 

does not contain the normal anywhere, only the integral of f_i v_i on the faces 
on the boundary (I guess with id 1).


By the way this is the same for the Poisson problem. If you impose 

u,i n_i = f

then your integral on the boundary becomes

f*v*ds(1)












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

2017-02-17 Thread luca.heltai
Dear Franco,

I think there is a problem in your formulation…

You are integrating 

u_i n_i f_i


and while you can certainly come up with good reasons for this to work out, I’m 
unsure about what you want to achieve. If your boundary conditions are 

((grad(u)).n,v) = u_i,j n_j v_i

and you impose 

(grad(u).n)_i = f_i 

on the boundary, then you should have 

cell_rhs(i) += (fe_face_values.shape_value(i, f_q_point) *
rhs_face_values[f_q_point][component_i]) * 
fe_face_values.JxW(f_q_point);


on the other hand, if you want to have, for example, for a scalar function p, 

u_i,j n_j = p n_i

then you should have

cell_rhs(i) += (fe_face_values.shape_value(i, f_q_point) *
rhs_scalar_function[f_q_point]
fe_face_values.normal_vector(f_q_point)[component_i]
) * fe_face_values.JxW(f_q_point);


What is the exact term you want to integrate?

L.



> On 17 Feb 2017, at 13:03, Franco Milicchio  wrote:
> 
> 
> 
> On Thursday, February 16, 2017 at 7:49:52 PM UTC+1, Jean-Paul Pelteret wrote:
> Dear Franco,
> 
> Super quick answer: Step-44 demonstrates how to implement the Neumann BC for 
> elasticity.
> 
> 
> Thanks for your pointer, Jean-Paul, I appreciate it. I am coming from Fenics, 
> where all these details were completely hidden and almost inaccessible: I 
> just used weak forms there. It was easier but, ultimately, not powerful 
> enough. So this is new to me, I am sorry if I'm asking something trivial.
> 
> I have tried to implement it, but I think I have a wrong result. This is the 
> code I've written:
> 
> // Neumann (boundary forces on top boundary == id 2)
> 
> for (unsigned int face_number = 0; face_number < 
> GeometryInfo::faces_per_cell; ++face_number)
> 
> {
> 
> if (cell->face(face_number)->at_boundary() && 
> (cell->face(face_number)->boundary_id() == 2))
> 
> {
> 
> // Get face FE values for this face and cell
> 
> fe_face_values.reinit(cell, face_number);
> 
> 
> // Neumann force vector on the face
> 
> 
> right_face_side.vector_value_list(fe_face_values.get_quadrature_points(), 
> rhs_face_values);
> 
> 
> 
> for(unsigned int f_q_point = 0; f_q_point < n_face_q_points; 
> ++f_q_point)
> 
> {
> 
> // Add contributions to all DOFs
> 
> for (unsigned int i = 0; i < dofs_per_cell; ++i)
> 
> {
> 
> const unsigned int component_i = 
> fe.system_to_component_index(i).first;
> 
> 
> cell_rhs(i) += (fe_face_values.shape_value(i, 
> f_q_point) *
> 
> 
> rhs_face_values[f_q_point][component_i] *
> 
> 
> fe_face_values.normal_vector(f_q_point)[component_i]
> 
> ) * fe_face_values.JxW(f_q_point);
> 
> }
> 
> } // Integral for linear form
> 
> }
> 
> } // Boundary forces
> 
> 
> My point is to integrate a distributed force f on the top boundary, so as far 
> as I understand this (from the tutorial 44), I have to do cycle over all 
> boundary faces, get values (normals, shape functions, jacobians) and their 
> values on the quadrature points, and finally add them to the right hand side.
> 
> Where is the error?
> 
> Thank you very much!
> Franco
> 
> PS. I am still struggling on some terms in deal.II, as for instance the role 
> of "fe.system_to_component_index(i).first", but I need to write code to 
> understand thoroughly how to switch my codebase from Fenics.
> 
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] Recommendation: BCs in config

2017-02-13 Thread luca.heltai
Actually, you have some alternatives… 

Take a look at this class:

https://github.com/mathLab/deal2lkit/blob/master/include/deal2lkit/parsed_mapped_functions.h

It does something similar to what you are asking for. 

(documentation here:

http://mathlab.github.io/deal2lkit/class_parsed_mapped_functions.html

Best,
Luca.

> On 13 Feb 2017, at 16:49, Bruno Turcksin  wrote:
> 
> 2017-02-13 10:34 GMT-05:00 Franco Milicchio :
>> Because I can imagine that having several BCs with some magic char there is
>> simply a recipe for disaster :)
>> 
>> Just think about this example:
>> 
>>  set dirichlet = x^2+y^2 : if(x < 0, 1, 3) : 0; 0 : 0 : 0
>> 
>> Since I am working with people not well versed in programming, that is
>> quite a concern to me.
> Well then you will need to declare everything in advance. The only
> solution I can think of is to use sth like boost::property_tree
> instead of ParameterHandler.
> 
> 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.

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

2016-12-17 Thread luca.heltai
Dear Joaquin,

as I wrote to you on one of my previous emails, the repository 

https://github.com/luca-heltai/ans-ifem

contains a branch that compiles correctly, without those warnings, on the 
development version of deal.II.

There are some more warnings due to the deprecation of the ‘sadd’ function and 
the ‘read_input’ one if you use the development version. I’m removing these 
now, and I’ll release a new version “warning-free”.

Best,
L.


> On 15 Dec 2016, at 7:16, Jean-Paul Pelteret  wrote:
> 
> Dear Joaquin,
> 
> The warning appears because you are calling a function that is marked as 
> deprecated, so although it remains in the library for now it will be removed 
> in the near future.
> 
> There are two alternate functions you can call if you would like to remove 
> the warning right now. They are the normal "* operator" (if contracting over 
> the inner two indices of the tensors) and the general contract function that 
> takes in two tensors and returns the result. The indices over which the 
> contract function operates are specified as template parameters. You can see 
> an example of how to use it in the function documentation.
> 
> I hope that this helps you.
> Jean-Paul
> 
> On Thursday, December 15, 2016 at 12:06:16 AM UTC+1, Joaquin wrote:
> Dear all,
> 
> I am trying to run the IFEM code on FSI problems, developed by Luca Heltai. I 
> am using deal.II 8.4.1. I edited some parts of the code due to warnings 
> because it is considered deprecated for the version I am using. I stopped 
> when warning appears for line 1038:
> 
> 1037  if((!par.semi_implicit) || (!par.use_spread))
> 1038  contract (PeFT, Pe[qs], 2, F[qs], 2);
> 
> The warning I see is as follows:
> 
> jomivalen@Nalia ~/ifem/ans-ifem $ make
> Scanning dependencies of target ifem
> [ 25%] Building CXX object CMakeFiles/ifem.dir/source/immersed_fem.cc.o
> /home/jomivalen/ifem/ans-ifem/source/immersed_fem.cc: In instantiation of 
> ‘void 
> ImmersedFEM::residual_and_or_Jacobian(dealii::BlockVector&, 
> dealii::BlockSparseMatrix&, const dealii::BlockVector&, const 
> dealii::BlockVector&, double, double) [with int dim = 2]’:
> /home/jomivalen/ifem/ans-ifem/source/immersed_fem.cc:2046:16:   required from 
> here
> /home/jomivalen/ifem/ans-ifem/source/immersed_fem.cc:1038:44: warning: ‘void 
> dealii::contract(dealii::Tensor<2, dim, Number>&, const dealii::Tensor<2, 
> dim, Number>&, unsigned int, const dealii::Tensor<2, dim, Number>&, unsigned 
> int) [with int dim = 2; Number = double]’ is deprecated (declared at 
> /home/jomivalen/cfem/dealii/include/deal.II/base/tensor_deprecated.h:262) 
> [-Wdeprecated-declarations]
>  contract (PeFT, Pe[qs], 2, F[qs], 2);   // contract (PeFT, Pe[qs], 
> 2, F[qs], 2);
> ^
> 
> I don't know how to actualize the contract function despite having seen the 
> indications in the file "tensor.h".
> 
> Thanks for any help,
> Joaquín
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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] using FEValues extractor for a

2016-12-17 Thread luca.heltai
Dear Anup,

one option you have is to use a Triangulation.

I would still use two scalar extractors:

const FEValuesExtractors::Scalar u_x
const FEValuesExtractors::Scalar u_y

Tensor<2,dim+1> gradient;

gradient[0] = fe_values_ref[u_x].gradient(k, q_point) 
gradient[1] = fe_values_ref[u_y].gradient(k, q_point) 

But at this point your gradient would be ok. Alternatively, you have to do 
things manually...

Best,

Luca.


> On 13 Dec 2016, at 23:30, Anup Basak  wrote:
> 
> Hello all,
> 
> I am solving for a  3 dimensional displacement vector (dim+1 dimensional)  in 
> a dim=2 dimensional space (for
> a planer problem in elasticity). Hence I consider an FEvaluesExtractor:
> 
> const FEValuesExtractors::Vector u_fe;
> 
> and initialize it as 
> 
> u_fe(0)
> 
> 
> Now I need to compute the gradient of the shape functions and the gradient of 
> the solution vectors. Hence I 
> use the command:
> 
> 
> for (unsigned int q_point = 0; q_point < n_q_points; ++q_point)
> for (unsigned int k = 0; k < dofs_per_cell; ++k)
> fe_values_ref[u_fe].gradient(k, q_point)
> 
> 
> Then I get 2x2 tensors. Could anyone suggest how to get gradient terms 
> corresponding to all three vectors
> and finally get a 3x3 tensors, instead of 2x2. I am expecting to get a 3x3 
> tensor with non-zero entries in the
>  first two columns and all zero entries in the third column.
> 
> 
> Thanks and regards,
> Anup.
> 
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "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.


  1   2   >