Put together ACA components to solve full problem

[jackhamel16]

Put everything together so that ACA is used to compute Z for well separated elements and Z is computed normally for close elements. Use an iterative solver to find the unknowns, J.

1) set up mesh and octree structs 2) for each test node for each src node if nodes farther than some tolerance, use ACA to compute decomposed sub-Z, U and V else nodes are too close, use direct calculations of sub-Z 3) call iterative solver on function that computes Z*J implicitly

Number 2 should be wrapped in a routine that does an effective matrix vector product between Z and and given J.

Question: Should I be storing all these sub-Z matrices (compressed and uncompressed) so that I am not recomputing them with each iteration of the iterative solve? Probably...

Maybe store with each node an array of the sub-Z matrix for that node's interaction with every other node. For uncompressed, it will be a single Z matrix, for compressed it will be an array of two arrays–one U and one V. Now I can write a function to compute ZJ utilizing multiple dispatch. If the provided Z is one matrix, then it will do ZJ, if the provided Z is an array of two matrices, it will compute U(VJ)

Split this up into multiple tasks:

First look into iterative solvers 1: add ability to store Z and U,V for each node interaction 2: add routine to compute matvec using U and V or Z 3: wrap matvec routine so that given a vector J, it loops through each node pair and computes the corresponding contributions to V and adds them up to produce the entire V vector.

Lastly, follow original steps 1-3 where step three uses the new matvec function

[jackhamel16]

Regarding what the approximation tolerance means, I interpret it as giving a limit to how small the estimated error of between the actual sub-Z matrix and the approximated one is when the algorithm stops. So, it doe not have anything directly to do with singular values. this also means that given a problem where two nodes are close, then U and V will be higher rank than if the nodes are far apart for the same approximation tolerance. Based on this, I don't think any adaptive changes to the approximation tolerance will be required based on how far apart the nodes are. In other words, far apart nodes aren't using approximate Z matrices with too small of an error compared to near node interactions thus wasting resources because the added accuracy in far apart nodes is masked by the high error in near node interactions won't be a problem here.

[jackhamel16]

forlearning about iterative solvers

https://github.com/JuliaLinearAlgebra/IterativeSolvers.jl/blob/master/docs/src/getting_started.md

[jackhamel16]

resume work by figuring out how to use matrix-free iterative solvers and choosing one. How this is done might need to inform all other work on this issue going forward.

[jackhamel16]

Iterative solvers requires a rhs vector and a linear map type object that affects a matrix vector product. The linear map type can be constructed from a function like in the example below

`using LinearAlgebra using IterativeSolvers using LinearMaps

function identityOperator(x::AbstractVector) vec_size = length(x) identity_matrix = I(vec_size) return(identity_matrix * x) end

map1 = LinearMap(identityOperator, 3)

matrix = [1 54 5; 0 0 -10; 3 18 -30]

function operator(x::AbstractVector) matrix = [1 54 5; 0 0 -10; 3 18 -30] return(matrix * x) end

map2 = LinearMap(operator, 3)

x = randn(3) rhs = matrix * x

test_sol = gmres(map2, rhs)

println("Results = ", isapprox(test_sol, x, rtol=1e-10))`

[jackhamel16]

Left off on octree function fillOctreeZMatricesSoundSoft!, specifically, on determining when to use ACA and when to not. Also need to set up inputs for computeMatrixACA and call the function. Add else statement that directly computes the sub Z matrix when nodes are too close.