Minor

joss_paper/demo.jl

@@ -74,7 +74,7 @@ with_mpi() do distribute
   blocks = [LinearSystemBlock() LinearSystemBlock();
             LinearSystemBlock() BiformBlock((p,q) -> ∫(p*q)dΩ,Q,Q)]
   P = BlockTriangularSolver(blocks,[solver_u,solver_p])
-  solver = FGMRESSolver(10;Pr=P,rtol=1.e-8,verbose=i_am_main(parts))
+  solver = GMRESSolver(10;Pr=P,rtol=1.e-8,verbose=i_am_main(parts))
   ns = numerical_setup(symbolic_setup(solver,A),A)
 
   x = allocate_in_domain(A); fill!(x,0.0)

joss_paper/paper.bib

@@ -78,7 +78,6 @@ @article{Bezanson2017
 volume = {59},
 year = {2017}
 }
-
 @article{Badia2020,
 abstract = {Gridap is a new Finite Element (FE) framework, exclusively written in the Julia programming language, for the numerical simulation of a wide range of mathematical models governed by partial differential equations (PDEs). The library provides a feature-rich set of discretization techniques, including continuous and discontinuous FE methods with Lagrangian, Raviart-Thomas, or N{\'{e}}d{\'{e}}lec interpolations, and supports a wide range of problem types including linear, nonlinear, single-field, and multi-field PDEs (see (Badia, Mart{\'{i}}n, {\&} Principe, 2018, Section 3) for a detailed presentation of the mathematical abstractions behind the implementation of these FE methods). Gridap is designed to help application experts to easily simulate real-world problems, to help researchers improve productivity when developing new FE-related techniques, and also for its usage in numerical PDE courses. The main motivation behind Gridap is to find an improved balance between computational performance, user-experience, and work-flow productivity when working with FE libraries. Previous FE frameworks, e.g., FEniCS (Alnaes et al., 2015) or Deal.II (Bangerth, Hartmann, {\&} Kanschat, 2007) usually provides a high-level user front-end to facilitate the use of the library and a computational back-end to achieve performance. The user front-end is usually programmable in an interpreted language like Python, whereas the computational back-end is usually coded in a compiled language like C/C++ or Fortran. Users can benefit from the high-level front-end (i.e., for rapid prototyping) and simultaneously enjoy the performance of the compiled back-end. This approach reaches a compromise between performance and productivity when the back-end provides all the functionality required by the user. However, it does not satisfactorily address the needs of researchers on numerical methods willing to extend the library with new techniques or features. These extensions usually need to be done at the level of the computational back-end for performance reasons.},
 author = {Badia, Santiago and Verdugo, Francesc},
@@ -95,7 +94,6 @@ @article{Badia2020
 volume = {5},
 year = {2020}
 }
-
 @article{Badia2020a,
 abstract = {In this work we formally derive and prove the correctness of the algorithms and data structures in a parallel, distributed-memory, generic finite element framework that supports {\$}h{\$}-adaptivity on c...},
 archivePrefix = {arXiv},
@@ -207,4 +205,4 @@ @book{fenics-book
   publisher = {Springer Berlin Heidelberg},
   editor = {Anders Logg and Kent-Andre Mardal and Garth Wells},
   title = {Automated Solution of Differential Equations by the Finite Element Method}
-}
+}

joss_paper/paper.md

@@ -57,7 +57,7 @@ GridapSolvers complements GridapPETSc with a modular and extensible interface fo
 - A modular implementation of geometric multigrid (GMG) solvers, allowing different types of smoothers and restriction/prolongation operators.
 - A generic interface for patch-based subdomain decomposition methods, and an implementation of patch-based smoothers for geometric multigrid solvers.
 
-![GridapSolvers and its relation to other packages in the Julia package ecosystem. In this diagram, each node represents  a Julia package, while the (directed) arrows represent relations (dependencies) among packages. Dashed arrows mean the package can be used, but is not necessary. \label{fig:packages}](packages.png){ width=60% }
+![GridapSolvers and its relation to other packages in the Julia package ecosystem. In this diagram, each node represents  a Julia package, while the (directed) arrows represent relations (dependencies) among packages. Dashed arrows mean the package can be used, but is not required. \label{fig:packages}](packages.png){ width=60% }
 
 # Demo
 

joss_paper/scalability/postprocess.jl

@@ -28,7 +28,7 @@ begin
 			n_dofs_u = df.ndofs_u[1],
 			n_dofs_p = df.ndofs_p[1],
 			n_dofs   = df.ndofs_u[1] + df.ndofs_p[1],
-			n_cells  = df.nc[1]
+			n_cells  = df.ncells[1]
 		)
 	end
 	sort!(df,:np)
@@ -37,7 +37,6 @@ end
 # ╔═╡ a10880e9-680b-46f0-9bda-44e53a7196ce
 begin
 	plt = plot(xlabel="N processors",ylabel="walltime (s)",legend=false)
-	plot!(df[!,:np],df[!,:t_solver][1]*df[!,:np]./df[!,:np][1]) # Perfect scaling
 	plot!(df[!,:np],df[!,:t_solver])
 end