[OptApp] Filtering

[sunethwarna]

Hi All,

It would be better to unify the filters which are present in the OptApp. Currently, it is harder to integrate new filters to existing controls, because they are basically hard coded. Therefore I propose the Filter base class and Filter::Factory in #12157.

Followings are the filtering concerns:

1. IF we are to use implicit and explicit and all types of filtering within any control, then we need to agree on the type of updating. Currently, we have updates x and \delta x. As far as I see, best would be to filters to work on \delta x, and not on x

Following are damping concerns:

1. Should the damping be applied after the filtering?
2. Should the damping coefficients be provided to the filtering so that, those can be applied when the filtering is done automatically? (If this is the case, then we need to put this to the Filter interface class
   This is problematic because, as far as I know, the explicit filtering applies damping as a coefficent, but implicit filtering
   fixes with Dirichlet BCs the damped domains and solves the PDE for filtering.
3. Damping will be within the filter (Then each filter can do damping as they wish).
   As far as I see, implicit and explicit filters applies damping differently, hence it should be done in the filter settings, not in the control. Because, control only knows where to damp, not how to damp. If we are to put damping in the control, then we need to have an iterface in the Filter base class to have this information passed to filter. (which is double work and making filters strongly tied to controls, which is going against the modularity)

I am more aligned towards the third which is most modular and most future proof way. But open to suggestions.

@RezaNajian @Igarizza

[RezaNajian]

Hi all,

About the filtering concern, filter should not know anything about the field it is applying for, every control should handle the fields on its own. As we already see, for example thickness control works with absolute values of the control and shape uses deltas and so on.
So filter only gets fields and applies filtering in a black-box manner.

About damping concerns, following are my comments and thoughts:
@sunethwarna I have reconsidered things and we can move damping to filter for the sake of consistency and modularity since as you explain Helmholtz implements the BCs or damping model parts.

[sunethwarna]

Hi All,

I want to clarify something with all of you. Let me know if something is wrong in the following formulations where $s_i$ is the $i^{th}$ physical space variable and $\tilde{s}_i$ is corresponding $i^{th}$ control space variable :

So the physical variable is obtained by filtering the control space as in the following where $D_{ik}$ is the diagonal damping matrix and $A_{kj}$ is the smoothing matrix (This step is referred to as Filter::FilterField(x) within the Filter class):

$$\Delta s_i = D_{ik}A_{kj} \Delta \tilde{s}_j$$

From above one can derrive the follwoing:

$$\frac{ds_i}{d\tilde s_j} = D_{ik}A_{kj} = G_{ij} = \mathbf{D}\mathbf{A} = \mathbf{G}$$

Assuming the objective function is $J(s_i)$. Then algorithm requires $J$ derivative w.r.t. control space (i.e. $\tilde{s}_i$) which is $\frac{dJ}{d\tilde{s}_i}$ given by following equation:

$$\frac{dJ}{d\tilde{s}_i} = \frac{dJ}{ds_k} \frac{ds_k}{d\tilde{s}_i} = G_{ki}\frac{dJ}{ds_k} = \frac{dJ}{d\tilde{\underline{s}}} = \mathbf{G}^T \frac{dJ}{d\underline{s}} = \mathbf{A}^T \mathbf{D} \frac{dJ}{d\underline{s}}$$

Followings are my concerns:

1. As far as I see, last step (i.e. computation of $\frac{dJ}{d\tilde{s}_i}$) should be called something different, since it maps the gradients from physical space to control space (not the exact inverse of the filter). What should we call it, may be Filter::UnfilterGradientField?
2. At the moment we support Filter::FilterField and Filter::FilterIntegratedField in the Filter class. Can we stick to Filter::FilterField and get rid of the Filter::IntegratedField? The reasoning is, control cannot know before hand whether a Response is giving an integrated field or not, hence it cannot decide. So we can make all responses to return non-integrated gradient fields. This simplifies the Filter interface, and remove confusions.
3. Finally, can we have this filtering method names to reflect the space (i.e. physical space and control space)? It would make lot clearer for others.

Following is the reference I followed (https://www.sciencedirect.com/science/article/pii/S0045782513002673)

@RezaNajian : Are the above equations valid for implicit as well?

Please let me know your thoughts on this.
@Igarizza @RezaNajian @DSchmoelz @bdevresse

[RezaNajian]

the third equation is valid and it is the transposed operation NOT inverse (when the matrices are inversed) so it should not be called UnfilterGradientField. The majority of response functions are surface/volume integrated values and we need to distinguish between integrated and not integrated functions otherwise the solution is mesh-dependent, I suggest you to check Section 4.1 of this reference as well: https://link.springer.com/article/10.1007/s00158-023-03548-2.
So, we need to have both methods to cover all scenarious and avoid mesh-dependency.

From my point of view the namings are clear but I am open to other meaninghfull options.

[sunethwarna]

So, as agreed with @RezaNajian ,

1. Filter::ForwardFilterField will map conrtol field to physical field.
2. Filter::BackwardFilterField will map physical space mesh-independent sensitivities to control space sensitiivties.
3. Filter::BackwardFilterIntegratedField will map physical mesh-dependent sensitivities to control space sensitivities.

So the Filter::FilterField, Filter::FilterIntegratedField will be removed. All the Responses are suppose to give mesh-independent sensitivities, hence Control will only call Filter::BackwardFilterField to get the control space sensitivities.

If anyone has some other concerns/suggeston, please let me know. Otherwise, I will go ahead with this to change the interfaces.
#12166

[DSchmoelz]

I've got a question: The mesh independent filtering method developed by @armingeiser expects integrated physical space mesh-dependent sensitivities for the backward filtering (see ShapeOpt/mesh-independent-vm). So in this case Control doesn't call Filter::BackwardFilterField. How would you account for that in the planned code restructuring?

[sunethwarna]

Hmm... In that case, can we make the Filter::BackwardFilterIntegratedField the default. It is the default for the existing reponses anyways?

[sunethwarna]

It is now by default using the Filter::BackwardFilterIntegratedField in #12168 :)

[sunethwarna]

Hi All,

I am becoming a fan in creating dicussions it seems 😆 . I have another issue to discuss. For that, I will bring up the mathematics related to filtering to best of my knowledge (thanks @Igarizza for the short course).

Assume $\underline{s}$ is the physical space design variable, $\underline{p}$ is the control space design variable. (Little bit different from the original post, but i thought using tilda may be hard to read).

When we update in the $k^{th}$ optimization iteration:

$$\underline{s}_k = \underline{s}_0 + \sum_{i=1}^{k} \underline{\Delta s}_i = \underline{s}_0 + \sum_{i=1}^{k} \mathbf{G}_i\underline{\Delta p}_i$$

where,

$$\begin{split} \underline{\Delta s}_i &= \underline{s}_i - \underline{s}_{i-1} \\\ \underline{\Delta p}_i &= \underline{p}_i - \underline{p}_{i-1} \end{split}$$ $$\underline{p}_k = \underline{p}_0 + \sum_{i=1}^k \underline{\Delta p}_i$$

In the above equation $\mathbf{G}_i$ is the filtering matrix with damping

Case 1
If we only use thickness (or SIMP) control in our optimization problem, then $\mathbf{G}_i = \mathbf{G}$ is a constant matrix, hence we can re-write the equation.

$$\begin{split} \underline{s}_k &= \underline{s}_0 + \sum_{i=1}^{k} \underline{\Delta s}_i \\\ &= \underline{s}_0 + \mathbf{G}\sum_{i=1}^{k}\underline{\Delta p}_i \\\ &= \mathbf{G}\left(\underline{p}_0 + \sum_{i=1}^{k}\underline{\Delta p}_i \right) \\\ &= \mathbf{G}\underline{p}_k \\\ \end{split}$$

So, one can use either the $\underline{\Delta p}$ or $\underline{p}$ with filtering without causing troubles or difficulties.

Case 2
Now lets assume thickness control (and/or SIMP) is used along with the shape control in the same optimization problem. Then $\mathbf{G}_i$ may be different for both thickness (or SIMP) and shape control in each optimization iteration if $\mathbf{G}_i$ is updated in each iteration. Lets assume we want to update our $\mathbf{G}_i$ when shape is changed. Now working with absolute values (i.e. $\underline{p}$) becomes difficult as shown below:

$$\begin{split} \underline{s}_k &= \underline{s}_0 + \sum_{i=1}^{k} \underline{\Delta s}_i \\\ &= \underline{s}_0 + \sum_{i=1}^{k} \mathbf{G}_i\underline{\Delta p}_i \\\ &= \underline{s}_0 + \sum_{i=1}^{k} \mathbf{G}_i\left(\underline{p}_i - \underline{p}_{i-1}\right) \\\ &= \mathbf{G}_0 \underline{p}_0 + \sum_{i=1}^{k} \mathbf{G}_i\left(\underline{p}_i - \underline{p}_{i-1}\right) \\\ &= \mathbf{G}_k \underline{p}_k + \sum_{i=1}^{k-1} \mathbf{G}_i\left(\underline{p}_i - \underline{p}_{i-1}\right) + \mathbf{G}_0 \underline{p}_0 - \mathbf{G}_k \underline{p}_{k-1} \end{split}$$

Therefore, I see lots of advantages using $\underline{\Delta p}$ for filtering and listed below:

1. It is simple to understand and implement if any control is used along with the shape control
2. Applying filtering boundary conditions simpler (only requires homogeneous BCs)
3. Filtering boundaries can have any arbitrary value (then user does not have to duplicate values in properties and filter BCs for material controls. The primal solution is seperated from the optimization problem json settings. No repitition of the primal problem settings/properties in the json settings of the optimization problem. Less prone for errors from users side).
4. This is possible with any combination of controls, or standalone controls used in any optimization problem, whereas, the absolute values needs special care depending on a control is used along with shape or not.
5. In VM/explicit, we work with $\Delta p$, hence the control interfaces can be generelized across all current filters/ desigh variables.

In the contrary to most of the literature, I would say we go with the $\underline{\Delta p}$ for filtering because, we are not talking about simple thickness or SIMP optimization, our target is to use OptApp to solve more sophisticated optimization problems. For that we need robust filtering which works with any control combination. I don't see a way to use absolute values for case 2 (for instnce shape VM + thickness). Please correct me if I am wrong.

❗ This will not change any of the algorithms. Algorithm will work on the control field, not on the $\underline{\Delta p}$ ❗

@RezaNajian

[DSchmoelz]

Hi,

your mathematical observation are in general correct.

The ShapeOptimizationApplication works only with changes of physical variables $\Delta s$ and changes of control variables $\Delta p$ as well. In https://link.springer.com/article/10.1007/s00158-013-1031-5, it is mentioned that the control field $p$ is unknown and indeed not necessary for the optimization workflow (in case of explicit filtering). I haven't looked in your current implementations, but I would be curious how you determine the initial control field $p_0$ for explicit filtering (so called deconvolution)?

Regarding your plea for using $\Delta p$ for filtering:
In my opinion, the architecture should be as flexible as possible allowing to create parameterization techniques for both options $\Delta p$ and $p$. I personally am currently developing explicit filtering techniques dealing with $p$. So the best would be that a decision between using one of these now doesn't have to be made. What is your motivation to decide for one of these now? Is it not possible to keep the implementation flexible?

And one last question: What do you mean with homogeneous BCs in the context of shape optimization?

[sunethwarna]

Implementation will be flexible, it is a question of, what a control will call by default (you can create some specific controls for specific needs). As i mentioned, if we are to use $\underline{p}$ in the control, how would you takle the problem mentioned in case 2 where your $\mathbf{G}_i$ is changing in every optimiztaion iteration?

PS: May be my wording is incorrect, I was thinking in the case where implciit filtering is used in shape opt, the BCs for fitlering is always zero.

[Igarizza]

Hello guys,
after reading your comments and making few rounds with @sunethwarna, Iam not sure what is the perfect solution. In general, I agree with keeping the filter as simple as possible. In current implementation it is so. The main problem that someone should know if he gets $\Delta p$ or $p$. The most logical candidate for that is control, which mean we need to have two controls, where one works with full $p$ and another with Deltas for one type of variable. First question I have faced is naming: what can be proper names for them? explicit and implicit ?? Absolute and Delta? Second question, is how to change damping behaviour, as if it works with Deltas it simply damps the update to zero, while if it works with $p$ it needs to damp to $p_0$. I hope you can follow this point.

Our current momentum is to have two (or more?) controls:

• first one) works with Delta and our current implementation (delta_(type)_control). It is current explicit VM (for shape, thickness, and SIMP) with usual damping (simply to zero).
• second one) works with absolute values (absolute_(type)_control). It is current implicit implementation with b.c. If your VM filter for variable also work with absolute, you just use this control in combination with your filter and damping.

