### Re: [deal.II] Periodic boundary conditions in Newton's method

Hi Dr. Bangerth, Thanks so much for the suggestion! My code works after applying the constraint on the Newton update! Best, Jimmy On Monday, September 7, 2020 at 11:01:53 PM UTC-5, Wolfgang Bangerth wrote: > > On 9/7/20 6:40 PM, Jimmy Ho wrote: > > > > I have a general question regarding the application of periodic boundary > > conditions in Newton's method when solving nonlinear equations. Should > the > > periodic constraint be applied to the incremental Newton update, or > directly > > to the total solution vector? > > Periodicity constraints are not too different from the way you would deal > with > Dirichlet boundary conditions. step-15 discusses this in great length, and > the > solution is to make sure that your first iteration satisfies the > periodicity > constraints and that all updates do as well -- which ensures that all > iterates > do so, too. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/ad19b669-acb2-422a-9b1a-e4e08c01ed69o%40googlegroups.com.

### [deal.II] Periodic boundary conditions in Newton's method

Hi All, I have a general question regarding the application of periodic boundary conditions in Newton's method when solving nonlinear equations. Should the periodic constraint be applied to the incremental Newton update, or directly to the total solution vector? Thanks in advance for any suggestions! Best, Jimmy -- 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/d89f0448-ff6d-4658-87a1-d93ea40c316do%40googlegroups.com.

### Re: [deal.II] Connecting UMFPACK in deal.II to Trilinos's Amesos solver

Hi Dr. Bangerth, Thanks a lot for your guidance! I will install an external copy of UMFPACK and see what happens! Best, Jimmy On Tuesday, August 4, 2020 at 5:23:09 PM UTC-5, Wolfgang Bangerth wrote: > > On 8/4/20 3:56 PM, Jimmy Ho wrote: > > > > So, what should I do to properly connect UMFPACK in deal.II to Trilinos? > Any > > suggestions are highly appreciated! > > It's not going to work this way, I'm afraid. Trilinos wants a link to an > external installation of UMFPACK (or SparseSuite, of which it is part of > these > days). deal.II doesn't actually create such an installation and instead > just > links everything into the deal.II libraries. > > So what you want to do is to download UMFPACK, install it on your system, > and > point Trilinos to the installation. > > (UMFPACK is still going to be part of the deal.II libraries, but that > shouldn't create any problems.) > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/7dc9b8d3-d128-4015-8b77-fa95461f6b76o%40googlegroups.com.

### [deal.II] Connecting UMFPACK in deal.II to Trilinos's Amesos solver

Hi All, I am trying to use UMFPACK through Trilinos (V.12.18.1) Amesos solver. Since UMFPACK is bundled with deal.ii and was configured to work in deal.ii before, I was trying to point Trilinos to that installation of UMFPACK. Following the README file on interfacing deal.II with Trilinos, I used the following config file (Also attached): mkdir build cd build cmake\ -DTrilinos_ENABLE_Amesos=ON \ -DTrilinos_ENABLE_Epetra=ON \ -DTrilinos_ENABLE_EpetraExt=ON \ -DTrilinos_ENABLE_Ifpack=ON \ -DTrilinos_ENABLE_AztecOO=ON \ -DTrilinos_ENABLE_Sacado=ON \ -DTrilinos_ENABLE_Teuchos=ON \ -DTrilinos_ENABLE_MueLu=ON \ -DTrilinos_ENABLE_ML=ON \ -DTrilinos_ENABLE_ROL=ON \ -DTrilinos_ENABLE_Tpetra=ON \ -DTeuchos_ENABLE_COMPLEX:BOOL=ON \ -DTeuchos_ENABLE_FLOAT:BOOL=ON \ -DTpetra_INST_FLOAT=ON \ -DTpetra_INST_COMPLEX_DOUBLE=ON \ -DTpetra_INST_COMPLEX_FLOAT=ON \ -DTrilinos_ENABLE_Zoltan=ON \ -DTrilinos_VERBOSE_CONFIGURE=OFF \ -DTPL_ENABLE_MPI=ON \ -DTPL_ENABLE_UMFPACK:BOOL=ON \ -DTPL_UMFPACK_INCLUDE_DIRS='/home/hippo/dealii-9.1.1/bundled/umfpack/AMD/Include;/home/hippo/dealii-9.1.1/bundled/umfpack/UMFPACK/Include' \ -DBUILD_SHARED_LIBS=ON \ -DCMAKE_VERBOSE_MAKEFILE=OFF \ -DCMAKE_BUILD_TYPE=RELEASE \ -DCMAKE_INSTALL_PREFIX:PATH=/home/hippo/Trilinos-12-18-1/myBuild \ ../ where the only difference from before was I added: -DTPL_ENABLE_UMFPACK:BOOL=ON \ -DTPL_UMFPACK_INCLUDE_DIRS='/home/hippo/dealii-9.1.1/bundled/umfpack/AMD/Include;/home/hippo/dealii-9.1.1/bundled/umfpack/UMFPACK/Include' \ to point to the two include folders of UMFPACK in deal.II. However, upon running the shell script, I got the following error: Processing enabled TPL: UMFPACK (enabled explicitly, disable with -DTPL_ENABLE_UMFPACK=OFF) -- UMFPACK_LIBRARY_NAMES='umfpack;amd' -- Searching for libs in UMFPACK_LIBRARY_DIRS='' -- Searching for a lib in the set "umfpack": -- Searching for lib 'umfpack' ... -- NOTE: Did not find a lib in the lib set "umfpack" for the TPL 'UMFPACK'! -- ERROR: Could not find the libraries for the TPL 'UMFPACK'! -- TIP: If the TPL 'UMFPACK' is on your system then you can set: -DUMFPACK_LIBRARY_DIRS=';;...' to point to the directories where these libraries may be found. Or, just set: -DTPL_UMFPACK_LIBRARIES=';;...' to point to the full paths for the libraries which will bypass any search for libraries and these libraries will be used without question in the build. (But this will result in a build-time error if not all of the necessary symbols are found.) -- ERROR: Failed finding all of the parts of TPL 'UMFPACK' (see above), Aborting! After reading through the error message, it appears that it needs a directory to find the UMFPACK libraries. So I changed the two config lines to be: -DTPL_ENABLE_UMFPACK:BOOL=ON \ -DUMFPACK_LIBRARY_DIRS:FILEPATH='/home/hippo/dealii-9.1.1/bundled/umfpack/AMD;/home/hippo/dealii-9.1.1/bundled/umfpack/UMFPACK' \ to point to the folder that the source codes live in. However, now I get this (essentially the same) error message: Processing enabled TPL: UMFPACK (enabled explicitly, disable with -DTPL_ENABLE_UMFPACK=OFF) -- UMFPACK_LIBRARY_NAMES='umfpack;amd' -- Searching for libs in UMFPACK_LIBRARY_DIRS='/home/hippo/dealii-9.1.1/bundled/umfpack/AMD;/home/hippo/dealii-9.1.1/bundled/umfpack/UMFPACK' -- Searching for a lib in the set "umfpack": -- Searching for lib 'umfpack' ... -- NOTE: Did not find a lib in the lib set "umfpack" for the TPL 'UMFPACK'! -- ERROR: Could not find the libraries for the TPL 'UMFPACK'! -- TIP: If the TPL 'UMFPACK' is on your system then you can set: -DUMFPACK_LIBRARY_DIRS=';;...' to point to the directories where these libraries may be found. Or, just set: -DTPL_UMFPACK_LIBRARIES=';;...' to point to the full paths for the libraries which will bypass any search for libraries and these libraries will be used without question in the build. (But this will result in a build-time error if not all of the necessary symbols are found.) -- ERROR: Failed finding all of the parts of TPL 'UMFPACK' (see above), Aborting! So, what should I do to properly connect UMFPACK in deal.II to Trilinos? Any suggestions are highly appreciated! Best, Jimmy -- 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 ---

### Re: [deal.II] Question about the numbering of DoFs

Hi Yuesu, To be more precise: Yes, you do have two sets of basis functions in each element. A quadratic one for interpolating the vector components, and a linear one for interpolating the scalar. But when calculating DOFs associated with the vector components, you should only count the basis functions that interpolate those components, which is one basis function per node. Hope this helps! Best, Jimmy -- 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/feed2cda-81f9-4e22-8089-beaf9b2ae2b0o%40googlegroups.com.

### Re: [deal.II] Question about the numbering of DoFs

Hi Yuesu, The 2 in the initialization means that the basis functions (hence the finite element for the vector part) are quadratic. Which means that each element has 9 nodes. But you should still only have one basis function associated with each node. That's why you have 9*2=18 DOFs associated with the vector problem. Best, Jimmy -- 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/36d98292-937c-4524-a8d6-5c76f4cabf5bo%40googlegroups.com.

### [deal.II] Question about the numbering of DoFs

Hi Yuesu, When you have a vector-valued finite element, different components of the vector are still interpolated using the same basis functions. So you can have two DOFs on each node, but there's only one basis function associated with this node. Hope that helps! Best, Jimmy -- 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/3c3bd51a-eaf4-49ce-af0f-fd6477100123o%40googlegroups.com.

