[deal.II] deal.II Newsletter #77
Hello everyone! This is deal.II newsletter #77. It automatically reports recently merged features and discussions about the deal.II finite element library. ## Below you find a list of recently proposed or merged features: #7987: Fix a couple of typos. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7987 #7986: Align a set of equations. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7986 #7985: Update module on user interfaces to AD libraries (proposed by jppelteret; merged) https://github.com/dealii/dealii/pull/7985 #7984: Enable doxygen to build SD documentation (proposed by jppelteret; merged) https://github.com/dealii/dealii/pull/7984 #7983: newline bug in grid_in_abaqus fixed (proposed by rezarastak; merged) https://github.com/dealii/dealii/pull/7983 #7982: Arpack Solver documentation fix (proposed by rezarastak; merged) https://github.com/dealii/dealii/pull/7982 #7981: Restrict SymEngine test (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7981 #7979: Misc. typos (proposed by luzpaz; merged) https://github.com/dealii/dealii/pull/7979 #7978: Refactor configuration option into DEAL_II_MPI_WITH_CUDA_SUPPORT (proposed by tamiko) https://github.com/dealii/dealii/pull/7978 #7977: Improve doxygen documentation for ReadWriteVector (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7977 #7976: Export DEAL_II_PETSC_WITH_COMPLEX variable (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7976 #7975: Improve the documentation of parallel builds. (proposed by drwells; merged) https://github.com/dealii/dealii/pull/7975 #7974: SD scalar operations: Creation of substitution maps (proposed by jppelteret) https://github.com/dealii/dealii/pull/7974 #7973: SD tensor operations: Creation of, and addition to, substitution maps (proposed by jppelteret) https://github.com/dealii/dealii/pull/7973 #7972: Use the function n_locally_owned_active_cells() in step-18 (proposed by dangars; merged) https://github.com/dealii/dealii/pull/7972 #7971: Updating Ginkgo wrapper after Ginkgo's release 1.0.0 (proposed by pratikvn) https://github.com/dealii/dealii/pull/7971 #7969: Use integers in cudaMemset (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7969 #7968: Deal with empty ranges in CUDAWrappers::MatrixFree::internal_reinit (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7968 #7967: Deal with empty empty sizes in CUDA kernels (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7967 #7966: Clean up CUDAWrappers::MatrixFree::reinit interface (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/7966 #7965: Exchange vectors of std::vector::swap() in step-18 (proposed by dangars; merged) https://github.com/dealii/dealii/pull/7965 #7964: Remove destructor in step40 (proposed by dangars; merged) https://github.com/dealii/dealii/pull/7964 #7962: Adding documentation for generic LA namespaces (proposed by rezarastak; merged) https://github.com/dealii/dealii/pull/7962 #7961: SD scalar operations: Addition to substitution maps and map merging (proposed by jppelteret; merged) https://github.com/dealii/dealii/pull/7961 #7960: Fix a mistaken assertion that only succeeds by accident. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7960 #7959: Documentation fix Physics::Transformations::Rotations::rotation_matrix_2d (proposed by kronbichler; merged) https://github.com/dealii/dealii/pull/7959 #7958: Augment documentation in class IteratorRange. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7958 #7957: Mathematical notation of DerivativeForm (proposed by rezarastak; merged) https://github.com/dealii/dealii/pull/7957 #7956: step-40 disable logic with complex PETSc (proposed by tjhei; merged) https://github.com/dealii/dealii/pull/7956 #7955: Reduce chunk_size used in CUDA kernels from 8 to 1 (proposed by Rombur; merged) https://github.com/dealii/dealii/pull/7955 #7954: Edit the results section of step-61. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7954 #7952: Remove pictures from the repository. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/7952 #7944: SD tensor operations: Add functions to perform symbolic tensor differentation (proposed by jppelteret; merged) https://github.com/dealii/dealii/pull/7944 #7943: Degree of quadrature based on degree of the fe-variable (proposed by anates; merged) https://github.com/dealii/dealii/pull/7943 #7932: Enrich CutOffFunctionBase, and provide also CutOffFunctionC1 (proposed by luca-heltai; merged) https://github.com/dealii/dealii/pull/7932 #7918: FunctionFromFunctionObjects class: wraps a vector of std::function objects into a Function object (proposed by luca-heltai; merged) https://github.com/dealii/dealii/pull/7918 #7913: Mapping::get_center()
Re: [deal.II] dynamic impact simulations
On 5/1/19 9:45 AM, Nico Bombace wrote: > > > 2) I have seen some some impact/contact problems in the step tutorials, > > would this work in dynamics as well? > > You'd have to write a time loop around it. In essence, you have to > solve > a nonlinear contact problem in each time step, for which there are > tutorial programs. Then you move one time step forward which changes > the > position of the impactor and you have to solve a nonlinear contact > problem again (for which you can use the previous state as a good > initial guess). > > > Would it be possible to use the fully explicit formulation of finite > elements, with a lumped mass matrix? > That would avoid the internal iterations and convergence issues (with > a conditional time-step obviously). Yes, sure. In that case, you really only need to be able to implement the right hand side of the problem. 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.
Re: [deal.II] dynamic impact simulations
Thank you for your answer, I have only a further small comment On 5/1/19 9:02 AM, Nico Bombace wrote: > > > > After some time using Abaqus/Explicit, I decided to start to code my > > library because it would give more liberty in terms of implementation of > > new algorithms. > > I am starting the deal.ii video lectures and tutorials and I have some > > questions regarding a particular class of problems, namely impacts in > > solid mechanics. I did search the publication section without much > success. > > > > 1) Does deal.ii implement the central time difference time marching > scheme? > > Time stepping schemes are generally easy enough that they are not > implemented in the library itself, but in user code. But there are > numerous time dependent programs that you can take a look at. > > > > 2) I have seen some some impact/contact problems in the step tutorials, > > would this work in dynamics as well? > > You'd have to write a time loop around it. In essence, you have to solve > a nonlinear contact problem in each time step, for which there are > tutorial programs. Then you move one time step forward which changes the > position of the impactor and you have to solve a nonlinear contact > problem again (for which you can use the previous state as a good > initial guess). > Would it be possible to use the fully explicit formulation of finite elements, with a lumped mass matrix? That would avoid the internal iterations and convergence issues (with a conditional time-step obviously). Kind regards, Nico > > > 3) Does deal ii support element erosion based on the internal state of > > an element? > > Sort of. You will want to take a look at step-46, which shows how you > can switch an equation on/off on individual cells. > > 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. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] dynamic impact simulations
On 5/1/19 9:02 AM, Nico Bombace wrote: > > After some time using Abaqus/Explicit, I decided to start to code my > library because it would give more liberty in terms of implementation of > new algorithms. > I am starting the deal.ii video lectures and tutorials and I have some > questions regarding a particular class of problems, namely impacts in > solid mechanics. I did search the publication section without much success. > > 1) Does deal.ii implement the central time difference time marching scheme? Time stepping schemes are generally easy enough that they are not implemented in the library itself, but in user code. But there are numerous time dependent programs that you can take a look at. > 2) I have seen some some impact/contact problems in the step tutorials, > would this work in dynamics as well? You'd have to write a time loop around it. In essence, you have to solve a nonlinear contact problem in each time step, for which there are tutorial programs. Then you move one time step forward which changes the position of the impactor and you have to solve a nonlinear contact problem again (for which you can use the previous state as a good initial guess). > 3) Does deal ii support element erosion based on the internal state of > an element? Sort of. You will want to take a look at step-46, which shows how you can switch an equation on/off on individual cells. 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.
Re: [deal.II] Re: Integrating a deal.II-specific function in a NOX-Interface for MPI-threads
On 5/1/19 5:58 AM, 'Maxi Miller' via deal.II User Group wrote: > > I don't know NOX, but is it using an update that it adds to the > solution in > each step? If so, you need to have the correct boundary conditions > in the > initial guess already. What happens if you only allow NOX to do zero > or one > iterations? > > Zero iterations is not allowed, the first iteration already goes way off > (expected highest value: 1, calculated value: 1e6), regardless if I set > boundary conditions already to the solution vector I feed to NOX, or if > I set the boundary conditions during the assembly of the right hand side. I don't know NOX at all, so I'm afraid there is little else I can to help you with this. As always, make the problem small and easy (e.g., try to find a constant solution where the nonlinear solver only has to find *which* constant value you are looking for). Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] dynamic impact simulations
Dear all, After some time using Abaqus/Explicit, I decided to start to code my library because it would give more liberty in terms of implementation of new algorithms. I am starting the deal.ii video lectures and tutorials and I have some questions regarding a particular class of problems, namely impacts in solid mechanics. I did search the publication section without much success. 1) Does deal.ii implement the central time difference time marching scheme? 2) I have seen some some impact/contact problems in the step tutorials, would this work in dynamics as well? 3) Does deal ii support element erosion based on the internal state of an element? Obviously if those features are not present at the moment, could you please point me where to find information about how to implement implement them? Thank you in advance Nico -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "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] scratch_data_03.cc from test/meshworker produces strange results when refining adaptively
I wanted to test the new ScratchData- and CopyData-Classes for DG-subfaces,
and thus used Test 3 with a locally refined grid. The result shows
significant distortions at the transitions between refinement levels.
Should that be, or is that a bug? Or is it just the missing handling of
subfaces in that test? The demo-file is attached, including modifications
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"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.
/* -
*
* Copyright (C) 2018 by the deal.II authors
*
* This file is part of the deal.II library.
*
* The deal.II library is free software; you can use it, redistribute
* it, and/or modify it under the terms of the GNU Lesser General
* Public License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
* The full text of the license can be found in the file LICENSE.md at
* the top level directory of deal.II.
*
* -
*/
// Solve Laplacian using SIPG + mesh_loop + ScratchData
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace dealii;
using namespace MeshWorker;
template
void
test()
{
Triangulation tria;
FE_DGQfe(1);
DoFHandlerdh(tria);
FunctionParser rhs_function("1");
FunctionParser boundary_function("0");
AffineConstraints constraints;
constraints.close();
GridGenerator::hyper_cube(tria);
const size_t refinement_val = 5;
tria.refine_global(refinement_val);
tria.execute_coarsening_and_refinement();
#ifdef REFINE_ADAPTIVELY
for (unsigned int i = 0; i < 2; i++)
{
typename Triangulation::active_cell_iterator
cell = tria.begin_active(),
endc = tria.end();
for (; cell != endc; cell++)
{
if ((cell->center()[1]) > 0.75 )
{
if ((cell->center()[0] > 0.8) || (cell->center()[0] < 0.2))
cell->set_refine_flag();
}
}
tria.execute_coarsening_and_refinement();
}
#endif
dh.distribute_dofs(fe);
SparsityPattern sparsity;
{
DynamicSparsityPattern dsp(dh.n_dofs(), dh.n_dofs());
DoFTools::make_flux_sparsity_pattern(dh, dsp);
sparsity.copy_from(dsp);
}
SparseMatrix matrix;
matrix.reinit(sparsity);
Vector solution(dh.n_dofs());
Vector rhs(dh.n_dofs());
QGauss quad(3);
QGauss face_quad(3);
UpdateFlags cell_flags = update_values | update_gradients |
update_quadrature_points | update_JxW_values;
UpdateFlags face_flags = update_values | update_gradients |
update_quadrature_points |
update_normal_vectors | update_JxW_values;
// Stabilization for SIPG
double gamma = 100;
using ScratchData = MeshWorker::ScratchData;
using CopyData = MeshWorker::CopyData<1 + GeometryInfo::faces_per_cell,
1,
1 + GeometryInfo::faces_per_cell>;
ScratchData scratch(fe, quad, cell_flags, face_quad, face_flags);
CopyDatacopy(fe.dofs_per_cell);
auto cell = dh.begin_active();
auto endc = dh.end();
typedef decltype(cell) Iterator;
auto cell_worker =
[&rhs_function](const Iterator &cell, ScratchData &s, CopyData &c) {
const auto &fev = s.reinit(cell);
const auto &JxW = s.get_JxW_values();
const auto &p = s.get_quadrature_points();
c = 0;
c.local_dof_indices[0] = s.get_local_dof_indices();
for (unsigned int q = 0; q < p.size(); ++q)
for (unsigned int i = 0; i < fev.dofs_per_cell; ++i)
{
for (unsigned int j = 0; j < fev.dofs_per_cell; ++j)
{
c.matrices[0](i, j) +=
fev.shape_grad(i, q) * fev.shape_grad(j, q) * JxW[q];
}
c.vectors[0](i) +=
fev.shape_value(i, q) * rhs_function.value(p[q]) * JxW[q];
}
};
auto boundary_worker = [gamma, &boundary_function](const Iterator &cell,
const unsigned int &f,
ScratchData & s,
CopyData & c) {
const auto &fev = s.reinit(cell, f);
const auto &JxW = s.get_JxW_values();
const auto &p = s.get_quadrature_points();
const auto &n = s.get_normal_vectors();
for (unsigned int q = 0; q < p.size(); ++q)
for (unsigned int i = 0; i < f
Re: [deal.II] Re: Integrating a deal.II-specific function in a NOX-Interface for MPI-threads
Am Dienstag, 30. April 2019 05:59:05 UTC+2 schrieb Wolfgang Bangerth: > > > Maxi, > > > What did you have to do? I was going to reproduce your problem today > by > > installing a Trilinos version that has NOX enabled. Is this moot > now, > > i.e., was it a bug in your code or did you just work around the > issue in > > some way that doesn't expose it? > > > > NOX expects vectors containing only the local elements, but no ghost > elements. > > Thus I had to initialize all vectors going in or out from any > NOX-related > > function using locally_owned_dofs, and copy accordingly if external > vectors > > contained ghost elements. > > I see. So this is a NOX requirement, not something that we could have done > anything about on the deal.II side? > > No, as far as I understand. NOX needs those vectors to be in the correct way, else it will not work. > > > The solver does not converge, and the output looks as if it is using > > Dirichlet-conditions with u = 0, independently of the "real" boundary > conditions. > > I don't know NOX, but is it using an update that it adds to the solution > in > each step? If so, you need to have the correct boundary conditions in the > initial guess already. What happens if you only allow NOX to do zero or > one > iterations? > > Best > W. > > Zero iterations is not allowed, the first iteration already goes way off (expected highest value: 1, calculated value: 1e6), regardless if I set boundary conditions already to the solution vector I feed to NOX, or if I set the boundary conditions during the assembly of the right hand side. > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
