[deal.II] Re: Problem with the use of FE_Nedelec with a mesh file generated from Gmsh

2017-12-19 Thread Jianan Zhang 
Just forget to attach the mesh file generated using Gmsh.

Jianan

在 2017年12月20日星期三 UTC-5上午12:56:11，Jianan Zhang写道：
>
> Hi, all,
>
> I am using dealii to solve the curl-curl equation:
>
> curl(mu^(-1)curl(E)) + (-omega^2*epsilon+j*omega*sigma)*E=0,
>
> with boundary conditions: n x E = n X F ,  
> (Dirichlet)
> or  n X (curl(E)) = n X (curl(F))  
>  (Neumann)
> where F is a known exact solution.
>
> Following Ross Kynch's code, I implemented my own exact solution and the 
> assembly of system of equations my self. The exact solution (including real 
> and imaginary parts) is as follows:
>
> E_re = [0, sin(pi*x)/a*cos(k_z10_re*z)*exp(k_z10_im*z), 0],
> E_im = [0, -sin(pi*x)/a*sin(k_z10_re*z)*exp(k_z10_im*z), 0]
>
> The exact solution for Ross Kynch's case (take p=[0 1 0] and k=[0 0 0.1]) 
> is given by:
> E_re = [0, cos(0.1*z), 0],
> E_im = [0, sin(0.1*z), 0] 
>
> The domain I want to solve this problem is a 3D hyperrectangle  with width 
> = 19.05e-3, height = 9.524e-3, and length = 15.24e-3. I've tried to solve 
> the above equation with these two exact solutions. When I used the build-in 
> mesh generator in dealii (i.e., GridGenerator::hyper_rectangle 
> (triangulation, p1, p2);) to generate the mesh. The problem can be solved 
> correctly. The results are given below:
>
> my exact solution, built-in mesh generator:
>
>
> 
>
>
>
>
>
>
> Ross' exact solution, built-in mesh generator:
>
> Cycle 0:Number of degrees of freedom: 3888
>  Done
> cycle cells dofsL2 ErrorH(curl) Error  
> 064 3888 9.73783895e-12 1.03298196e-11 
>
> When I use the mesh generated from Gmsh software (after conversion into 
> hexes), if I give Ross' exact solution, the problem can still be solved 
> correctly, as shown bellow:
> Cycle 0:number of cells:244
> Number of degrees of freedom: 13176
>  Done
> cycle cells dofs L2 ErrorH(curl) Error  
> 0   244 13176 1.36020912e-07 8.58355818e-05
>
>
> However, when I switch to my exact solution, the results are totally 
> wrong. The electric field obtained has totally wrong direction (seems to be 
> arbitrary but the correct one should be along y-axis). The results are as 
> follows
>
> 
>   
>   
> 
>
>
> I've spent like ten days finding the reason, and I am almost 100% sure 
> that my exact solution is given correctly and the assembly is correct. The 
> only thing I changed is the exact solution, and the difference between his 
> and mine is that his is only z-component dependent while mine depend on 
> both x and z. 
>
> I post my codes and the vtk files for anyone who are interested. I am 
> having  a hard time on debugging this and any suggestions and help is much 
> appreciated. 
>
> Thanks in advance.
>
> Jianan Zhang
>
>
>

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


hollow_v2.msh
Description: Mesh model

Re: [deal.II] affine representation

2017-12-19 Thread Wolfgang Bangerth 


Hi Jean,
good to hear from you!

I am solving a linear system (say linear heat conduction) with many different 
materials (blockID) whose material properties are uncertain.


My goal is to use a RB approach to build the ROM. However, while building the 
snapshots, for every new sample, I need to reassemble the system matrix. This 
operation can become quite costly when repeated many times.


It would be better to exploit the affine representation of my problem. To make 
this simple, I am only describing the 2-material case. Suppose I have a block 
ID for each material. The global stiffness matrix  is K = k1 K1 + k2 K2,
where k1,k2 are the conductivities of materials 1/2 and K1 is the stiffness 
matrix built with a *unit* conductivity in regions where material 1 is present 
and a similar definition for K2. The size of each matrix is n (total ndofs). 
But their number of nonzero entries (nnz) depends on how many cells are in 
each material region. If you extrapolate this to 1000 materials, it is clear 
that I do not want to allocate the memory for 1000  Ki matrices based on the 
total ndofs in the system. I would like to create each Ki matrix with just 
enough memory for each material region.


So, is there a way to do this in deal?


Funny, because I've been thinking about this same issue over the past week. In 
my case, the coefficient are constant on each cell but may have (in principle) 
as many values as there are cells. What I'm going to do in my cell is to store 
the local matrices A_K for each cell K (computed with a unit coefficient) and 
then I only need to do the following to get the global matrix:


  for (cell=...)
