Re: [deal.II] Possible minor error in a graphic for MATH676 video lecture 15

2020-01-13 Thread Wolfgang Bangerth 
On 1/11/20 7:22 AM, Krishnakumar Gopalakrishnan wrote:
> I don't know if this is the right place to discuss this, but it might 
> possibly 
> be of relevance to new users of deal.ii
> 
> There might be a minor error in a graphic used in the slides corresponding to 
> video lecture 15 of MATH676 (topic: cell refinement introduction)
> 
> In the longest edge refinement and red-green refinement strategies, the 
> discussion pertains to triangular meshes.
> 
> However, the right-most (slightly bottom-right) cell is actually a 
> quadrilateral!   (see slides 10-15, 19-23) in 

Good eye. I've fixed it in my own document. It will be fixed in the pdf online 
next time I update them.

Thanks for the note!
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/1c93a7a2-6dd5-e4ed-14ec-fb59d5aad767%40colostate.edu.

Re: [deal.II] discontinous contour over elements

2020-01-13 Thread Wolfgang Bangerth 
On 1/12/20 9:17 PM, David Eaton wrote:
> My inflow condition is uniform. This formulation and mesh is tested in a 
> simple C++ code without library. The  large mesh near the inflow does not 
> give 
> this problem.
> Yes. I am using C0 element. I did calculation using tecplot. However, the 
> results from a my C++ code does not give this issue either. Just now, I check 
> the formulation again. Although I use Q2Q1 Taylor-Hood element without any 
> stabilization, these issues are still happening.

David -- we don't really know what formulation you are using, how you are 
implementing it, what you are comparing against, and a number of other factors.

If you have a formulation that computes u,p, and you are plotting the 
vorticity, you need to expect that the isocontours are discontinuous for the 
reasons Praveen already stated. If you are getting results that make no sense 
to you, then the first step would be to ensure that your program is converging 
as expected. To do this, choose a solution that you know and compute the error 
norm; then ensure that the program yields error norms that decrease as 
expected with mesh refinement.

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/e1b55e95-a139-d62e-e786-61393cf84dc7%40colostate.edu.

Re: [deal.II] Segfault when calling gather_evaluate() or read_dof_values_plain()

2020-01-13 Thread Wolfgang Bangerth 
On 1/13/20 8:41 AM, 'Maxi Miller' via deal.II User Group wrote:
> Therefore, I assume that I have some bugs in my code, but am not experienced 
> enough in writing matrix-free code for being able to debug it myself. What 
> kind of approach could I do now, or is there simply a glaring bug which I did 
> not see yet?

I haven't even looked at the code yet, but for segfaults there is a relatively 
simple cure: Run your code in a debugger. A segmentation fault is a problem 
where some piece of code tries to access data at an address (typically through 
a pointer) that is not readable or writable. The general solution to finding 
out what the issue is is to run the code in a debugger -- the debugger will 
then stop at the place where the problem happens, and you can inspect all of 
the values of the pointers and variables that are live at that location. Once 
you see what variable is at fault, the problem is either already obvious, or 
you can start to think about how a pointer got the value it has and why.

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/6aba09b0-5f12-0707-c822-ad04a0a5251d%40colostate.edu.

Re: [deal.II] Re: "fatal error: MueLu_CreateEpetraPreconditioner.hpp: No such file or directory" when compiling with Trilinos

2020-01-13 Thread Wolfgang Bangerth 
On 1/9/20 8:49 AM, masod sadipour wrote:
> I want to install dael.ii at ubuntu. There is a problem when I want to use 
> "cmake".
> I was wondering if you could help me to install it. The way that mentioned in 
> the deal.ii.org 
> 
>  
> (cmake -DCMAKE_INSTALL_PREFIX=/path/to/install/dir ../deal.II) make an error. 
> It does make an error persistently.
> 
> could you please introduce me another source to help me about it.

Masod,
you will have to help us help you. We can't guess what might be the reason for 
your problems if all you say "There is a problem". You'll have to show us what 
the error message is, explain what you have already tried, etc.
Best
  WB

-- 

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/c5d6f1e2-9e00-d0a3-c44b-e24b3362bd67%40colostate.edu.

[deal.II] Segfault when calling gather_evaluate() or read_dof_values_plain()

2020-01-13 Thread 'Maxi Miller' via deal.II User Group 
I tried to implement a RK4-solver similar to the upcoming example 67 using 
the matrix-free technique, and compare it to other solvers I wrote earlier. 
For this purpose I chose the classical heat-equation for testing. When 
running the attached example, though, I get a segfault when calling either 
gather_evaluate() or read_dof_values_plain(). By replacing the code from 
read_dof_values_plain() with the code from the include file, I could narrow 
the problem down to (presumably) the operation read_write_operation(). When 
commenting this function out, the code continues until evaluate(), when 
not, it segfaults.
Therefore, I assume that I have some bugs in my code, but am not 
experienced enough in writing matrix-free code for being able to debug it 
myself. What kind of approach could I do now, or is there simply a glaring 
bug which I did not see yet?
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/06afdccd-8520-435a-9c49-2cfe1021998e%40googlegroups.com.
/* -
 *
 * Copyright (C) 2009 - 2019 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.
 *
 * -
 *
 * Author: Wolfgang Bangerth, Texas A University, 2009, 2010
 * Timo Heister, University of Goettingen, 2009, 2010
 */
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 

namespace LA
{
#undef DEAL_II_WITH_PETSC
#if defined(DEAL_II_WITH_PETSC) && !defined(DEAL_II_PETSC_WITH_COMPLEX) && \
	!(defined(DEAL_II_WITH_TRILINOS) && defined(FORCE_USE_OF_TRILINOS))
	using namespace dealii::LinearAlgebraPETSc;
#  define USE_PETSC_LA
#elif defined(DEAL_II_WITH_TRILINOS)
	using namespace dealii::LinearAlgebraTrilinos;
#else
#  error DEAL_II_WITH_PETSC or DEAL_II_WITH_TRILINOS required
#endif
} // namespace LA
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 

#include 

#include 
#include 

#include 
#include 

constexpr double time_step = 0.01;

constexpr unsigned int fe_degree= 2;
constexpr unsigned int n_q_points_1d= fe_degree + 2;
using Number= double;

enum LowStorageRungeKuttaScheme
{
	stage_3_order_3, /* Kennedy, Carpenter, Lewis, 2000 */
	stage_5_order_4, /* Kennedy, Carpenter, Lewis, 2000 */
	stage_7_order_4, /* Tselios, Simos, 2007 */
	stage_9_order_5, /* Kennedy, Carpenter, Lewis, 2000 */
};
constexpr LowStorageRungeKuttaScheme lsrk_scheme = stage_5_order_4;

namespace Step40
{
	using namespace dealii;

	class LowStorageRungeKuttaIntegrator
	{
	public:
		LowStorageRungeKuttaIntegrator(const LowStorageRungeKuttaScheme scheme)
		{
			if (scheme == stage_3_order_3)
			{
bi = {{0.245170287303492, 0.184896052186740, 0.569933660509768}};
ai = {{0.755726351946097, 0.386954477304099}};
			}
			else if (scheme == stage_5_order_4)
			{
bi = {{1153189308089. / 22510343858157.,
	   1772645290293. / 4653164025191.,
	   -1672844663538. / 4480602732383.,
	   2114624349019. / 3568978502595.,
	   5198255086312. / 14908931495163.}};
ai = {{970286171893. / 4311952581923.,
	   6584761158862. / 12103376702013.,
	   2251764453980. / 15575788980749.,
	   26877169314380. / 34165994151039.}};
			}
			else if (scheme == stage_7_order_4)
			{
bi = {{0.0941840925477795334,
	   0.149683694803496998,
	   0.285204742060440058,
	   -0.122201846148053668,
	   0.0605151571191401122,
	   0.345986987898399296,
	   0.186627171718797670}};
ai = {{0.241566650129646868 + bi[0],
	   0.0423866513027719953 + bi[1],
	   0.215602732678803776 + bi[2],
	   0.232328007537583987 + bi[3],
	   0.256223412574146438 + bi[4],
	   0.0978694102142697230 + bi[5]}};
			}
			else if (scheme == stage_9_order_5)
			{
bi = {{2274579626619. / 23610510767302.,
	   693987741272. / 12394497460941.,
	   -347131529483. / 15096185902911.,
	   1144057200723. / 32081666971178.,