Local coordinate system based on W vector and global Y axis

[ettaka]

Sometimes local coordinate system is needed in coil formulations.
Currently we can define that by using the thickness direction and height direction in rectangular coils.
If those are not available (ambiguous thickness or height), one option could be to use W Vector direction and a user defined vector.

Let's try to implement that alternative option in this issue.

FYI @jvencels

[raback]

Would it make sense to have this as Elemental subroutine to hide some complexity. So there would be some additional structure that would be initialized and then rotation would be done automatically.

The annoying thing is that rotation may be given in many ways. If it is a full tensor you need 2 vectors, if there is some symmetry 1 vector is enough, and often one rotation angle is enough. So how to add the different possibilities in a generic way? Ideally one would not need to change anything for the elemental routines. Or maybe there could be just one additional command in style.

TYPE(Rotate_t) :: Rotate
IF(Init) CALL ListInitRotation(Model, Rotate)

MagnetizationAtIp = ListGetElementReal3D(Mag_h,Basis,Element,...)
CALL ListGetElementRotate(Rotate,MagnetizationAtIp)

Maybe the way the rotation is defined could be solver-specific. Maybe listing the types of use cases would be good way to start....

I know that the elemental stuff is not much used around AV solver but the old ListGetReal results to guite a bit of extra code for features like this. There are already routines hiding grad, div etc.

FUNCTION ListGetElementRealParent
FUNCTION ListGetElementReal
FUNCTION ListGetElementIm
FUNCTION ListGetElementComplex
FUNCTION ListGetElementReal3D
FUNCTION ListGetElementRealGrad
FUNCTION ListGetElementRealDiv
FUNCTION ListGetElementComplex3D
FUNCTION ListGetElementRealVec

[ettaka]

@raback
Excellent idea! The way we do it now on WhitneyAV side is that we call to get the transformation matrix RotM

elmerfem/fem/src/modules/MagnetoDynamics/WhitneyAVHarmonicSolver.F90

Line 492 in 1f5be3a

CALL GetElementRotM(Element, RotM, n)

Then that is used to transform the conductivity tensor

elmerfem/fem/src/modules/MagnetoDynamics/WhitneyAVHarmonicSolver.F90

Line 1439 in 1f5be3a

C = MATMUL(MATMUL(RotMLoc, C),TRANSPOSE(RotMLoc))

But you are right. We should have what you propose so that any tensor could be transformed before it even gets to the solver routine. However, I feel that is a slightly different issue. In the current issue we just need to redefine the way we compute the local coordinate system:
Alpha:

elmerfem/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif

Line 25 in 1f5be3a

Solver 1

Beta

elmerfem/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif

Line 37 in 1f5be3a

Solver 2

RotM

elmerfem/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif

Line 50 in 1f5be3a

Exec Solver = Before All

So now we do $$\gamma = \alpha \times \beta$$ but if we assume that $\alpha$ and $\beta$ are ambiguous, we could do $$w=\gamma$$ and $\beta$ (coil axis) is set by the user.

Back to your point. I think we should definitely create an issue for your idea, for the future. I think we should refactor the RotM functionality out of AV solver following your concept and use it as a library feature. Then it could be used in any solver. We can then define the RotM transformation matrix as we do in the coil example, or it can be defined some other way.