k_K = get_coefficient (cell)
A_K = get_local_matrix (cell)  // previously computed -- only needs lookup
A_K *= k_K;
distribute_local_to_global (A_K, A);

If the coefficient you have applies to only one of multiple terms (with the 
other terms potentially multiplied by other coefficients), then you may have 
to store multiple A_K matrices, multiply them by their respective 
coefficients, and only then do the copy-local-to-global operation.


Alternatively, if you want to go your route, you could note that K1 and K2 
have different sparsity patterns -- they only have non-zero entries in their 
respective sub-domains. So you could build your 1000 sparsity patterns for the 
1000 Ki matrices, each of which would be vastly sparser than that of K. The 
case I describe above is really just an extreme case: each of the coefficients 
ki lives on only one cell, so the Ki have a sparsity pattern that is 
equivalent to the DoFs on only one cell -- which is most efficiently 
represented by not storing Ki as a sparse matrix, but as the local dense matrix.


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] Documenting code for Code gallery

2017-12-19 Thread Wolfgang Bangerth 

On 12/19/2017 02:15 PM, RAJAT ARORA wrote:


I have written a code for a small strain elasto-plastic solid mechanics 
problem in 2d using deal.ii.


I wanted to contribute it to code gallery and have gone through the 
instructions given here:

http://www.dealii.org/code-gallery.html#instructions

I wanted to know how can I document the code using Doxygen as most of the 
example programs are documented.
To understand this, I looked at the examples already documented in Code 
Gallery. They use tags like @sect3, and @sect4. (I am not sure  if Doxygen has 
these commands built in.)


I wanted to know where can I learn what commands are available to use and 
generate documentation locally before uploading everything.


Rajat -- first, many thanks already for being willing to contribute your 
program!

As for the documentation: the code gallery works a bit differently than the 
tutorial programs, but ultimately you can essentially do everything in both 
worlds. For the code gallery, the introduction (and results section, in fact) 
is in the Readme.md file -- which uses doxygen-style markdown to annotate sections

  https://www.stack.nl/~dimitri/doxygen/manual/markdown.html
But, ultimately, it is also sent into the same scripts that we use for the 
tutorials, and that gives you the ability to use formulas, for example.


You may want to take a look at the README.html file for the LDG example. The 
source is here:


https://dealii.org/developer/doxygen/code-gallery/Distributed_LDG_Method/README.md

And the rendered version is here:

https://dealii.org/developer/doxygen/deal.II/code_gallery_Distributed_LDG_Method.html#ann-README.md

Best & looking forward to your program!
 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] assertion failed: be_value_from_constant: unknown constant kind (shared/cfe/edgglue/edg_decl.c, line 1374)

2017-12-19 Thread Wolfgang Bangerth 

On 12/19/2017 02:23 PM, Lev Karatun wrote:


I get the error when running make on 1 process, after cleaning the build 
directory. Any help would be appreciated!


It's a compiler bug -- you are triggering an assertion inside the compiler 
itself, not in our source code. So that already makes it difficult to find a 
solution.


It used to be pretty common to trigger compiler bugs, and the only solution to 
this was to try to make the code that's being compiled smaller. You already 
know that the issue is in fe_enriched.cc -- remove one function after the 
other, while making sure that the compiler error still happens. Repeat this 
until you can't remove a single line any more, then try to modify the code in 
such a way that it continues to do the same thing, but with a different syntax.


Of course, you could also try to use GCC instead of the Intel compiler. Or you 
could see if your sysadmins are willing to upgrade the Intel compiler -- this 
particular compiler bug appears to already have been fixed:

  https://software.intel.com/en-us/forums/intel-c-compiler/topic/293438

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] Sixth deal.II Users and Developers Workshop - 23 --27 July 2018, Trieste, Italy

2017-12-19 Thread Yaakobi, Oded (NIH/NIAID) [F] 
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(UTC-05:00) Eastern Time (US & Canada)
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Yaakobi, Oded (NIH/NIAID) [F]":MAILTO:oded.yaak...@nih.gov
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Deal.II Us
 ers:MAILTO:dealii@googlegroups.com
UID:04008200E00074C5B7101A82E008756ABDCD1779D301000
 0100039A2C6A3B99FA64BBEC1EE37E8A3319B
SUMMARY;LANGUAGE=en-US:[deal.II] Sixth deal.II Users and Developers Worksho
 p - 23 --27 July 2018\, Trieste\, Italy
DTSTART;TZID="(UTC-05:00) Eastern Time (US & Canada)":20180723T12
DTEND;TZID="(UTC-05:00) Eastern Time (US & Canada)":20180728T12
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20171219T06Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2115805045
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

Re: [deal.II] Re: Moving Mesh when using Fe_Q(p) p>1

