Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

h this preconditioner. By > the way I am also using an IMEX scheme in my solver, see > https://github.com/sebglane/BoussinesqFluidSolver/tree/modular_version . > > Best wishes, > > Sebastian > On 01.11.18 17:30, Jie Cheng wrote: > > Hi Sebastian, > > I think w

Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

A56WAf2WcJ>. > For this reason I have two ConstraintMatrix object one for the system > matrix and one for the preconditioner. > > I also attached my code which is based step-32 but in serial. > > Best wishes, > Sebastian > > Am Freitag, 20. Oktober 2017 09:36:07 UTC-7 schrieb

Re: [deal.II] Re: Convergence problem arising for large number of DoFs

Hi Hamed I just browsed your post two years ago. I am not sure if you are still active on this mailing list. But I am very interested in the bug you found because they may be inspiring to me. It looks like in Line 923 and Line 963 you had two temporary distributed solution inside the Newton

Re: [deal.II] Re: Implementing Dirac delta function

Dear Wolfgang Thanks for your attention. The physical background is that I want to interpolate fluid velocity (v^f) onto an arbitrary point (which is in fact a solid support point). Instead of doing a standard finite element interpolation, I want to do a "delta function interpolation": v^s =

[deal.II] Re: Implementing Dirac delta function

Hi, I figured out a way to do the interpolation (Question 2), but still not sure how to avoid duplicates (Question 1): I changed the type of DiracDeltaInterpolator::sources to std::vector::active_cell_iterator,

[deal.II] Implementing Dirac delta function

Hi everyone I am trying to implement a template Dirac delta function, which takes a source vector and its associated DoFHandler, then interpolates the source vector onto an arbitrary point. Different from VectorTools::point_value, the target point does not have to be in the source grid.

Re: [deal.II] VectorTools::interpolate_boundary_values for Q2 element

Hi Wolfgang Using MappingQ(2) solved the problem, thank you! 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

Re: [deal.II] Building issue: undefined reference to SolutionTransfer

aries you are linking. > 2. run under gdb: "gdb step-1" then "run" then "backtrace" to see > where you crash. > > > On Mon, Apr 23, 2018 at 8:49 PM, Jie Cheng <chengjieh...@gmail.com> wrote: > > Hi Wolfgang > > > > Sorry for not up

Re: [deal.II] Building issue: undefined reference to SolutionTransfer

Hi Wolfgang Sorry for not updating this issue for so long. I've been developing on my local machine until recently I started to test my code on cluster again. This issue has not been resolved, linking to SolutionTransfer will fail if I build static library (solution_transfer is compiled). But

[deal.II] Re: Mesh generation issue

Hi Peng I've written something to generate sphere based on the documentation, which generates not as perfect, but usable mesh (see attached). If you are interested, click this . Best Jie -- The deal.II project is

[deal.II] Re: Constraints on support points on Q2 elements and output

I've found what was wrong in this piece of code. It turned out that index.first < dim does not guarantee this dof is a velocity dof. Changing it to* if (i < fe.base_element(0).dofs_per_cell && index.first < dim)* solves the problem. But there are two things that I can not understand: 1. using

[deal.II] Re: Constraints on support points on Q2 elements and output

Hi Daniel Thank you for your help! The code below suggests that you want to constraint all degrees of freedom. > Is this really what you intend? If so, it might be better to just > interpolate the values using VectorTools::interpolate >

[deal.II] Re: Use of 'VectorTools::interpolate_boundary_values' using numerical solution.

Hi Jaekwang One way I can think of is to construct your ConstraintMatrix for Part B manually. Iterate over your triangulation, find all the dofs on the target boundaries, then use ConstraintMatrix::add_line and ConstraintMatrix::set_inhomogeinity to set the BC. Another method might be putting

[deal.II] Constraints on support points on Q2 elements and output

Hi dealii users I need to constrain all the support points on a Q2 element instead of only vertices. The constrained values (inhomogeneity) are obtained from (conceptually) a function, say f(\bold{x}). I already know how to query the coordinates of the support points, I also know how to query

Re: [deal.II] Subtle issues in time-dependent Dirichlet boundary conditions

