CellIpData B-Matrix memoization

[pmueller2]

Problem:
Using different differential operators with given cellIpData is not possible because the second will not be evaluated but returns the memoized copy of the first.

Possible solution:
Remove the memoization at this point. This is done in removeMemoAtCellIPData.

Maybe this is also the right time to introduce memoization at the interpolations with the NaturalCoordinateMemoizerMap?

[Psirus]

I agree on removing this DofType-wise memoization there.

I'm not sure how to implement the reference coordinate memoization. One option would be to stick two NaturalCoordinateMemoizers into the InterpolationSimple base class, and memoize calls to GetB and GetN. However, this would mean that the base class has data and is no longer a pure interface - I don't like it.

Another option would be to add another class, that saves a reference to an InterpolationSimple, two memoizers and forwards the respective calls, but this would mean saving MemoziedInterpolation at the element, and seems too intrusive as well. Any ideas?

[TTitscher]

So you want to solve a PDE where some terms use a different spatial derivative? At the first glance, this sounds odd. Maybe you could describe the problem in more detail. Other solutions that keep the memoization: - memoization is dof wise: introduce a separate dof type for the other nabla operator - memoization is cell wise: introduce an additional integrand for the other nabla Christoph Pohl <notifications@github.com> schrieb am Mi., 16. Mai 2018, 09:52:

…

I agree on removing this DofType-wise memoization there. I'm not sure how to implement the reference coordinate memoization. One option would be to stick two NaturalCoordinateMemoizers into the InterpolationSimple base class, and memoize calls to GetB and GetN. However, this would mean that the base class has data and is no longer a pure interface - I don't like it. Another option would be to add another class, that saves a reference to an InterpolationSimple, two memoizers and forwards the respective calls, but this would mean saving MemoziedInterpolation at the element, and seems too intrusive as well. Any ideas? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#258 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMH78WfbU38jh7jcRWcLfUn1kdrbVzfXks5tzEs1gaJpZM4UAJvU> .

[pmueller2]

The reason why this problem showed up was the implementation of an example of the scaled boundary element method. There the differential operator/B-Matrix is splitted into a sum B1+B2 where the first operates on one coordinate that is handled differently than the other.

While for this specific case there are also other solutions I do not know why this restriction to only one differential operator is necessary - performance? I doubt it.

The whole idea of this differential operator class was imho to make adding other types of nablas easier.
The 2nd order electromagnetic wave equations for anisotropic media or for inhomogeneous media contain rotation and vector gradient for one single dof (e.g. E-field) in one equation (although I do not know if they are also present in the weak form - but thats not the point here).