### Re: [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

Hi Dr. Bangerth, Thanks a lot for the clarification! They are really helpful! Best, Jimmy On Thursday, July 30, 2020 at 11:47:21 AM UTC-5, Wolfgang Bangerth wrote: > > On 7/30/20 10:11 AM, Jimmy Ho wrote: > > > > As a follow-up question, upon calling compress(), will the local copy of > the > > system matrix on a specific processor get updated to contain information > from > > all other processors? In other words, if I print out the system matrix > from a > > particular processor after calling compress(), is that the same global > system > > matrix that the linear solver is solving? > > Each processor only stores a subset of the rows of the matrix. During > assembly, each processor computes a number of matrix entries, but it can > not > compute all entries for the rows of the matrix it owns -- some need > contributions from other processes. The call to compress() makes sure the > contributions from these other processes are sent to the one that owns > these > rows of the matrix. > > In any case, after compress(), the rows each processor owns are correct -- > but > each processor doesn't know anything about the rows of the matrix it > doesn't own. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/b424e816-cd22-4854-b432-d9d9d745ae8do%40googlegroups.com.

### Re: [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

Hi Dr. Bangerth, As a follow-up question, upon calling compress(), will the local copy of the system matrix on a specific processor get updated to contain information from all other processors? In other words, if I print out the system matrix from a particular processor after calling compress(), is that the same global system matrix that the linear solver is solving? Thanks a lot for clarifying! Best, Jimmy On Wednesday, July 29, 2020 at 9:55:38 AM UTC-5, Wolfgang Bangerth wrote: > > > Jimmy, > > > A minimum example to reproduce this is attached. When the mesh is built > using > > GridGenerator::hyper_cube or GridGenerator::subdivided_hyper_rectangle > with > > subsequent refinement, the program works as expected. When the same mesh > is > > generated using GridGenerator::subdivided_hyper_rectangle without any > > subsequent refinement, some entries in the global stiffness matrix (the > nodes > > on the right hand side of the mesh, in this case, using 2 processors) do > not > > get updated. The example output of stiffness matrices when using one and > two > > processors are also attached for reference. > > > > So my question is, is this the expected behavior of the function? If so, > why > > is that the case? > > There is still a lot of stuff in the program that could be remove, > including > all of the comments, to make it substantially smaller and easier to > understand. > > I don't know whether there is a bug, but here is a suggestion: The finite > element solution u_h(x) that results from the linear system should be the > same > independent of the partitioning. But the order of degrees of freedom may > be > different, and consequently the matrix may not be the same -- it should > only > be the same up to some column and row permutation. Have you verified that > the > *solution function* (not the solution vector) that results is the same > independent of the number of processors? > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/39a0b8f8-c0f4-437d-b70c-7eed4295b13co%40googlegroups.com.

### Re: [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

Hi Dr. Bangerth, Thanks a lot for your guidance! I compared the solution in the vtu files using the minimal example above, they are nearly identical. Looking back into the code, I am outputting the system matrix from processor 0, which probably only printed the part that it locally owns, hence there's a difference in the matrices when running in serial and parallel. I guess I rushed to conclusion too quickly. Best, Jimmy On Wednesday, July 29, 2020 at 9:55:38 AM UTC-5, Wolfgang Bangerth wrote: > > > Jimmy, > > > A minimum example to reproduce this is attached. When the mesh is built > using > > GridGenerator::hyper_cube or GridGenerator::subdivided_hyper_rectangle > with > > subsequent refinement, the program works as expected. When the same mesh > is > > generated using GridGenerator::subdivided_hyper_rectangle without any > > subsequent refinement, some entries in the global stiffness matrix (the > nodes > > on the right hand side of the mesh, in this case, using 2 processors) do > not > > get updated. The example output of stiffness matrices when using one and > two > > processors are also attached for reference. > > > > So my question is, is this the expected behavior of the function? If so, > why > > is that the case? > > There is still a lot of stuff in the program that could be remove, > including > all of the comments, to make it substantially smaller and easier to > understand. > > I don't know whether there is a bug, but here is a suggestion: The finite > element solution u_h(x) that results from the linear system should be the > same > independent of the partitioning. But the order of degrees of freedom may > be > different, and consequently the matrix may not be the same -- it should > only > be the same up to some column and row permutation. Have you verified that > the > *solution function* (not the solution vector) that results is the same > independent of the number of processors? > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/285f4af3-3e01-4cd8-bcf0-9e6062a53967o%40googlegroups.com.

### [deal.II] Unexpected behavior when using GridGenerator::subdivided_hyper_rectangle in parallel

Hi All, I am using the Step 40 tutorial to build a parallel program using MPI. The code runs but generates different results when using one and multiple processors. After stripping it down to the bare minimum, it appears that when the mesh is built using GridGenerator::subdivided_hyper_rectangle without any subsequent refinement, the compress() function does not work properly, leading to a different global stiffness when using multiple processors. A minimum example to reproduce this is attached. When the mesh is built using GridGenerator::hyper_cube or GridGenerator::subdivided_hyper_rectangle with subsequent refinement, the program works as expected. When the same mesh is generated using GridGenerator::subdivided_hyper_rectangle without any subsequent refinement, some entries in the global stiffness matrix (the nodes on the right hand side of the mesh, in this case, using 2 processors) do not get updated. The example output of stiffness matrices when using one and two processors are also attached for reference. So my question is, is this the expected behavior of the function? If so, why is that the case? Thanks a lot for any answers! Your inputs are highly appreciated! Best, Jimmy -- 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/35ccb8ca-855d-4b01-95e7-cd549b947db5o%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 */ // @sect3{Include files} // // Most of the include files we need for this program have already been // discussed in previous programs. In particular, all of the following should // already be familiar friends: #include #include #include #include // uncomment the following #define if you have PETSc and Trilinos installed // and you prefer using Trilinos in this example: #define FORCE_USE_OF_TRILINOS // This will either import PETSc or TrilinosWrappers into the namespace // LA. Note that we are defining the macro USE_PETSC_LA so that we can detect // if we are using PETSc (see solve() for an example where this is necessary) namespace LA { #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 // The following, however, will be new or be used in new roles. Let's walk // through them. The first of these will provide the tools of the // Utilities::System namespace that we will use to query things like the // number of processors associated with the current MPI universe, or the // number within this universe the processor this job runs on is: #include // The next one provides a class, ConditionOStream that allows us to write // code that would output things to a stream (such as std::cout // on every processor but throws the text away on all but one of them. We // could achieve the same by simply putting an if statement in // front of each place where we may generate output, but this doesn't make the // code any prettier. In addition, the condition whether this processor should // or should not produce output to the screen is the same every time -- and // consequently it should be simple enough to put it into the statements that // generate output itself. #include // After these preliminaries, here is where it becomes more interesting. As // mentioned in the @ref distributed module, one of the fundamental truths of // solving problems on large numbers of processors is that there is no way for // any processor to store everything (e.g. information

### Re: [deal.II] Output cell variables as cell arrays in vtu files

Hi Dr. Bangerth, Thanks a lot for pointing me to the right direction! That's what I am looking for! Best, Jimmy On Monday, July 27, 2020 at 3:55:41 PM UTC-5, Wolfgang Bangerth wrote: > > On 7/27/20 2:47 PM, Jimmy Ho wrote: > > > > data_out.add_data_vector( cellData , "Name" , data_out.type_cell_data ); > > > > to force deal.ii to recognize that "cellData" should be interpreted as a > > cell-based data. When I read the vtu files generated by this program via > > ParaView, I found that although cellData looks like it is cell-based in > the > > visualization (i.e., it is discontinuous over the cells), the data array > > itself is stored as a point array, so I couldn't use the > > Cell_Data_to_Point_Data filter to get a smoothed and continuous > visualization. > > So, is there a way to write a cell-based data into cell arrays in vtu > files? > > No, all data produced by DataOut is point data. For cell-wise constants, > it is > just written in a way that makes point data look piecewise constant. > > You will have to find a different way to achieve what that filter does. > What > does it do? Maybe we can suggest a way to achieve the same from within > deal.II. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/a8641b6e-e158-4f66-8e23-937b1078ae07o%40googlegroups.com.

### Re: [deal.II] Output cell variables as cell arrays in vtu files

Hi Dr. Bangerth, Thanks a lot for your fast response! That's good to know! The Cell_Data_to_Point_Data filter in ParaView averages the adjacent cell values and assign them to the nodes, which produces a smooth and continuous nodal solution field. I was planning on implementing the averaging scheme myself but I was just looking to see if ParaView already has this functionality. In general, is there a built-in function from deal.ii that can performing nodal averaging? This can be very useful when someone tries to generate smooth and continuous visualization for integration point variables. Thanks again for the help! Best, Jimmy On Monday, July 27, 2020 at 3:55:41 PM UTC-5, Wolfgang Bangerth wrote: > > On 7/27/20 2:47 PM, Jimmy Ho wrote: > > > > data_out.add_data_vector( cellData , "Name" , data_out.type_cell_data ); > > > > to force deal.ii to recognize that "cellData" should be interpreted as a > > cell-based data. When I read the vtu files generated by this program via > > ParaView, I found that although cellData looks like it is cell-based in > the > > visualization (i.e., it is discontinuous over the cells), the data array > > itself is stored as a point array, so I couldn't use the > > Cell_Data_to_Point_Data filter to get a smoothed and continuous > visualization. > > So, is there a way to write a cell-based data into cell arrays in vtu > files? > > No, all data produced by DataOut is point data. For cell-wise constants, > it is > just written in a way that makes point data look piecewise constant. > > You will have to find a different way to achieve what that filter does. > What > does it do? Maybe we can suggest a way to achieve the same from within > deal.II. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/72d82f91-4861-465f-aab6-d67ae0b40cc1o%40googlegroups.com.