We also need to build logic for mesh motion. In one case, where filter is not used to move inner solid nodes we can call the mesh moving app. -> hence it can be third solid_shape control which can be again be used with delta or absolute values, which gives extra two controls for shape variable...

The point I am trying to bring is that we can't find a way to have one simple control for variable type and simple filter for it. we have to create or several controls for different scenario and simple respected filters or One general control and different filter types, that tracks Deltas and etc.

I am open for your suggestions, what can be better extendable for your methods in future.

[sunethwarna]

Hi All,

I don't like the idea of creating multiple controls for the same, and multiple factories (such as implicit and explicit) to be used in the controls. This will be a nightmare to maintain. Hence, after sleeping over it, I have followin solutions.

Solution 1:

1. Every filter have a method to return FilterType
2. Based on the FilterType it can use respective ControlUpdater class ( I am open for name suggestions, I am renowned to comeup with really bad names ;) ).
3. Every Filter will have ApplyDamping(list_of_container_expressions) method to apply damping. The values for each component will be provided by the control.
4. This ControlUpdater class will have following responsibilities
   a. Constructed by passing a filter
   b. Returns $\underline{s}_k$ when passed with the $\underline{p}_k$, $\underline{p}_{k-1}$, $\underline{s}_{k-1}$
   c. Returns $\underline{p}_0$ when $\underline{s}_0$ is passed

