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 https://github.com/ElmerCSC/elmerfem/blob/1f5be3a78a9773511929950d4d3782a02485977c/fem/src/modules/MagnetoDynamics/WhitneyAVHarmonicSolver.F90#L492

Then that is used to transform the conductivity tensor https://github.com/ElmerCSC/elmerfem/blob/1f5be3a78a9773511929950d4d3782a02485977c/fem/src/modules/MagnetoDynamics/WhitneyAVHarmonicSolver.F90#L1439

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: https://github.com/ElmerCSC/elmerfem/blob/1f5be3a78a9773511929950d4d3782a02485977c/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif#L25 Beta https://github.com/ElmerCSC/elmerfem/blob/1f5be3a78a9773511929950d4d3782a02485977c/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif#L37 RotM https://github.com/ElmerCSC/elmerfem/blob/1f5be3a78a9773511929950d4d3782a02485977c/fem/tests/circuits_harmonic_stranded_homogenization/sif/2241.sif#L50

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.