Conversation
|
|
||
| # Multidimensional BC operators | ||
| _concretize(Q::MultiDimDirectionalBC, M) = _concretize(Q.BCs, M) | ||
| # _concretize(Q::MultiDimDirectionalBC, M) = _concretize(Q.BCs, M) |
There was a problem hiding this comment.
what's the reason for commenting instead of removing?
There was a problem hiding this comment.
Earlier it was an Affine operator with concretizations. Now it isn't and hence won't support this but rather than removing I thought about commenting out keeping in mind that if by any means one can come up with a way to still concretize this later.
Now when I think of it, I don't know why this should necessarily be manipulated and concretized ┐(•_•)┌
|
|
||
| """ | ||
| slice_rmul lets you multiply each vector like strip of an array `u` with a linear operator `A`, sliced along dimension `dim` | ||
| """ |
There was a problem hiding this comment.
no space or this won't be a docstring.
|
|
||
| struct MultiDimBC{N} end | ||
|
|
||
| MultiDimBC{dim}(N::Int, approx_order::Int, dx::T) where {dim,T} = finite_stencil(approx_order,dx,dim,N) |
There was a problem hiding this comment.
Overall Dimension of the space in which its operating. I think the declaration in the struct MultiDimBC{N} is misleading.
Will replace there with dim.
| paraboloid(x::T, y::T) where T = 2*(x^2+y^2) - 4 # declare an elliptic paraboloid function | ||
| u0 = [paraboloid(X, Y) for X in x, Y in y] | ||
|
|
||
| q1 = MultiDimBC{1}(2,6,dx) # Padding along x |
There was a problem hiding this comment.
I don't think this can account for affine terms or Dirichlet non-zero?
There was a problem hiding this comment.
Yeah, this isn't an affine operator per se.
2 participants
Here, the last implementation has been edited to produce the expected results.
There was a goof-up in previous structure since it presumed that all data columns along a dimension would have same boundary conditions. I have rather used extrapolation using FD approximation to estimate the right BVs.
Moreover, a multi-dimensional boundary padding in true-sense would require updation of 'unpadded' part of our
Arrayafter each operation along a dimension. Hence, handling it that way has been administered.There are still few bottlenecks that need to be thought about and resolved if feasible -
Arrayrather thanCompositeBoundaryPaddedArraybecause segregating what's padded and what's not becomes cumbersome as the BVs after first operation are interior points for the next one.I have commented out the previous code, since it would be required to figure out the 'expectations' from this.