With the above ControlUpdater class, we have the following advantages at the expense of additional layer of complexity (someone needs to do the dirty works ;))

1. VertexMorphingShapeControl will have its own ControlUpdater class which handles always $\underline{\Delta p}$, and apply damping with zero values irrespective of the FilterType
2. Other controls can have AbsoluteValueControlUpdater class which handles always $\underline{p}$ or DeltaValueControlUpdater class which handles always $\underline{\Delta p}$ depending on the FilterType used in the control.
3. No need to have duplicate controllers for the same.
4. No need to have duplicate filtering factories. All implicit and explicit filters will live in the same factory.

What this does not solve is the case 2 explained above when used with absolute values. I don't have a solution for that. If it is to use in case 2, then

$$\begin{split} \begin{split} \underline{s}_k &= \mathbf{G}_k \underline{p}_k + \sum_{i=1}^{k-1} \mathbf{G}_i\left(\underline{p}_i - \underline{p}_{i-1}\right) + \mathbf{G}_0 \underline{p}_0 - \mathbf{G}_k \underline{p}_{k-1} \\\ &= \mathbf{\hat{G}}_k\underline{p}_k \end{split} \end{split}$$

Then who-ever uses $\underline{p}$ in their filtering in a case where $\mathbf{G}_k$ is different in every $k^{th}$ iteration of the optimization, then they need to come-up with a mechanism to compute the $\mathbf{\hat{G}}_k$. Otherwise, it will be as far as I see, mathematically wrong.

Solution 2:
We go with $\underline{\Delta p}$. So we don't need the additional complexity of ControlUpdater classes. But still if someone wants to work with $\underline{p}$, they can make a derrived control of the base control.

Those are my thoughts after sleeping over it. Please let me know your thoughts @RezaNajian @Igarizza @DSchmoelz @bdevresse
We want to support all of your future implementations as much as possible, hence wants to be flexible as far as possible. 😄

[Igarizza]

After different calls and discussion we have decided to go with Solution 2.