-
Notifications
You must be signed in to change notification settings - Fork 32
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
base: develop
Are you sure you want to change the base?
Feature/implicit forcing #1177
Conversation
src/common/user_intf.f90
Outdated
!> 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 | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
u%user_implicit_brinkman => bman | |
u%user_implicit_brinkman => bman |
u%user_implicit_brinkman => bman | ||
end subroutine user_setup | ||
|
||
! Harry --------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
! Harry --------------------------------------- | |
!> Insert your comments here |
src/common/.user_intf.f90.swp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
src/fluid/bcknd/cpu/pnpn_res_cpu.f90
Outdated
@@ -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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/fluid/fluid_pnpn.f90
Outdated
@@ -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 |
There was a problem hiding this comment.
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?
src/fluid/fluid_pnpn.f90
Outdated
@@ -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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
…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
There was a problem hiding this 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?
… 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
Co-authored-by: Tim Felle Olsen <[email protected]>
Co-authored-by: Tim Felle Olsen <[email protected]>
Co-authored-by: Tim Felle Olsen <[email protected]>
Co-authored-by: Tim Felle Olsen <[email protected]>
Co-authored-by: Tim Felle Olsen <[email protected]>
Co-authored-by: Tim Felle Olsen <[email protected]>
…o into feature/implicit_forcing
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: