Re: [deal.II] Unique FE evaluation on arbitrary points

Hi David, > I want to evaluate each point out of the cloud only once in case of a distributed triangulation. A quick (and dirty) solution would be to evaluate and perform the communication non-uniquely and pick out one of the received values at the end. See also

[deal.II] Publications based on deal.II

All, as you may know, we try to list all publications based on deal.II at http://dealii.org/publications.html We use this list to justify the effort we spend on writing this software, both to our universities as well as the funding agencies that support its development. In anticipation

[deal.II] dealii-9.3.0 release candidate 1

Dear all, We have tagged a first release candidate for the upcoming deal.II 9.3.0 release. You can find the sources and a generated offline documentation here:   https://github.com/dealii/dealii/releases/tag/v9.3.0-rc1 Alternatively, you can switch to the dealii-9.3 branch in your local git

[deal.II] Re: std::set> : missing operator(s)

Hi Simon, you don't need to modify the point class. You can simply pas to the constructor of the set a comparator. See the first answer in https://stackoverflow.com/questions/2620862/using-custom-stdset-comparator. Hope this helps, PM On Sunday, 27 June 2021 at 12:15:40 UTC+2 Simon wrote: >

[deal.II] Marc Fehling appointed principal developer of deal.II

Dear all, it's our pleasure to announce that we have appointed Marc Fehling as a principal-developer of deal.II! I guess many of you already know him through meetings at workshops or interactions here or on GitHub but nevertheless let me introduce Marc to you quickly. Marc has started using

[deal.II] Re: Step-7 Extension : How to get the runtime at each cycle to plot it

Dear Pushkar, it seems that the convergence table is already outputted during the execution of the program. So all you have to do is to read, postprocess, and plot the data in your favorite programming language. You might want to checkout R (as shown in

Re: [deal.II] Re: Step-7 Extension : How to get the runtime at each cycle to plot it

e to plot the dofs vs error in julia but actually I am looking for > a way to output runtime at each cycle so that I can plot runtime Vs error. > > Regards > Pushkar > > On Mon, Mar 22, 2021 at 12:45 PM Peter Munch wrote: > >> Dear Pushkar, >> >> it seems

[deal.II] Re: deal.II-based FSI matrix-free solver / looking for a post-doc

Good luck at the defence! Hope it goes well! Peter On Sunday, 18 April 2021 at 00:44:44 UTC+2 mtwich...@gmail.com wrote: > Dear all, > I have developed a parallel matrix-free monolithic FSI solver in the ALE > frame of reference. Exemplary results [1 , 2 >

[deal.II] Re: Computing the solution gradient at the quadrature point on a face

The return type should be `*Tensor<2,dim,NumberType>*` shouldn't it? Hope this helps. If not, could describe how the code does not work? It it not compiling? Is the result wrong? PM On Sunday, 1 August 2021 at 04:09:45 UTC+2 lian...@gmail.com wrote: > Dear All, > > I want to do a surface

[deal.II] Re: Meshing complex geometries

Hi Kaushik, > Is there a plan for relaxing this limitation in the future? Is there any other way to do this? Unfortunately, there are currently no active developments regarding anisotropic refinement. Would it be an option to refine isotropically? Latter works very well

[deal.II] Re: Computing the global index values from vertex iterator

That should fix the issue: https://github.com/dealii/dealii/pull/13429 Peter On Sunday, 20 February 2022 at 22:06:02 UTC+1 reza@gmail.com wrote: > Hi all, > > I am maintaining a code containing a function to obtain the global dof > numbers of a vertex based on a given vertex iterator

[deal.II] Re: Vlasov equation integration issue (hyper.deal)

Hi Alexander, Nice that you found hyper.deal! Since this seems to be more a hyper.deal related issue, I would suggest to move the discussion to: https://github.com/hyperdeal/hyperdeal/discussions. On the first glance, the code seems to be correct but I have one or two ideas how to simplify

[deal.II] Re: Periodic bc for dim=1

What do you mean by "does not work for 1D"? In hyper.deal (https://github.com/hyperdeal/hyperdeal), we also have PBC in "1D". Peter On Tuesday, 8 February 2022 at 06:34:42 UTC+1 Praveen C wrote: > Dear all > > I was trying to write a code that works for 1/2/3d navier stokes. > > But it seems

[deal.II] Re: Flag cells to be refined more than one levels?

Hi Greg, I guess what you could do is to treat the vector as vector associated with a DoFHandler with FE_DGQ(0). During each refinement you "interpolate" the vector to the new mesh and decrease the value by one. This approach naturally extends to a parallel setting. Alternately, you could

[deal.II] Re: Using MatrixFree functionality without distributed arrays

Hi Corbin, Vector and LiearAlgebra::Vector should work work with MatrixFree. If not let us know what (compilation) errors you get. Alternatively, you can use LinearAlgebra::distributed::Vector and run the program with a single process. Hope that helps, Peter On Monday, 23 May 2022 at

[deal.II] Re: Using AMR with MatrixFree

The problem is that ECL is not working with AMR, yet. A technical issue is that one cannot that easily loop over 2*dim faces and compute the fluxes for each but also has to go over the subfaces when the neighbor is refined. One might be able to hide this in FEFaceEvaluation and load the values

[deal.II] Re: DoFTools::make_periodicity_constraints error when working with FEColleciton

Hi Rose, the assert was definitely not positioned at the right place and checked on every face - even on non-active ones. I have moved it in the PR https://github.com/dealii/dealii/pull/14091. Now this assert is not triggered. Generally, I am wondering if hp and PBC is working. At least, I

Re: [deal.II] Re: Using AMR with MatrixFree

from a matrix-free loop with a cell iterator from > Triangulation or DoFHandler. > > Best regards, > Alexander Kiselyov > > On Thu, 2022-07-07 at 12:55 -0700, Peter Munch wrote: > > The problem is that ECL is not working with AMR, yet. > > A technical issue is that one

[deal.II] Re: Different resulting meshes in spatial adaptivity for d::p::d::triangulation and d::triangulation

Hi Maurice, deal.II 9.0.1 is quite old, don't you want to update ;) If I understand this is the first refinement step. So results should be the same if you do everything the same. Question: with how many MPI processes are you running the `p::d::triangulation` simulation? Could you try to run

[deal.II] Re: Evaluating a field at a point

I guess for your purpose, `VectorTools::point_values()` and `VectorTools::point_gradients()` are more useful and it works in parallel. If the location of the points do not change, they are cached in RemotePointEvaluation. > If I am not refining the mesh, is there a more efficient why of

[deal.II] Re: Does deal.II support readin a matirx market file and plot it sturcture out.

I am not familiar with these files. But the example given on their webpage (https://math.nist.gov/MatrixMarket/mmio/c/example_read.c) shows how to read such a file in C. The same code can be used to fill a deal.II SparsityPattern (see SparsityPattern::add_entries()). You can use e.g.

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

sed > significantly. > > Thank you all! > > -Simon > > Am Sa., 22. Okt. 2022 um 12:57 Uhr schrieb Peter Munch < > peterr...@gmail.com>: > >> You are right. Release 9.3 uses the slow path for MappingQ. The reason is >> that here >> https://github.com/deali

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

You are right. Release 9.3 uses the slow path for MappingQ. The reason is that here https://github.com/dealii/dealii/blob/ccfaddc2bab172d9d139dabc044d028f65bb480a/include/deal.II/matrix_free/fe_point_evaluation.h#L708-L711 we check for MappingQGeneric. At that time MappingQ and MappingQGeneric

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

ersion 9.3.2, the cpu > time is about 18.7 seconds. > Crudely, the .reinit function associated with the FEPointEvaluation > objects is called about 1.2 million times. > > Best, > Simon > > Am Sa., 22. Okt. 2022 um 17:09 Uhr schrieb Peter Munch < > peterr...@gmail.com>:

Re: [deal.II] Re: measuring cpu and wall time for assembly routine

> FEPointEvaluation creates an FEValues object along with a quadrature object under the hood. Closer inspection revealed that all constructors, destructors,... associated with FEPointEvaluation need roughly 5000 instructions more (per call!). That said, FEValues is indeed the faster approach, at

[deal.II] Re: Run time analysis for step-75 with matrix-free or matrix-based method

Hi Wayne, your numbers make totally sense. Don't forget that you are running for high order: degree=6! The number of non-zeroes per element-stiffness matrix is ((degree + 1)^dim)^2 and the cost of computing the element stiffness matrix is even ((degree + 1)^dim)^3 if I am not mistaken (3

[deal.II] Re: Importing Tetrahedron mesh from Abaqus into dealii

Hi Masoud, it seems that read_abaqus() calls read_ucd() and the the latter has been not generalized for simplex meshes yet. See: https://github.com/dealii/dealii/blob/ee0a4995de1009875a4a5572ca14bde8a1979ad5/source/grid/grid_in.cc#L948-L950. I am a bit surprised that you did not get an error

[deal.II] Re: Trying to increase precision of floating point values in step3 of tutorial

> It is binary and so outputs as many digits as there are in a 32-bit floating point number. @WB Which is equivalent to "deal.ii outputs the solution vector values upto 7 decimal" if I am not mistaken. To be able to switch between double and single precision would be nice. It's not the first

Re: [deal.II] Re: Matrix-based p-multigrid preconditioning

Yes. Peter On 07.10.22 07:44, 'yy.wayne' via deal.II User Group wrote: I see. So that's why we create a new dof_handlers in solve_with_gmg() function instead of continue using dof_handler as other tutorials. If I want to build mg_matrices and their SparsityPattern, they should based on

[deal.II] Re: Matrix-based p-multigrid preconditioning

Hej, > One thing I'm confused is that why we use "make_hanging_node_constraints" and "interpolate_boundary_values" for a new constraints in solve_with_gmg in step-75, instead of the boundary_constraints as done in previous MG tutorials. Your observation is correct. It is related to the fact

Re: [deal.II] Assemble system slowing down the program

You are creating a new instance of FEValues at each quadrature point. This is a very expensive operation, since there all the shape functions are evaluated. Try to reuse that by passing it to the function as a parameter. Hope that helps! Peter On Sunday, 8 January 2023 at 09:58:41 UTC+1

Re: [deal.II] Assemble system slowing down the program

Change: > float H_plus(Vector solution_elastic, const auto cell,const unsigned int q_point, * FEValues<2> fe_values_damage*); to: > float H_plus(Vector solution_elastic, const auto cell,const unsigned int q_point, * const FEValues<2> & fe_values_damage*); Peter On

[deal.II] Re: matrix-free vector FEM with Nedelec space

Hi Abbas, Vinta, and Wayne, it's nice to see that there is increasing interest regarding doing matrix-free computations with Nedelec elements! It's a very interesting and cool topic. Unfortunately, there has been no progress regarding our Nedlec elements on our (matrix-free) side in the last

[deal.II] Re: Boundary conditions besides Dirichlet BC for Multigrid

Hi Wayne, you can attache your own constraints as shown here: https://github.com/dealii/dealii/blob/2376c62a4b89953b74801852983eb8556930d54d/tests/numerics/no_flux_18.cc#L1136-L1146 Hope this helps! Peter On Wednesday, 21 December 2022 at 02:44:42 UTC+1 yy.wayne wrote: > Hi guys, I have a

[deal.II] Re: How to specify finite element component in MatrixFree?

Hi Wayne, currently MGTransferBlockGlobalCoarsening takes in the constructor only a single MGTransferGlobalCoarsening instance and uses this for all blocks (i.e., uses the same AffineConstraints instance for all blocks):

[deal.II] Re: Getting global DoF indices of a face

Hi Alexander, You are using FE_DGQ, which per definition only has DoFs in the cell. Switch to quadratic FE_Q and then your idea with the dummy DoFHandler to globally uniquely identify faces should work! Not sure why you create a system!? Peter On Friday, 18 November 2022 at 18:30:38 UTC+1

[deal.II] Re: some problems about step37

In this tutorial, multigrid is using Chebysev sweeps around a point Jacobi solver as smoother. Latter needs the (inverse) of the diagonal. Hope this helps. Peter On Friday, January 27, 2023 at 11:07:21 AM UTC+1 13274...@163.com wrote: > hello everyone！ > I am learning about the step37 and

[deal.II] Re: How to specify finite element component in MatrixFree?

Hi Wayne, in that case I would provide the same DoFHandler to MatrixFree twice and two different AffineConstraint objects. See the version of MatrixFree::reinit() that takes vectors https://www.dealii.org/developer/doxygen/deal.II/classMatrixFree.html#abb081e301fadbfd94e0169611bae3838. Peter

[deal.II] Re: Solve distributed BlockVector with direct solver

If it is not too expensive, I would copy the block vector to the normal distributed vector. For this purpose, I use functions like these: ``` template void split_up_components_fast(const VectorType , BlockVectorType ) { for (unsigned int i = 0, j = 0; i <

[deal.II] Re: Apply boundary integral to diagonal in MatrixFree

Hi, you are right such a function is unfortunately missing in deal.II. It has been on my TODO list for a long time but I didn't get around to implement it, since I haven't had to use DG for a while and in most of my applications I can move the BCs to the RHS. Setting up the matrix is not

[deal.II] Re: How to specify finite element component in MatrixFree?

Hi The block version of MGTransferGlobalCoarsening is MGTransferBlockGlobalCoarsening (see https://www.dealii.org/developer/doxygen/deal.II/classMGTransferBlockGlobalCoarsening.html). I don't know the details of step-29. But what I would recommend you to do is to take a look at

[deal.II] Re: How to specify finite element component in MatrixFree?

Hi Wayne, > The solution in HeatProblem is a non-complex one then(half size of src and dst processed in MatrixFree operator)? We are solving equation (10) from the paper; it is the reformulated version of equation (9), which is a complex system. The heat equation is indeed not complex; but

[deal.II] Re: Marking cells at interface between subdomains

Hi Jose, not sure. You could use Triangulation::global_active_cell_index_partitioner() to initialize a distributed vector, access it via CellAccessor::global_active_cell_index(), and update the ghost values. Peter On Tuesday, March 21, 2023 at 10:47:14 AM UTC+1 jose.a...@gmail.com wrote: >

[deal.II] Re: Fully distributed triangulation with GMSH

Hi Kumar, take a look at https://www.dealii.org/developer/doxygen/deal.II/namespaceTriangulationDescription_1_1Utilities.html#aefc3e841bcfd37714a07d04e42c8ffca. Hope this helps, Peter On Wednesday, 15 March 2023 at 01:44:17 UTC+1 kumar.sau...@gmail.com wrote: > Hi, > > I am trying to

[deal.II] Re: Remove constraints at some DoF

I don't see a remove function in AffineConstraints. What you could do is to create a new AffineConstrains instance based on the old one by ignoring the unwanted entry. See also:

[deal.II] Re: anisotropic polynomial degree

Hi Greg, unfortunately we do not support anisotropic polynomials: we make the assumption that all faces (of the same type) and lines have the same number of DoFs. For what do you need such polynomial spaces? Best, Peter On Saturday, 11 March 2023 at 15:05:25 UTC+1 ygre...@gmail.com wrote: >

[deal.II] deal.II at SIAM CSE (Amsterdam)

Dear all, Next week is the SIAM CSE conference in Amsterdam - finally again in person. Many of the deal.II developer will be attending the conference and will give talks. We are wondering who else is attending the SIAM CSE this year? We will have a common lunch/dinner during the days (maybe

[deal.II] Re: Specify vectorization length

Hi Wayne, What is you error message? > I replace all FEEvaluation, MatrixFree and VectorizedArray construction with a VectorizedArray, but make returns some intricate error. Is specify vectorization length possible? I think I've seen one in dealii/test ... Yes, it is possible and the to

[deal.II] Re: Specify vectorization length

What version of deal.II are you using. I thought we fixed the vector-valued version: https://github.com/dealii/dealii/commit/6351f255d16c3cf465752e2ce943726df6bf4ea4 Peter On Thursday, 23 February 2023 at 15:13:42 UTC+1 yy.wayne wrote: > I think the problem exists for vector-valued problem. >

[deal.II] Re: Specify vectorization length

It should be part of the 9.4.1 point release. Peter On Thursday, 23 February 2023 at 15:20:14 UTC+1 yy.wayne wrote: > I'm using deal.II 9.4.0. It seems bug are fixed... > 在2023年2月23日星期四 UTC+8 22:16:47 写道： > >> What version of deal.II are you using. I thought we fixed the >> vector-valued

Re: [deal.II] Re: exadg installation error ‘class dealii::CellAccessor<3, 3>’ has no member named ‘as_dof_handler_iterator’

As stated above. This is not a deal.II issue. The function has been introduced since the last release and is only part of the master branch. I have added some ifdefs in https://github.com/exadg/exadg/pull/402. However, I am not sure if this enough to make the code compatible with deal.II 9.4...

Re: [deal.II] Convergence failure in step 0.

Hi Wayne, it seems that you are using multigrid on a locally refined mesh. Have you tried to use globally refined meshes? This one does not have inner boundaries so that the issue should not occur. Does it? You might have forgotten to attach the constrains to the transfer operator:

[deal.II] Re: exadg installation error ‘class dealii::CellAccessor<3, 3>’ has no member named ‘as_dof_handler_iterator’

Hej Sooraj, CellAccessor::as_dof_handler_iterator() was added since the 9.3 release. It looks like ExaDG is not compatible with the 9.3. release but only with master. I would suggest that you report this at the ExaDG project (https://github.com/exadg/exadg/discussions) and than we decide if

Re: [deal.II] Re: step-37 multiple DoFHandler's smoother problems

OK. The problem are these lines: https://github.com/dealii/dealii/blob/8d68b3192ed1c8b928dfce03ca1d615201859904/include/deal.II/matrix_free/operators.h#L1225-L1235. The number of rows are the sum of the number of DoFs of both attached DoFHandlers... Personally, I would not use these

Re: [deal.II] Re: step-37 multiple DoFHandler's smoother problems

I'll try to take a look at the issue tomorrow. Could you attach the full code. I have a feeling what might be an issue. Peter On Tue, Jun 27, 2023, 18:18 Sean Johnson wrote: > Okay. Thank you. > > On Tuesday, June 27, 2023 at 10:02:16 AM UTC-6 Wolfgang Bangerth wrote: > >> On 6/27/23 09:53,

[deal.II] Re: Could not find partitioner that fits vector

Hi Wayne, my best guess it that the partitioners in the multigrid operator and the matrix-free operators not match, with the result that a vector with wrong ghosting coming from the multigrid operator is used as src/dst in the matrix-free loop resulting in the assert you show. Previously,

[deal.II] Re: Could not find partitioner that fits vector

Thanks! Peter On Sunday, 7 May 2023 at 09:27:34 UTC+2 yy.wayne wrote: > I'll try add build function to MGTransferBlockMatrixFree then. > Thank you. > > Best, > Wayne > > 在2023年5月7日星期日 UTC+8 15:23:12 写道： > >> > I wonder will the unmatched partitioners occur even coding is correct? >> >> Yes.

[deal.II] Re: Could not find partitioner that fits vector

> I wonder will the unmatched partitioners occur even coding is correct? Yes. The requirements of MG and the level operators are not identical. If you don't do anything special, the vector are set up for MG and not the level operators. With the help of external partitioners you can fix this

[deal.II] Re: MGTransferGlobalCoarsening with Nedelec element

Hi Ce Qin, There is a WIP PR for adding a fallback path to MGTransferMF: https://github.com/dealii/dealii/pull/12924. The PR is already 2 years old and has merge conflicts with master. But I guess the changes would be similar on master. Best, Peter On Wednesday, 15 November 2023 at 08:30:00

Re: [deal.II] Re: Flag cells to be refined more than one levels?

Hi Greg, good that you find a working solution! However, I would suggest against using `VectorTools::interpolate_to_different_mesd` but use `SolutionTransfer` or `parallel::distributed::SolutionTransfer` to move the refinement information from a coarse mesh to a fine mesh. You can take a look