Closed BruceWyxv closed 6 years ago
@BruceWyxv I have a question about your normalizations. Based off the definition of orthonormality I'm familiar with (here and here), I would think that this line should be 1 / std::sqrt(M_PI)
as opposed to just 1 / M_PI
. This concern applies to the other terms as well. I could very well be missing something though.
@lindsayad You are correct, I have taken a little liberty with the term 'orthonormal'. But there is more to the story...
In essence, the square of the orthonormality value needs applied somewhere throughout the process. Some approaches apply it as a post-processing step, others only when expanding out the coefficients. Yet others simply implement a single function using the actual value, that is used for both coefficient generation and expansion, for the total effect of applying the square of the constant. This last approach I found typically in EE applications, referenced usually as the "RMS form" (or similar) if my memory serves me right.
I elected to adopt an approach that applies the square of the orthonormality value when generating the coefficients. This results in coefficients that correspond directly to the scaled level of the standard series. For example, by generating the Zernike coefficients using the square of the orthonormality value (as you noticed), the coefficient for the zeroth order term is the value of the zeroth order term, or the piston. For me, at least, it makes manually interpreting the coefficient values a lot easier.
Further, this opens up direct usage of the standard function series form for uses beyond functional expansions. That was one of the reasons this module was designed with the Function
-derived FunctionSeries
class: so that others could use the standard function series forms as needed for their own purposes.
In his work, Dr. Griesheimer himself referred to the this value as the orthonormalization constant. I am open for suggestions if there is a more sound mathematical terminology for this approach.
No, I'm fine with this; I just wanted to understand what was going on 😃 Might be worth writing this up somewhere in the documentation. If you're busy, I can get around to it at some point
That's actually a very good suggestion. It is alluded to via some of the references, but not directly stated in the documentation.
It might be a little while, so feel free to jump in if I'm taking too long to get around to it. :roll_eyes:
Rationale
One primary challenge in multiphysics coupling is deriving a common data-exchange interface. Ideally, both externally-coupled codes and internally-coupled physics components will share a common/universal interface for transferring field solutions.
Description
Functional expansions provide a unique approach to multiphysics coupling. Among the key features is the ability to transcend model geometries/constructions to represent data that can be easily understood in a separate context. Another is the ability to represent field solution information with a comparatively small amount of data.
It is proposed to implement this functionality as a new module named "functional_expansion_tools". The merits of including this as a module will be evaluated per the moose-users thread New MOOSE Module Instructions
Impact
The addition of functional expansions to MOOSE will provide a flexible coupling mechanism that already supports the MultiApp system to streamline various forms of coupling. Users will be able to immediately leverage this approach. Future updates are planned to provide an API for MOOSE-wrapped applications. No negative impact to the current framework is anticipated.