ElementComposite()

[JarosT55]

Hi,
I would like to use (or experiment in the context of a project similar to ex24) with an element which is composed of ElementTriP2 and ElementTriMorley ... something like:
eC = ElementComposite(ElementTriP2(), ElementTriMorley())
or in its vector form
_eCV = ElementVector(ElementComposite(ElementTriP2(), ElementTriMorle_y()),2)

The current setup with:
e = ElementVector(ElementTriP2())
works quite well, but having 'u_n' dof type would give me more flexibility and potentially? the better numerical flow.

However, there are some issues I don't know how to address.
Dofs types of an ElementComposite(...) are a all-inclusive set of the respective elements' dofs.
They are:
for eC: ['u^1', 'u^2', 'u^1', 'u_n^2']
for eCV: ['u^1^1', 'u^1^2', 'u^2^1', 'u^2^2', 'u^1^1', 'u^1^2', 'u_n^2^1', 'u_n^2^2']
and because the 'all-inclusive' composition of elements resulting in dofs sets contain redundancies, like u^1 ≡ u^2
The question.
Is there a way to avoid such redundancies and, e.g. create eC in the form:
eC: ['u^1', 'u^1', 'u_n^2']

Regards
MichaelT

[kinnala]

That would require programming your own Element class. However, it is not clear to me what kind of finite element (see mathematical definition of a finite element) is this expected to correspond to. Normally you cannot simply drop out DOFs from an element and expect the result to make sense.

[kinnala]

There are no "redundacies" as you call them. ElementComposite is used to approximate multiple solutions at once.

[JarosT55]

Hi Mr Kinnala,

###Normally you cannot simply drop out DOFs from an element and expect the result to make sense.###

Yes, I am aware of this fact. My question was directed towards “automatic or semiautomatic” generating a new Composite Finite Element Space, removing potential redundancies of arguments of the respective fields of composed elements, in short, a new ElementClass(). In many cases, it could not make sense, but I suppose adding  ‘u_n’  to ElementTriPX(), would. I have looked at ElementTriPX() classes and others offering ‘u_n’. They seem to be constructed differently.
How difficult would such modification be???
Is it feasible? Would it be reinventing the wheel?
I have no clue … so I have asked the question.  

Thank you, Mr Kinnala, for the prompt answer.
 
Regards
MichaelT  

PS. I had a short glimpse into Symfem (a symbolic finite element definition library) but did not venture there ... yet :).

[kinnala]

I suggest you try to explain what your goal is with 'u' and 'u_n' and then we can think of different solutions. I presume sometimes you want to set 'u' and sometimes 'u_n'? It can be done without special finite element.

[JarosT55]

Hi, Mr Kinnala,

At this stage, I just want to experiment and better understand the software environment. It was a 'black magic' weeks ago, now it is a 'very dark grey'
What is the idea about 'n_u'?
I want to check/experiment with how the numerical process responds to setting DOF from 'u' (which works fine) to 'u_n'. It would be easier (more elegant) to define 'u_n' DOF in one element than in the composite one. Obviously, it is also an opportunity to learn the software!!!

I am attaching a sample project's PNG and MP4 (with low-resolution mesh). The goal is to make a transition on the right side of the pink line as 'smooth' as possible, minimizing artefacts (they are smaller for hi-res meshes). It is not really critical; just say ... the esthetic exercise is progressing on the software learning curve. I have tried higher-order TriPX(), and the results are positive.

Regards
MichaelT

https://github.com/kinnala/scikit-fem/assets/23690439/f06146cb-134e-4e49-973e-4251dd87821f

[JarosT55]

Hi, Mr Kinnala,

I have rethought the issue of adding 'u_n' to ElementTriPX's, and I hope I come to some conclusion on the question I asked, … but by any means, welcome any correction of my line of thought.

### How difficult would such modification be???
### Is it feasible?
### Would it be reinventing the wheel?

The addition of 'u_n' to ElementTriPX where X>1 creates a mathematical dilemma of solving polynomial equations of order two or more. Even the quadratic equations possess some challenges with two possible solutions. Hence, we have TriMorley ≡ TriP1+u_n, while TriMorleyX (for X>1) are unavailable.
Constatating the questions …

### How difficult would such modification be??? … difficult if not … impossible
### Is it feasible? … very unlikely
### Would it be reinventing the wheel? … no, the wheel in the dimension X>1 does not exist … yet ;).

… I will put this puzzle to rest :).

Regards
MichaelT