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

2020-09-08 Thread Jimmy Ho
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

2020-09-07 Thread Jimmy Ho
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

2020-08-04 Thread Jimmy Ho
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

2020-08-04 Thread Jimmy Ho
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

2020-08-02 Thread Jimmy Ho
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

2020-08-02 Thread Jimmy Ho
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

2020-08-02 Thread Jimmy Ho
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

2020-07-30 Thread Jimmy Ho
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

2020-07-30 Thread Jimmy Ho
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

2020-07-30 Thread Jimmy Ho
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

2020-07-28 Thread Jimmy Ho
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

2020-07-28 Thread Jimmy Ho
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

2020-07-27 Thread Jimmy Ho
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

2020-07-27 Thread Jimmy Ho
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?

2020-06-22 Thread Jimmy Ho
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?

2020-06-21 Thread Jimmy Ho
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.