Dear Wolfgang Problem solved, thank you! For other people's references, here is what I did: 1. when setting the nonzero_constraints, always query the current value first and then substract it from the target value so that the solution delta is constrained correctly. 2. Apply

[deal.II] Building issue: undefined reference to SolutionTransfer

Hi everyone I am trying to build deal.II on a cluster with x86_64 architecture, Scientific Linux 6.9 (Carbon), gcc 7.2.0 and openmpi 3.0.0. (Yes, I am building dealii everywhere, as our entire research group just began to use dealii.) This time, I got linking error related to SolutionTransfer

Re: [deal.II] Re: Parallel DoFRenumbering does not work on mac

Hi Bruno and Wolfgang I finally fixed it! If there is anyone who has the same problem as I described: replacing MPICH with open-mpi resolves this issue. I do not know why, but this method has fixed two macs for me: I have never installed open-mpi before so there were no conflicting between

Re: [deal.II] Re: Parallel DoFRenumbering does not work on mac

at 11:28 PM Wolfgang Bangerth <bange...@colostate.edu> wrote: > On 01/23/2018 01:16 PM, Jie Cheng wrote: > > These are just warnings -- what happens if you run the executable? > > > > > > If I do not modify step-40.cc, it runs fine both in serial and parallel. &

Re: [deal.II] Re: Parallel DoFRenumbering does not work on mac

Hi Wolfgang > These are just warnings -- what happens if you run the executable? > If I do not modify step-40.cc, it runs fine both in serial and parallel. After I added DoFRenumbering in it, it crashes in parallel. Does DoFRenumbering have any dependency? As I posted in previous messages,

Re: [deal.II] Re: Parallel DoFRenumbering does not work on mac

I've reinstalled MPICH, and did a clean build of p4est, petsc and dealii, this problem still exists. At the linking stage of building dealii, I got warnings: [526/579] Linking CXX shared library lib/libdeal_II.9.0.0-pre.dylib ld:

Re: [deal.II] Re: Parallel DoFRenumbering does not work on mac

Bruno, > This says that you have a problem with MPI. Your program died before >> executing any code in deal. Can you run other MPI codes? >> > Yes, I can run step-40 in parallel. This problem happens only after I added a DoFRenumbering call in it (step-40.cc originally does not call

[deal.II] Parallel DoFRenumbering does not work on mac

Hi all I found that DoFRenumbering with distributed dof_handler does not work on my mac (Mac OS X 10.13.2). My dealii is built with PETSc and Step-40 runs fine. But once I added DoFRenumbering::Cuthill_McKee(dof_handler) after dof_handler.distribute_dofs (fe), it gave me runtime error:

[deal.II] Trouble getting deal.II working on bgq

Happy new year everyone I have been trying to install deal.II on my university's blue gene Q system recently. The IBM XL compiler wouldn't work because it doesn't support C++11 features. An old thread in the mailing list also suggests that it is an dead end... I also tried GCC compilers,

Re: [deal.II] Temporary distributed vectors

> The way to deal with the sparsity pattern is to "simulate" what entries > you > would produce in the mmult, add them to the sparsity pattern, attach a > matrix, > and then do the whole thing again but this time actually put the entries > into > the matrix. > That's exactly what this

Re: [deal.II] Temporary distributed vectors

Dear Wolfgang Thanks to your advice, now I have a working serial solver and a petsc-based parallel solver now. I manged to reuse the factorization in MUMPS solver, as I commented in another thread . I did some further

Re: [deal.II] PETSc Sparse LU Preallocation

Hi Lucas and Wolfgang I have something to say on this issue because I think it might be helpful to Lucas or other users. I know large memory usage is unavoidable in direct solvers. But I guess Lucas' issue with MUMPS was that he did not know how to reuse the factorization like one always does

Re: [deal.II] Temporary distributed vectors

Dear Wolfgang Another issue related to this question is that, ApproximateMassSchur has a vmult member function defined, so it can be used in CG solver to get the product of its inverse with some vector, just like step-20 does. However unlike the dealii SolverCG class, PETScWrappers::SolverCG

[deal.II] Temporary distributed vectors

Dear developers and users I am trying to parallelize my incompressible navierstokes solver based on step-57. I am not sure how to initialize the various temporary distributed vectors in preconditioners. For example, I have a class called ApproximateMassSchur which equals B(diag(M))^{-1}B^T.

Re: [deal.II] General questions in distributed parallelization

Hi Wolfgang Thank you so much for the clear answer! Jie On Wednesday, December 6, 2017 at 3:14:46 PM UTC-5, Wolfgang Bangerth wrote: > > > Jie, > > > First I want to say, it is so much easier and more pleasant to work with > > PETScWrappers in dealii than writing PETSc code in C. Developing

[deal.II] General questions in distributed parallelization

Hello everyone First I want to say, it is so much easier and more pleasant to work with PETScWrappers in dealii than writing PETSc code in C. Developing finite element code based on dealii is 1000 times more efficient than writing from scratch! Recently I parallelized a time-dependent linear

Re: [deal.II] Assemble the rhs of time-dependent linear elasticity

Hi Wolfgang Thanks for your reply. I carefully tested these two methods and found that they produce two different rhs vectors given identical previous solution. There is no non-zero boundary values in my case, and the constrained values are indeed zero. It seems that the unconstrained

[deal.II] Assemble the rhs of time-dependent linear elasticity

Hi everyone I have a time-dependent linear elasticity solver which is different from step-17 in which I assume small-deformation all the time. Due to the time discretization, I have a -K*u^n term at the rhs of the system where u^n is the known displacement (at previous time step) and K is the

[deal.II] Re: deal.II's birthday

Thank all the developers for creating and maintaining such an awesome package! Jie On Friday, November 24, 2017 at 8:25:23 PM UTC-5, Wolfgang Bangerth wrote: > > > All, > today 20 years ago -- on November 24 1997 -- is the date of the first > commit > to the deal.II repository. If you had

Re: [deal.II] A_inverse in step-57

Hi Timo and Wolfgang It turns out the SparseILU needs to be tuned very carefully. I set the AdditioalData to (0.03, 0) the solver now works fine. Although it is still slower than UMFPACK. Maybe using just the right parameters in AdditionalData can further improve it. I observed similar thing in

Re: [deal.II] A_inverse in step-57

Hi Timo and Wolfgang I wrapped up my A preconditioner with an inner CG solver (I am using IMEX scheme which moves the convection term to the RHS so A is symmetric) but the SparseILU still seems not to work. I attached my code here, if you could take a look, it is very easy to reproduce the issue:

Re: [deal.II] A_inverse in step-57

Hi Timo Thanks for your answer! > Do you have an inner inner solve or do you just use a single SparseILU > application? I do not have an inner inner solve, I just use a single SparseILU initialized with system_matrix.block(0,0) to approximate its inverse. It is the trick used in

Re: [deal.II] A_inverse in step-57

Dear Timo It's been a month since I started this thread, during this time I managed to write a time-dependent navier-stokes solver with Grad-Div stablization using IMEX scheme. My major references are your PhD thesis (beautiful work by the way), Dr. Kronbichler's paper and steps 20, 22, 57. I

Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

Hi Martin and Wolfgang Thank you very much for the helpful comments and references. I'll start to read the works you mentioned. > Jie -- I think this would be a very interesting program for others as > well. > Would you be interested in contributing it to the code gallery? > I'd love

Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

Hi Wolfgang > but if you treat the nonlinearity implicitly, and time discretized model > will remain > nonlinear and needs to be solved with a Newton scheme or similar. The > appropriate solver for that system then remains FGMRES. > Thank you for your hints on my previous question. Now

[deal.II] Re: Calculating lift and drag

Hi Lucas > I am trying to replicate the results here > > > of the benchmark problem of flow around a cylinder (circle in 2D). Here is > my code so far: > It's been a long time since you posted this

[deal.II] A_inverse in step-57

Hi everyone I'm playing around with step-57. A 3D grid which is globally refined for 4 times has 4096 cells and 112724 dofs. Solving such a case is unbearably slow on my computer. I suspect it is due to the direct solver for SparseDirectUMFPACK solver for A_inverse in the

Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

Hi Wolfgang I do plan to use Newton's iteration + FGMRES. Based on your experience, does the preconditioner remain the same? Thanks Jie On Wednesday, October 4, 2017 at 6:24:25 PM UTC-4, Wolfgang Bangerth wrote: > > > > How hard would it be to first extend Step-57 to be non-steady, and then >

[deal.II] Re: 2D cantilever beam: reference to step-7,8,11,22

Hi there Like Wolfgang said, you need to elaborate your question. I ran your code and I did see positive x-displacement in a certain area. I guess your question was that you expected the grid to be actually deformed? If so, that is because your results were plotted on the original mesh. Look

Re: [deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

Hi Wolfgang It seems that the NS equation solver in this gallery code is based on projection method. The continuous Galerkin Finite Elements with high-order stabilization is used for the level set solver though. How hard would it be to first extend Step-57 to be non-steady, and then add

[deal.II] Petrov-Galerkin stabilization approach to solve Navier-Stoke equations

similar things. Any suggestions on how to solve the resulting matrix system of SUPG method are also welcome. Thank you Jie Cheng -- 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

Re: [deal.II] Output nodal scalar

Hi Jean-Paul Thanks for explaining it. Now I got both StrainPostprocessor and StressPostprocessor working! But it seems a little wasteful to have two separate classes because we are not reusing the gradient of displacement computed in StrainPostprocessor. Although it is tolerable, but it'll be

Re: [deal.II] Output nodal scalar

Hi Wolfgang I tried DataPostprocessorTensor as soon as the commits merged in. It is easy to use, I really like it! Thank you! Unfortunately there is still a bug that I couldn't figure out, which is basically the same as my previous post: after successfully writing the output, the program

Re: [deal.II] Output nodal scalar

Hi Wolfgang Thank you very much for adding this documentation! I'm trying to use the same technique on my linear elasticity problem. To compute the displacement gradient, the idea is to extract ux, uy, uz from the solution and then compute their individual gradients as you suggested. However I

[deal.II] Re: Output nodal scalar

Dear Jean-Paul Now I understand why the heuristic method is less preferable and have a better sense of the least square method in this context. Like a simple linear regression > , the > least-squares method will minimise the

[deal.II] Re: Output nodal scalar

Thank you Jean-Paul. I did not hear about L2-projection method before, but it seems that the L2-projection method also evaluates the stress tensor at the quadrature points and then finds the cell-averaged stress. The only difference compared with the heuristic method is that it solves AX = Y

[deal.II] Re: Output nodal scalar

ethod: Linear Static >> and Dynamic Finite Element Analysis}, >> Author = {Hughes, T. J.}, >> Publisher= {Dover Publications Inc.}, >> Year = {2000}, >> Address = {New York, USA}, >> No

[deal.II] Re: Output nodal scalar

more accurate representation of the > stress field than your approach. This should also be a relatively > inexpensive operation because solving the linear system only involves > inverting a mass matrix. > > Regards, > Jean-Paul > > On Thursday, August 24, 2017 at 5:13:2

[deal.II] Re: Output nodal scalar

Update: I switched to my old trick of nodal averaging method: take the average of the values at quadrature points, then add this average to the vertex dofs. And if a vertex is shared by n cells, divide the values at the related dofs by n. I am happy with the results because they look quite

[deal.II] Output nodal scalar

Hi everyone I'm trying to compute and output nodal stress and strain. Although there are already some helpful discussions, for example this and this

Re: [deal.II] Re: Reading Abaqus boundary conditions

Hi Jean-Paul and Wolfgang Following your suggestions, I found that the name of surfaces must be prefixed with SS, for example SS1. The SURF- prefix doesn't work. Now my program can apply boundary indicators to the target surfaces. I will write code to read the traction/pressure load and apply

[deal.II] Re: Reading Abaqus boundary conditions

ith this function. > You'd then have to interpret the meaning of each boundary on a case-by-case > basis for each mesh. > > I hope that this explains in sufficient detail why our mesh reader is as > limited as it is. > > Regards, > Jean-Paul > > On Thursday, August 17

[deal.II] Reading Abaqus boundary conditions

Hi all Recently I started to reconstruct my old hand-written finite element code with deal.II. Although deal.ii offers a lot of useful functionalities that make my life much easier, there is one thing I find inconvenient and not sure what to do. I'd like to read the mesh file from Abaqus,