Remove tabs and trailing white spaces (AMReX-Codes#1860)

The changes are purely white spaces only. `git diff -w development..HEAD`
shows nothing.  It was done with

```
find . -type d \( -name .git \
                  -o -path ./paper \
               \) -prune -o \
       -type f \( -name "*.H" -o -name "*.h" -o -name "*.hh" -o -name "*.hpp" \
                  -o -name "*.c" -o -name "*.cc" -o -name "*.cpp" -o -name "*.cxx" \
                  -o -name "*.f" -o -name "*.F" -o -name "*.f90" -o -name "*.F90" \
                  -o -name "*.py" \
                  -o -name "*.md" -o -name "*.rst" \
                  -o -name "*.sh" \
                  -o -name "*.tex" \
                  -o -name "*.txt" \
               \) \
    -exec grep -Iq . {} \; \
    -exec sed -i 's/[[:blank:]]\+$//g' {} + \
    -exec sed -i 's/\t/\ \ \ \ \ \ \ \ /g' {} +
```

We will add a CI check as a follow-up.

CONTRIBUTING.md

@@ -22,9 +22,9 @@ Development generally follows the following ideas:
          since these will be used for a squashed commit message.*
 
          Please note the following:
-            If you choose to make contributions to the code 
-            then you hereby grant a non-exclusive, royalty-free perpetual license 
-            to install, use, modify, prepare derivative works, 
+            If you choose to make contributions to the code
+            then you hereby grant a non-exclusive, royalty-free perpetual license
+            to install, use, modify, prepare derivative works,
             incorporate into other computer software,
             distribute, and sublicense such enhancements or derivative works
             thereof, in binary and source code form.
@@ -53,7 +53,7 @@ your fork.
 First, let us setup your local git repo. Make your own fork of the main
 (`upstream`) repository:
 on the [AMReX Github page](https://github.com/AMReX-Codes/amrex), press the
-fork button. 
+fork button.
 
 If you already had a fork of AMReX prior to 4/17/2020, we recommend deleting it and re-forking.
 This is due to a history re-write on the main repository. Note that you will lose any branches

Docs/Migration/Migration.md

@@ -16,7 +16,7 @@ environment variable `AMREX_HOME` is set to the AMReX directory.
 ## Step 0
 
 Make sure your code works with the [latest version of BoxLib on
-github](https://github.com/BoxLib-Codes/BoxLib). 
+github](https://github.com/BoxLib-Codes/BoxLib).
 
 ## Step 1
 
@@ -59,7 +59,7 @@ has been removed from AMReX.  This step has to be done manually.
   function does not change the pointers even though they may modify
   the data pointed by the pointers.  AMReX provides a number of
   functions that can convert from `unique_ptr<T>` to `T*`.   For
-  example, 
+  example,
   `Array<T*> GetArrOfPtrs (const Array<std::unique_ptr<T> >& a)`.
   These functions are in `Src/C_BaseLib/Array.H` as of writing,
   and they will be moved to `Src/Base/AMReX_Array.H`.
@@ -97,14 +97,14 @@ into the `amrex` namespace.  In this step, you can use
 `Tools/Migration/step-5-amrex-namespace/amrex-namespace.sh` to replace
 `BoxLib::` with `amrex::` for those already in `BoxLib` namespace.
 However, the rest of work is expected to be performed manually,
-because C++ is too a complicated language for shell scripting.  
+because C++ is too a complicated language for shell scripting.
 
 For most `.cpp` files, you can put a `using namespace amrex;` line
 after the last `include` line, or `using amrex::MultiFab` etc., or you
 can add `amrex::` to wherever needed.  Note that having both `using
 namespace amrex` and `using namespace std` in one file may cause
 conflicts because some names like `min` and `max` exist in both
-namespace. 
+namespace.
 
 For header files, it is considered bad practice to have `using
 namespace amrex` because it pollutes the namespace.  So you need to
@@ -113,7 +113,7 @@ manually add `amrex::` in front of AMReX names likes `MultiFab` and
 
 ### Step 6
 
-AMReX `migration/6-distributionmap` branch should be used in this step. 
+AMReX `migration/6-distributionmap` branch should be used in this step.
 
 In BoxLib, there is a `DistributionMapping` cache implemented with
 `std::map` with the number of `Box`es as the key.  Utilizing the

Docs/sphinx_documentation/source/AMReX_Profiling_Tools_Chapter.rst

@@ -11,13 +11,13 @@ varying levels of profiling detail.
 Here are links to short courses (slides) on how to use the profiling tools.
 More details can be found in the documentation below.
 
-Lecture 1: `Introduction and TINYPROFILER <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture1.pdf>`_ 
+Lecture 1: `Introduction and TINYPROFILER <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture1.pdf>`_
 
-Lecture 2: `Introduction to  Full Profiling <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture2.pdf>`_ 
+Lecture 2: `Introduction to  Full Profiling <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture2.pdf>`_
 
-Lecture 3: `Using ProfVis -- GUI Features <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture3.pdf>`_ 
+Lecture 3: `Using ProfVis -- GUI Features <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture3.pdf>`_
 
-Lecture 4: `Batch Options and Advanced Profiling Flags <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture4.pdf>`_ 
+Lecture 4: `Batch Options and Advanced Profiling Flags <http://ccse.lbl.gov/AMReX/AMReX_Profiling_Lecture4.pdf>`_
 
 .. toctree::
    :maxdepth: 1

Docs/sphinx_documentation/source/AmrCore.rst

@@ -25,9 +25,9 @@
 
 .. _fig:Adv:
 
-.. table:: Time sequence (:math:`t=0,0.5,1,1.5,2` s) of advection of a Gaussian profile using the SingleVortex tutorial. The analytic velocity field distorts the profile, and then restores the profile to the original configuration.  The red, green, and blue boxes indicate grids at AMR levels :math:`\ell=0,1`, and :math:`2`.  
+.. table:: Time sequence (:math:`t=0,0.5,1,1.5,2` s) of advection of a Gaussian profile using the SingleVortex tutorial. The analytic velocity field distorts the profile, and then restores the profile to the original configuration.  The red, green, and blue boxes indicate grids at AMR levels :math:`\ell=0,1`, and :math:`2`.
    :align: center
-   
+
    +-----+-----+-----+-----+-----+
    | |a| | |b| | |c| | |d| | |e| |
    +-----+-----+-----+-----+-----+
@@ -69,20 +69,20 @@ The protected data members are:
         int            finest_level;    // Current finest level.
 
         Vector<IntVect> n_error_buf;     // Buffer cells around each tagged cell.
-        Vector<IntVect> blocking_factor; // Blocking factor in grid generation 
+        Vector<IntVect> blocking_factor; // Blocking factor in grid generation
                                         // (by level).
         Vector<IntVect> max_grid_size;   // Maximum allowable grid size (by level).
         Real           grid_eff;        // Grid efficiency.
         int            n_proper;        // # cells required for proper nesting.
 
         bool use_fixed_coarse_grids;
         int  use_fixed_upto_level;
-        bool refine_grid_layout;        // chop up grids to have the number of 
+        bool refine_grid_layout;        // chop up grids to have the number of
                                         // grids no less the number of procs
 
         Vector<Geometry>            geom;
         Vector<DistributionMapping> dmap;
-        Vector<BoxArray>            grids;    
+        Vector<BoxArray>            grids;
 
 The following parameters are frequently set via the inputs file or the command line.
 Their usage is described in the section on :ref:`sec:grid_creation`
@@ -135,22 +135,22 @@ class :cpp:`AmrCoreAdv`.
 ::
 
     //! Tag cells for refinement.  TagBoxArray tags is built on level lev grids.
-    virtual void ErrorEst (int lev, TagBoxArray& tags, Real time, 
+    virtual void ErrorEst (int lev, TagBoxArray& tags, Real time,
                            int ngrow) override = 0;
 
     //! Make a new level from scratch using provided BoxArray and DistributionMapping.
     //! Only used during initialization.
-    virtual void MakeNewLevelFromScratch (int lev, Real time, const BoxArray& ba, 
+    virtual void MakeNewLevelFromScratch (int lev, Real time, const BoxArray& ba,
                                           const DistributionMapping& dm) override = 0;
 
-    //! Make a new level using provided BoxArray and DistributionMapping and fill 
+    //! Make a new level using provided BoxArray and DistributionMapping and fill
     //  with interpolated coarse level data.
-    virtual void MakeNewLevelFromCoarse (int lev, Real time, const BoxArray& ba, 
+    virtual void MakeNewLevelFromCoarse (int lev, Real time, const BoxArray& ba,
                                          const DistributionMapping& dm) = 0;
 
-    //! Remake an existing level using provided BoxArray and DistributionMapping 
+    //! Remake an existing level using provided BoxArray and DistributionMapping
     //  and fill with existing fine and coarse data.
-    virtual void RemakeLevel (int lev, Real time, const BoxArray& ba, 
+    virtual void RemakeLevel (int lev, Real time, const BoxArray& ba,
                               const DistributionMapping& dm) = 0;
 
     //! Delete level data
@@ -215,7 +215,7 @@ single-level routines :cpp:`MultiFab::FillBoundary` and :cpp:`FillDomainBoundary
 to fill interior, periodic, and physical boundary ghost cells.  In principle, you can
 write a single-level application that calls :cpp:`FillPatchSingleLevel()` instead
 of using :cpp:`MultiFab::FillBoundary` and :cpp:`FillDomainBoundary()`.
-   
+
 A :cpp:`FillPatchUtil` uses an :cpp:`Interpolator`. This is largely hidden from application codes.
 AMReX_Interpolater.cpp/H contains the virtual base class :cpp:`Interpolater`, which provides
 an interface for coarse-to-fine spatial interpolation operators. The fillpatch routines described
@@ -245,7 +245,7 @@ Using FluxRegisters
 -------------------
 
 AMReX_FluxRegister.cpp/H contains the class :cpp:`FluxRegister`, which is
-derived from the class :cpp:`BndryRegister` (in ``amrex/Src/Boundary/AMReX_BndryRegister``). 
+derived from the class :cpp:`BndryRegister` (in ``amrex/Src/Boundary/AMReX_BndryRegister``).
 In the most general terms, a FluxRegister is a special type of BndryRegister
 that stores and manipulates data (most often fluxes) at coarse-fine interfaces.
 A simple usage scenario comes from a conservative discretization of a hyperbolic
@@ -402,7 +402,7 @@ Code Structure
    Source code tree for the AmrAdvection_AmrCore example.
 
 
-The figure shows the :ref:`fig:AmrAdvection_AmrCore_flowchart` 
+The figure shows the :ref:`fig:AmrAdvection_AmrCore_flowchart`
 
 
 -  amrex/Src/
@@ -499,11 +499,11 @@ These fluxes are used to set or increment the flux registers.
     // the flux registers from the coarse or fine grid perspective
     // NOTE: the flux register associated with flux_reg[lev] is associated
     // with the lev/lev-1 interface (and has grid spacing associated with lev-1)
-    if (do_reflux) { 
+    if (do_reflux) {
        if (flux_reg[lev+1]) {
           for (int i = 0; i < BL_SPACEDIM; ++i) {
               flux_reg[lev+1]->CrseInit(fluxes[i],i,0,0,fluxes[i].nComp(), -1.0);
-          }     
+          }
        }
        if (flux_reg[lev]) {
           for (int i = 0; i < BL_SPACEDIM; ++i) {
@@ -558,7 +558,7 @@ advanced a multiple of :cpp:`regrid_int`, we call the :cpp:`regrid` function.
                     // regrid could add newly refine levels
                     // (if finest_level < max_level)
                     // so we save the previous finest level index
-            int old_finest = finest_level; 
+            int old_finest = finest_level;
             regrid(lev, time);
 
                     // if there are newly created levels, set the time step
@@ -618,19 +618,19 @@ interface to a Fortran routine that tags cells (in this case, :fortran:`state_er
     #endif
         {
             Vector<int>  itags;
-        
+
         for (MFIter mfi(state,true); mfi.isValid(); ++mfi)
         {
             const Box& tilebox  = mfi.tilebox();
 
                 TagBox&     tagfab  = tags[mfi];
-            
+
             // We cannot pass tagfab to Fortran because it is BaseFab<char>.
             // So we are going to get a temporary integer array.
                 // set itags initially to 'untagged' everywhere
                 // we define itags over the tilebox region
             tagfab.get_itags(itags, tilebox);
-            
+
                 // data pointer and index space
             int*        tptr    = itags.dataPtr();
             const int*  tlo     = tilebox.loVect();
@@ -639,8 +639,8 @@ interface to a Fortran routine that tags cells (in this case, :fortran:`state_er
                 // tag cells for refinement
             state_error(tptr,  ARLIM_3D(tlo), ARLIM_3D(thi),
                 BL_TO_FORTRAN_3D(state[mfi]),
-                &tagval, &clearval, 
-                ARLIM_3D(tilebox.loVect()), ARLIM_3D(tilebox.hiVect()), 
+                &tagval, &clearval,
+                ARLIM_3D(tilebox.loVect()), ARLIM_3D(tilebox.hiVect()),
                 ZFILL(dx), ZFILL(prob_lo), &time, &phierr[lev]);
             //
             // Now update the tags in the TagBox in the tilebox region
@@ -665,7 +665,7 @@ is simple:
                            dx,problo,time,phierr) bind(C, name="state_error")
 
       implicit none
-      
+
       integer          :: lo(3),hi(3)
       integer          :: state_lo(3),state_hi(3)
       integer          :: tag_lo(3),tag_hi(3)

Docs/sphinx_documentation/source/AmrLevel.rst

@@ -111,10 +111,10 @@ the :cpp:`AmrLevelAdv` class, e.g.,
         for (int i = 0; i < BL_SPACEDIM; ++i) {
         lo_bc[i] = hi_bc[i] = INT_DIR;   // periodic boundaries
         }
-        
+
         BCRec bc(lo_bc, hi_bc);
 
-        desc_lst.setComponent(Phi_Type, 0, "phi", bc, 
+        desc_lst.setComponent(Phi_Type, 0, "phi", bc,
                   StateDescriptor::BndryFunc(nullfill));
     }
 
@@ -168,7 +168,7 @@ The figure above shows the :ref:`fig:AmrAdvection_AmrLevel_flowchart`
     main()
       Amr amr;
       amr.init()
-      loop { 
+      loop {
         amr.coarseTimeStep()
           /* compute dt */
           timeStep()

Docs/sphinx_documentation/source/Basics.rst

@@ -365,7 +365,7 @@ Sharing the Command Line
 ------------------------
 
 In some cases we want AMReX to only read part of the command line -- this happens, for example, when we
-are going to use AMReX in cooperation with another code package and that code also takes command-line 
+are going to use AMReX in cooperation with another code package and that code also takes command-line
 arguments.
 
 .. highlight:: console
@@ -1518,7 +1518,7 @@ together. In this section, we will show how you can operate on the
           // Call function f1 to work on the region specified by box.
           // Note that the whole region of the Fab includes ghost
           // cells (if there are any), and is thus larger than or
-          // equal to "box". 
+          // equal to "box".
           f1(box, a);
       }
 
@@ -2214,7 +2214,7 @@ macro on loops that are not safe for vectorization may lead to errors,
 so if unsure about the independence of the iterations of a
 loop, test and verify before adding the macro.
 
-These loops should usually use :cpp:`i <= hi.x`, not :cpp:`i < hi.x`, when 
+These loops should usually use :cpp:`i <= hi.x`, not :cpp:`i < hi.x`, when
 defining the loop bounds. If not, the highest index cells will be left out
 of the calculation.
 
@@ -2611,7 +2611,7 @@ For example,
 ::
 
     mpiexec -n 4 valgrind --leak-check=yes --track-origins=yes --log-file=vallog.%p ./foo.exe ...
-    
+
 Breaking into Debuggers
 =======================
 

Docs/sphinx_documentation/source/DualGrid.rst

@@ -15,12 +15,12 @@ the mesh work and particle work have very different requirements for load balanc
 Rather than using a combined work estimate to create the same grids for mesh and particle
 data, we have the option to pursue a "dual grid" approach.
 
-With this approach the mesh (:cpp:`MultiFab`) and particle (:cpp:`ParticleContainer`) data 
+With this approach the mesh (:cpp:`MultiFab`) and particle (:cpp:`ParticleContainer`) data
 are allocated on different :cpp:`BoxArrays` with different :cpp:`DistributionMappings`.
 
 This enables separate load balancing strategies to be used for the mesh and particle work.
 
-The cost of this strategy, of course, is the need to copy mesh data onto temporary 
+The cost of this strategy, of course, is the need to copy mesh data onto temporary
 :cpp:`MultiFabs` defined on the particle :cpp:`BoxArrays` when mesh-particle communication
 is required.
 

Docs/sphinx_documentation/source/EB.rst

@@ -226,7 +226,7 @@ procedure for this goes as follows:
 
    Real operator() (const Array<Real,AMREX_SPACEDIM>& p) const;
 
-- Make a :cpp:`EB2::GeometryShop` object using the implicit function. 
+- Make a :cpp:`EB2::GeometryShop` object using the implicit function.
 
 - Build an :cpp:`EB2::IndexSpace` with the :cpp:`EB2::GeometryShop` object and a
   :cpp:`Geometry` object that contains the information about the domain and the
@@ -382,7 +382,7 @@ format of basic AMReX objects such as :cpp:`BaseFab`, :cpp:`FArrayBox`,
                         const Vector<int>& a_ngrow,
                         EBSupport a_support);
 
-or 
+or
 
 .. highlight: c++
 
@@ -405,11 +405,11 @@ needed.
 - :cpp:`EBSupport:full`: volume plus area fraction, boundary centroid
   and face centroid
 
-:cpp:`EBFArrayBoxFactory` is derived from :cpp:`FabFactory<FArrayBox>`.  
+:cpp:`EBFArrayBoxFactory` is derived from :cpp:`FabFactory<FArrayBox>`.
 :cpp:`MultiFab` constructors have an optional argument :cpp:`const
 FabFactory<FArrayBox>&`.  We can use :cpp:`EBFArrayBoxFactory` to
 build :cpp:`MultiFab`\ s that carry EB data.  Member function of
-:cpp:`FabArray` 
+:cpp:`FabArray`
 
 .. highlight: c++
 
@@ -503,7 +503,7 @@ it to determine if a box contains cut cells.
 
     auto const& flags = factory->getMultiEBCellFlagFab();
     MultiCutFab const& centroid = factory->getCentroid();
-    
+
     for (MFIter mfi ...) {
         const Box& bx = mfi.tilebox();
         FabType t = flags[mfi].getType(bx);
@@ -544,20 +544,20 @@ testing cell types and getting neighbor information. For example
                 else if (is_single_valued_cell(flags(i,j,k))) then
                     ! this is a cut cell
                 end if
-            end do     
-        end do     
-    end do     
+            end do
+        end do
+    end do
 
 
 Linear Solvers
 ==============
 
 Linear solvers for the canonical form (equation :eq:`eqn::abeclap`)
-have been discussed in chapter :ref:`Chap:LinearSolvers`.  
+have been discussed in chapter :ref:`Chap:LinearSolvers`.
 
-AMReX supports multi-level 
-1) cell-centered solvers with homogeneous Neumann, homogeneous Dirichlet, 
-or inhomogeneous Dirichlet boundary conditions on the EB faces, and 
+AMReX supports multi-level
+1) cell-centered solvers with homogeneous Neumann, homogeneous Dirichlet,
+or inhomogeneous Dirichlet boundary conditions on the EB faces, and
 2) nodal solvers with homogeneous Neumann boundary conditions on the EB faces.
 
 To use a cell-centered solver with EB, one builds a linear operator
@@ -601,9 +601,9 @@ where phi_on_eb is the MultiFab holding the Dirichlet values in every cut cell,
 and coeff again is a real number (i.e. the value is the same at every cell)
 or a MultiFab holding the coefficient of the gradient at each cell with an EB face.
 
-Currently there are options to define the face-based coefficients on 
+Currently there are options to define the face-based coefficients on
 face centers vs face centroids, and to interpret the solution variable
-as being defined on cell centers vs cell centroids.   
+as being defined on cell centers vs cell centroids.
 
 The default is for the solution variable to be defined at cell centers;
 to tell the solver to interpret the solution variable as living