### [deal.II] Output cell variables as cell arrays in vtu files

Hi All, I am trying to compute the average of integration point variables and store them as cell variables, and subsequently write them as cell arrays in the visualization. I used: data_out.add_data_vector( cellData , "Name" , data_out.type_cell_data ); to force deal.ii to recognize that "cellData" should be interpreted as a cell-based data. When I read the vtu files generated by this program via ParaView, I found that although cellData looks like it is cell-based in the visualization (i.e., it is discontinuous over the cells), the data array itself is stored as a point array, so I couldn't use the Cell_Data_to_Point_Data filter to get a smoothed and continuous visualization. So, is there a way to write a cell-based data into cell arrays in vtu files? Thanks a lot for any suggestions! Any help from the group is highly appreciated! Best, Jimmy -- 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/3f442541-9fff-4da9-91f9-400e7751bb68o%40googlegroups.com.

### [deal.II] Re: An iterator for all nodes (including midside) in the mesh?

Hi Bruno, Thanks a lot for pointing me to the right direction! That is very helpful! Best, Jimmy On Monday, June 22, 2020 at 7:37:28 AM UTC-5, Bruno Turcksin wrote: > > Jimmy, > > Is this > https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-to-get-the-mapped-position-of-support-points-of-my-element > > what you are looking for? > > Best, > > Bruno > > On Monday, June 22, 2020 at 1:32:43 AM UTC-4, Jimmy Ho wrote: >> >> Dear All, >> >> I am trying to write a code to give initial condition for a vector of >> FullMatrix objects. The initial value of each entry of each matrix >> is uniquely defined by the corresponding nodal location. Hence, I am >> looking for an easy way to iterate all nodes (including mid-side nodes) in >> the mesh and access their coordinates. Is there a way to do so? >> >> I am aware of the Interpolate() function in VectorTools. However, the >> documentation for this function show that the input function to interpolate >> must have the same number of components as the number of components in the >> vector-valued finite element. This is not the case for me, since the >> initial values of the matrix are not directly linked to the DoFs of the >> finite element. I also considered making the entries of the matrices as >> extra DoFs of the finite element, then I will be able to use Interpolate() >> and some component masks to assign initial values. But this idea is >> sub-optimal, since in subsequent calculations, the values of the entries >> can be directly computed using other DoFs of the finite element as well as >> their previous values. So there's really no point posing them as additional >> DoFs of the finite element. Is there any suggestions on how to achieve this? >> >> Thanks a lot for any discussions and suggestions! Your help is much >> appreciated! >> >> Best, >> Jimmy >> > -- 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/d9d3255c-3020-40a4-b715-309648510c06o%40googlegroups.com.

### [deal.II] An iterator for all nodes (including midside) in the mesh?

Dear All, I am trying to write a code to give initial condition for a vector of FullMatrix objects. The initial value of each entry of each matrix is uniquely defined by the corresponding nodal location. Hence, I am looking for an easy way to iterate all nodes (including mid-side nodes) in the mesh and access their coordinates. Is there a way to do so? I am aware of the Interpolate() function in VectorTools. However, the documentation for this function show that the input function to interpolate must have the same number of components as the number of components in the vector-valued finite element. This is not the case for me, since the initial values of the matrix are not directly linked to the DoFs of the finite element. I also considered making the entries of the matrices as extra DoFs of the finite element, then I will be able to use Interpolate() and some component masks to assign initial values. But this idea is sub-optimal, since in subsequent calculations, the values of the entries can be directly computed using other DoFs of the finite element as well as their previous values. So there's really no point posing them as additional DoFs of the finite element. Is there any suggestions on how to achieve this? Thanks a lot for any discussions and suggestions! Your help is much appreciated! Best, Jimmy -- 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/b4387ec1-9f55-426e-89ff-f2f38386c251o%40googlegroups.com.