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

Feature/implicit forcing #1177

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

Feature/implicit forcing #1177

wants to merge 37 commits into from

Conversation

gloopydoop
Copy link
Collaborator

Sorry, first pull request, please point out where documentation should go.

For some applications (immersed boundary methods, sponge regions, generation of FST etc) it is common to have a forcing term that is linearly proportional to the velocity, we denote this as f = \chi * u, where \chi is a scalar field.

Imposing this in user_f results in an explicit formulation where f = \chi * u^(n) that can lead to stability issues for large \chi.

Here we impose an implicit formulation f = \chi * u^(n+1)

Predicted problems:

  • I'm 99% sure if \chi is defined on the boundary, we'll have to adjust the pressure boundary conditions.
  • Nothing has been tested on GPU's etc yet
  • not a lot of testing has gone into this, I'm only pull requesting so that it can be discussed

Comment on lines 241 to 247
!> Dummy user (fluid) implicit Brinkman forcing
subroutine dummy_implicit_brinkman(chi, t)
type(field_t), intent(inout) :: chi
real(kind=rp), intent(in) :: t
chi%x = 0.0
end subroutine dummy_implicit_brinkman

Copy link
Collaborator

Choose a reason for hiding this comment

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

This should throw an error, as all the other dummies.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not all dummies I guess, some are "do nothing" but will not return an error. Like dummy_user_check

Copy link
Collaborator

@MartinKarp MartinKarp left a comment

Choose a reason for hiding this comment

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

I think this is a good feature. One thing I guess as Tim also mentioned is how we want to treat the brinkman term when there is none. Right now it calls a do-nothing routine, but technically we add a vector of zero each time. If we moved out setting h1,h2 outside of computing the residual for the velocity this might be possible to do more elegantly.

YOFAM/README.md Outdated
@@ -0,0 +1,3 @@
#Simple turbulent channel case at Re_tau=180
The channel starts with a slightly perturbed initial condition which becomes turbulent after around 10 time units.
If one wants to change the mesh and play around, please do so, by generating a new mesh with genmeshbox.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this be in the main code? If so, please expand on how it differs from usual turb_channel, remove the field files, and rename the folder.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

none of this example should be in the main code, it was just the case I was using to test the implicit Brinkman term.
I would envision that the immersed_bunny or something similar would be extended as an example.

@@ -0,0 +1,3 @@
#Simple turbulent channel case at Re_tau=180
The channel starts with a slightly perturbed initial condition which becomes turbulent after around 10 time units.
If one wants to change the mesh and play around, please do so, by generating a new mesh with genmeshbox.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Kind of similar comment as for the other example here. Please also avoid ALLCAPS in folder names.

type(user_t), intent(inout) :: u
u%fluid_user_ic => user_ic
u%user_mesh_setup => user_mesh_scale
u%user_implicit_brinkman => bman
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
u%user_implicit_brinkman => bman
u%user_implicit_brinkman => bman

u%user_implicit_brinkman => bman
end subroutine user_setup

! Harry ---------------------------------------
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
! Harry ---------------------------------------
!> Insert your comments here

Copy link
Collaborator

Choose a reason for hiding this comment

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

remove

@@ -147,7 +147,7 @@ subroutine pnpn_vel_res_cpu_compute(Ax, u, v, w, u_res, v_res, w_res, &

do i = 1, n
c_Xh%h1(i,1,1,1) = mu
c_Xh%h2(i,1,1,1) = rho * (bd / dt)
c_Xh%h2(i,1,1,1) = rho * (bd / dt) + chi%x(i,1,1,1)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is nice and will work I think, but maybe we should also consider moving h1, h2 to the Ax_helm type @njansson @timofeymukha . They do not really belong in coef, but are directly linked to the Helmholtz equation. Maybe something we could issue another PR for?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think the idea of using a global h1 and h2 that sits somewhere and gets overwritten with right values just prior to a call to an axhelm is unnecessary. I would say we can just pass h1 and h2 to axhelm's compute routine as arguments, or is there some reason not to do that? But I agree that if we should dedicate a components for this in a type, it should be axhelm, and not coef.

Copy link
Collaborator

Choose a reason for hiding this comment

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

If we do that the idea of passing something that computes a linear operator Ax to the ksp solvers will kind of not work as different matrices will have different inputs. Because of that I was leaning a bit towards putting it directly in Ax.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see, that makes sense.

@@ -473,6 +473,8 @@ subroutine fluid_pnpn_step(this, t, tstep, dt, ext_bdf)
type(ksp_monitor_t) :: ksp_results(4)
! Extrapolated velocity for the pressure residual
type(field_t), pointer :: u_e, v_e, w_e
! Field for implicit Brinkman term
! type(field_t), intent(inout) :: chi_fam
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this be commented or?

@@ -581,10 +583,12 @@ subroutine fluid_pnpn_step(this, t, tstep, dt, ext_bdf)

! Compute velocity.
call profiler_start_region('Velocity residual', 19)
! Potentially compute the Brinkman penalization term
call this%userbrinkman%compute(t)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess it does not need to be user, I forsee a lot could be captured by typical forcings in the json file. Similar to constant forcing.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is just a naming suggestion

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree, can't this be put in the forcing? Same with chi, would be nice to hide these case specific variables under some object/abstraction

@MartinKarp MartinKarp added enhancement New feature or request help wanted Extra attention is needed labels Mar 17, 2024
@timfelle timfelle marked this pull request as draft March 19, 2024 09:07
@gloopydoop gloopydoop marked this pull request as ready for review March 19, 2024 10:19
@gloopydoop gloopydoop marked this pull request as draft March 19, 2024 10:20
…the source terms. NOTE. I have used extra fields in the field list so that I didn't break other source terms, but I suspect it would be more understandable if we passed an additional chi field through all source terms
Copy link
Collaborator

@timfelle timfelle left a comment

Choose a reason for hiding this comment

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

Any chance you could go through and cleanup the places where stuff is no longer changed?
It is kinda difficult to know what is still needed and what is not. Are you still using the changes in user_intf.f90 for instance?

src/source_terms/brinkman_source_term.f90 Outdated Show resolved Hide resolved
src/source_terms/brinkman_source_term.f90 Outdated Show resolved Hide resolved
src/source_terms/source_term.f90 Outdated Show resolved Hide resolved
src/source_terms/source_term.f90 Outdated Show resolved Hide resolved
src/source_terms/source_term.f90 Outdated Show resolved Hide resolved
src/source_terms/brinkman_source_term.f90 Outdated Show resolved Hide resolved
gloopydoop and others added 16 commits March 21, 2024 16:16
… sponge. NOTE there is certainly some scaling factor wrong with the current chi implementation!
… passive scalars, test implicit vs explicit, implement pnpn_res on device and sx to include the extrapolated Brinkman terms in the pressure solve
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants