search

MaxwellUBC / MaxwellFrequency

Frequency domain quasi-static electromagnetic simulation and sensitivities
Other
0 stars 0 forks source link

Anisotropy #1

Open cschwarzbach opened 8 years ago

cschwarzbach commented 8 years ago

Is it safe to modify getData.jl on lines 19–20

-       Msig = getEdgeMassMatrix(param.Mesh,vec(sigma))
-       Mmu  = getFaceMassMatrix(param.Mesh,fill(1/mu,length(sigma)))
+       Msig = getEdgeMassMatrix(param.Mesh,sigma)
+       Mmu  = getFaceMassMatrix(param.Mesh,fill(1/mu,size(sigma,1)))

to support anisotropic conductivity? The OcTree library accepts for sigma a vector (isotropic) or a 2D-array with 6 columns (anisotropic).

Pbellive commented 8 years ago

Hi Christoph, The short answer to your question is yes, it should be fine to modify those lines to allow for anisotropic conductivity. Here's a longer answer that points to a couple more modifications that it would be nice to include along with your proposed change:

There are two potential problems with removing the vec(sigma) from both lines. The first, which you could argue isn't that big a deal, is that if an isotropic physical property is provided in an nX1 2d array rather than a vector of length n, then JOcTree will dispatch the call to the anisotropic getMassMatrix routine, causing the code to crash. This might not be an issue in Julia 0.5 as they've improved the handling of singleton array dimensions.

The second, more substantial issue is that, ideally we want the getData functions to be mesh independent and right now, the tensor mesh mass matrix methods in jInv don't support anisotropy. The ideal solution would be to add support for anisotropy to jInv. A simpler fix would be to add some error handling so attempting to pass anisotropic conductivity to a tensor mesh would result in an informative error message.