2017-12-19 Thread Bruno Turcksin 
Hi,

2017-12-19 15:59 GMT-05:00 RAJAT ARORA :

>
> So, going by what you described, if x2 is unknown, how can the mapping
> class calculate the information?
>
> Is it because it uses the manifold information (which is a straight
> boundary by default) attached to it to get the nodal coordinates of the
> middle node and then calculate the Jacobian and other information?
>
Mapping knows the cell in the real space because of this function
.
Depending on the mapping you are using, it can use the information from the
manifold (that's what happens when you use MappingManifold) or just an
approximation of the manifold (that's what happens with MappingQGeneric).
This function

maps a point in the reference space to a point in the real space. So you
know where x2 is in the real space, since you know it's position in the
reference space.

Best,

Bruno

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

[deal.II] assertion failed: be_value_from_constant: unknown constant kind (shared/cfe/edgglue/edg_decl.c, line 1374)

2017-12-19 Thread Lev Karatun 
Hi everyone,

I was trying to update dealII to the latest version, but I'm getting an 
error:

> [ 47%] Building CXX object 
>> source/fe/CMakeFiles/obj_fe_release.dir/fe_enriched.cc.o
>
> cd /home/lkaratun/aspect/dealii/build/source/fe && 
>> /cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/intel2017.1/openmpi/2.1.1/bin/mpiCC
>>   
>>  -I/home/lkaratun/aspect/dealii/build/source/fe 
>> -I/home/lkaratun/aspect/dealii/build/include 
>> -I/home/lkaratun/aspect/dealii/include 
>> -I/home/lkaratun/aspect/dealii/bundled/tbb41_20130401oss/include 
>> -I/home/lkaratun/aspect/dealii/bundled/umfpack/UMFPACK/Include 
>> -I/home/lkaratun/aspect/dealii/bundled/umfpack/AMD/Include 
>> -I/home/lkaratun/aspect/dealii/bundled/boost-1.62.0/include 
>> -I/home/lkaratun/aspect/dealii/bundled/muparser_v2_2_4/include 
>> -I/cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/intel2017.1/openmpi/2.1.1/include
>>  
>> -I/cvmfs/soft.computecanada.ca/nix/var/nix/profiles/16.09/include 
>> -I/cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/MPI/intel2016.4/openmpi2.1/trilinos/12.10.1/include
>>  
>> -I/cvmfs/soft.computecanada.ca/easybuild/software/2017/Core/imkl/11.3.4.258/mkl/include
>>  
>> -I/cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/Compiler/intel2016.4/gsl/2.2.1/include
>>  
>> -I/cvmfs/soft.computecanada.ca/easybuild/software/2017/avx2/MPI/intel2016.4/openmpi2.1/p4est/1.1/include
>>   
>> -fpic -ansi -w2 -diag-disable=remark -wd21 -wd68 -wd135 -wd175 -wd177 
>> -wd191 -wd193 -wd279 -wd327 -wd383 -wd981 -wd1418 -wd1478 -wd1572 -wd2259 
>> -wd2536 -wd3415 -wd15531 -wd111 -wd128 -wd185 -wd186 -wd280 -qopenmp-simd 
>> -std=c++14 -std=c++14 -g -O2 -march=native -Wno-parentheses -O2 
>> -no-ansi-alias -ip -funroll-loops -o 
>> CMakeFiles/obj_fe_release.dir/fe_enriched.cc.o -c 
>> /home/lkaratun/aspect/dealii/source/fe/fe_enriched.cc
>
> /cvmfs/soft.computecanada.ca/nix/store/lvjwgn6hpngyy6k4xqcqa9h2cxy3fl30-gfortran-5.4.0/include/c++/5.4.0/functional(1673)
>  
>> (col. 30): internal error: assertion failed: be_value_from_constant: 
>> unknown constant kind (shared/cfe/edgglue/edg_decl.c, line 1374)
>
> compilation aborted for 
>> /home/lkaratun/aspect/dealii/source/fe/fe_enriched.cc (code 4)
>>
> make[2]: *** [source/fe/CMakeFiles/obj_fe_release.dir/build.make:762: 
>> source/fe/CMakeFiles/obj_fe_release.dir/fe_enriched.cc.o] Error 4
>
> make[2]: Leaving directory '/home/lkaratun/aspect/dealii/build'
>
> make[1]: *** [CMakeFiles/Makefile2:1949: 
>> source/fe/CMakeFiles/obj_fe_release.dir/all] Error 2
>
> make[1]: Leaving directory '/home/lkaratun/aspect/dealii/build'
>
> make: *** [Makefile:133: all] Error 2
>
>
I get the error when running make on 1 process, after cleaning the build 
directory. Any help would be appreciated! 

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

2017-12-19 Thread RAJAT ARORA 
Hello all,

I have written a code for a small strain elasto-plastic solid mechanics 
problem in 2d using deal.ii.

I wanted to contribute it to code gallery and have gone through the 
instructions given here:
http://www.dealii.org/code-gallery.html#instructions

I wanted to know how can I document the code using Doxygen as most of the 
example programs are documented. 
To understand this, I looked at the examples already documented in Code 
Gallery. They use tags like @sect3, and @sect4. (I am not sure  if 
Doxygen has these commands built in.)

I wanted to know where can I learn what commands are available to use and 
generate documentation locally before uploading everything.


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.

[deal.II] Re: Moving Mesh when using Fe_Q(p) p>1

2017-12-19 Thread RAJAT ARORA 
Hello Bruno,

Thanks for the reply. 

I read the the link you gave and that helped me learn and understand how 
things work behind the scene in deal.ii.

But, I dont understand 1 thing. Lets say my domain just consists of a 
single element in 1D. I use quadratic shape functions so this makes a total 
of 3 shape functions. Now, lets say I want to use isoparametric mapping.

If x is the mapping and zeta is the coordinate in the parent element, and 
x1, x2 (middle node), x3 are the coordinates of the three nodes in the real 
space.

so, Jacobian needs to calculate, dx / dzeta = x1 * dN1 / dzeta + x2 * dN2 / 
dzeta + x3 * dN3 / dzeta.

So, going by what you described, if x2 is unknown, how can the mapping 
class calculate the information?

Is it because it uses the manifold information (which is a straight 
boundary by default) attached to it to get the nodal coordinates of the 
middle node and then calculate the Jacobian and other information?

Thanks.

On Monday, December 11, 2017 at 8:39:20 AM UTC-5, Bruno Turcksin wrote:
>
> Hi,
>
> On Sunday, December 10, 2017 at 9:55:49 PM UTC-5, RAJAT ARORA wrote:
>
>> My question is:
>> Is the mesh movement independent of the order of the polynomial used to 
>> interpolate the solution?
>>
>> What is confusing me is that I learned that there are nodes (other than 
>> vertices) in the element when using higher order elements. So, when moving 
>> mesh, these nodes must also be moved. In other words, these nodes are part 
>> of the mesh. But if the move mesh function is correct for higher order 
>> shape functions as well, than this means, my mesh just knows about the 
>> vertices of the elements.
>>
> The mesh is independent of the  order of the polynomial. The easiest way 
> to realize it is that you don't need to know which kind of finite element 
> you are using to create a mesh. If it worked like you said and the nodes 
> would be part of the mesh, you would need to know the finite element to 
> build the mesh. There is no reason to have the nodes part of the mesh. The 
> only thing you need is to be able to map the position of the nodes in the 
> unit cell to their position in the mesh. This is done using Mapping. 
> Mapping allows you decouple the mesh with the finite element that you are 
> using. Take a look here 
> http://dealii.org/developer/doxygen/deal.II/group__FE__vs__Mapping__vs__FEValues.html
>
> Best,
>
> Bruno
>

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

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

2017-12-19 Thread Bruno Turcksin 
Hi,

On Tuesday, December 19, 2017 at 2:58:20 PM UTC-5, jie liu wrote:
>
>
> This phenomenon is not desired. Different solvers are adopted, but there 
> is no improvement on it. Can anybody give some clues? Thank you.
>
You have a bug in your code. What you should see is that the error 
decreases and then flattens. Your code probably converges to a solution 
close but different than the exact solution. Because it is close to the 
exact solution, it looks like you are converging correctly but when you 
refine the problem more you see the difference (just a guess though). If 
you are using elements of the third order, you could check that the you get 
the exact solution when the solution is a polynomial of order 3. You should 
get the exact solution independently of the mesh, so you can see what 
happens on a coarse and on a fine 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.

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

2017-12-19 Thread jie liu 
Dear all,

I'm solving a 1D Poisson problem.

I put those lines of step-7 computing the L2-norm into step-4 to output the 
L2-norm of the solution. 
P3 elements are adopted and the residual norm of the solver is set to 1e-12.
The error decreases first, while it starts to increase when the number of 
nodes becomes large enough.
This phenomenon is not desired. Different solvers are adopted, but there is 
no improvement on it. Can anybody give some clues? Thank you.

Kind regards,
Jie

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

2017-12-19 Thread Wolfgang Bangerth 

On 12/10/2017 08:58 AM, Lukas Korous wrote:



I just want to share my success - I successfully incorporated the Taylor DG 
space into my code - https://github.com/l-korous/mhdeal.


Lukas,
is either the element (or the whole code) something you would perhaps like to 
contribute to the library (or the code gallery)?


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.