Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDE filter for Brinkman source term #1562

Draft
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

gloopydoop
Copy link
Collaborator

This is a PDE filter used to smooth the boundaries of a Brinkman source term, to avoid oscillations associated with sharp interfaces + spectral methods.

The theory is based on B. S. Lazarov, O. Sigmund (2010) "Filters in topology optimization based on Helmholtz-type differential equations".

@gloopydoop gloopydoop marked this pull request as draft October 29, 2024 10:58
@gloopydoop gloopydoop marked this pull request as ready for review October 29, 2024 12:07
@gloopydoop gloopydoop marked this pull request as draft October 29, 2024 13:27
@gloopydoop gloopydoop marked this pull request as ready for review October 29, 2024 15:37
use hsmg, only: hsmg_t
use utils, only: neko_error
use device_math, only: device_cfill, device_col3
implicit none
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
implicit none
implicit none

call json_get_or_default(json, "filter.radius", this%r, 1.0_rp)

call json_get_or_default(json, "filter.tolerance", this%abstol_filt, &
0.0000000001_rp)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use exponential notation instead?

Suggested change
0.0000000001_rp)
1.0e-10_rp)

src/source_terms/brinkman_source_term.f90 Show resolved Hide resolved
@timofeymukha
Copy link
Collaborator

As a general comment, could we come up with more specific names? filter_t is definitely too generic, since we already have e.g. a filter for LES. PDE_filter is better, but perhaps could be concretized as well. I would also use pde, we generally avoid capitals unless really needed.

@timfelle
Copy link
Collaborator

timfelle commented Oct 30, 2024

As a general comment, could we come up with more specific names? filter_t is definitely too generic, since we already have e.g. a filter for LES. PDE_filter is better, but perhaps could be concretized as well. I would also use pde, we generally avoid capitals unless really needed.

A counter proposal would be, shouldn't the LES filter derive from the generic filter type then, we will probably add more filters later, meaning the abstract base class should have some name which is easy to understand.

on the PDE_filter name, sure, it might be better to call it a helmholz_filter, since that is the PDE implemented for this particular filter.

@gloopydoop
Copy link
Collaborator Author

Both good suggestions.
I just had a little read of the elementwise_filter_t and I suppose with the exception of fields vs arrays, the elementwise_field_filter_3d fits filter_apply. @timofeymukha, I guess you've done a lot LES stuff, what are your thoughts?

Regarding the names, yeh I sort of expected this to be problematic. We also now have filter.f90 and filters.f90 😅

I'm happy with helmholz_filter, that's a good suggestion.

@timfelle
Copy link
Collaborator

Both good suggestions. I just had a little read of the elementwise_filter_t and I suppose with the exception of fields vs arrays, the elementwise_field_filter_3d fits filter_apply. @timofeymukha, I guess you've done a lot LES stuff, what are your thoughts?

Regarding the names, yeh I sort of expected this to be problematic. We also now have filter.f90 and filters.f90 😅

I'm happy with helmholz_filter, that's a good suggestion.

Yes that is also a thing 😅 I guess we need to move the smooth_step functions somewhere else as well.

@timofeymukha
Copy link
Collaborator

@Shiyu-Sandy-Du implemented the LES filtering. I think if you guys can figure out a good abstract interface that would fit a reasonably large class of filters, that would be great!

@gloopydoop gloopydoop marked this pull request as draft October 30, 2024 11:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants